FR2901943A1 - Quality of service resource reserving method for e.g. Ethernet network, involves sending send request to device, and sending resource reservation request conforming to on-line signalization protocol to infrastructure device - Google Patents
Quality of service resource reserving method for e.g. Ethernet network, involves sending send request to device, and sending resource reservation request conforming to on-line signalization protocol to infrastructure device Download PDFInfo
- Publication number
- FR2901943A1 FR2901943A1 FR0605015A FR0605015A FR2901943A1 FR 2901943 A1 FR2901943 A1 FR 2901943A1 FR 0605015 A FR0605015 A FR 0605015A FR 0605015 A FR0605015 A FR 0605015A FR 2901943 A1 FR2901943 A1 FR 2901943A1
- Authority
- FR
- France
- Prior art keywords
- signaling protocol
- resource reservation
- request
- protocol
- type
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/781—Centralised allocation of resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/13—Flow control; Congestion control in a LAN segment, e.g. ring or bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Procédé de réservation de ressource lors de la transmission d'un contenuMethod of reserving a resource when transmitting content
dans un réseau de communication, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transmissions de contenus de données dans un réseau de communication. Plus précisément, l'invention concerne la réservation de ressources pour de telles transmissions dans un contexte de qualité de service. 2. Solutions de l'art antérieur Le standard "Universal Plug and Play" (ci-après désigné par standard UPnP) a pour objectif de permettre de manière simple et efficace à des systèmes et des équipements d'être mis en réseaux et de collaborer, sans configuration préalable. Les équipements compatibles avec le standard UPnP sont notamment des dispositifs audio-vidéo ou des ordinateurs personnels (PCs) fabriqués par diverses sociétés. Ces équipements peuvent être intégrés dans un réseau IP (pour Internet Protocol ) local tel qu'un réseau domestique. Le standard UPnP fournit à un équipement compatible des moyens de connexion dynamique à un réseau UPnP (qui met en oeuvre le standard UPnP), lui permet de découvrir les autres équipements compatibles du réseau et lui permet de communiquer (ou exposer) ses propres capacités. La technologie UPnP est basée sur le protocole réseau TCP/IP, sur le protocole HTTP (pour HyperText Transport Protocol ) et sur le protocole XML (pour Extensible Markup Language ). in a communication network, product computer program, storage medium and corresponding device. FIELD OF THE INVENTION The field of the invention is that of transmissions of data contents in a communication network. More specifically, the invention relates to the reservation of resources for such transmissions in a context of quality of service. 2. Solutions of the Prior Art The purpose of the "Universal Plug and Play" standard (hereinafter referred to as the UPnP standard) is to enable simple and efficient systems and equipment to be networked and collaborated. , without prior configuration. UPnP compatible devices include audio-video devices or personal computers (PCs) manufactured by various companies. These devices can be integrated into a local IP (for Internet Protocol) network such as a home network. The UPnP standard provides a compatible device with means of dynamic connection to a UPnP network (which implements the UPnP standard), allows it to discover other compatible devices of the network and allows it to communicate (or expose) its own capabilities. UPnP is based on the TCP / IP network protocol, the HTTP protocol (for HyperText Transport Protocol) and the XML protocol (for Extensible Markup Language).
Les constituants essentiels d'un réseau UPnP sont les équipements, les services offerts par ces équipements et les postes de contrôle (ou control points en anglais). Un équipement UPnP (qui met en oeuvre le standard UPnP) peut supporter plusieurs services, et est catégorisé en fonction de la liste des services (par exemple un service de type serveur de contenus vidéo , un service de type imprimante, etc.) qu'il peut fournir. Un équipement UPnP expose les services qu'il peut mettre en oeuvre (on parlera dans la suite de ses services ) au moyen d'un fichier de description en langage XML. Un service dans un équipement UPnP comprend une machine d'état, un serveur de contrôle et un serveur d'événements. La machine d'état modélise un état du service grâce à la mise à jour de variables d'état caractérisant l'équipement. Le serveur de contrôle reçoit les requêtes d'équipements distants, exécute les commandes associées et met à jour la machine d'état. Le serveur d'événements orchestre la diffusion sur le réseau de cette mise à jour auprès des équipements UPnP ayant montré leur intérêt pour cette information. The essential components of a UPnP network are the equipment, the services offered by this equipment and the control points (or control points in English). UPnP equipment (which implements the UPnP standard) can support several services, and is categorized according to the list of services (for example a service of video content server type, a printer type service, etc.) that he can provide. UPnP equipment exposes the services it can implement (we will talk about the rest of its services) using a description file in XML. A service in UPnP equipment includes a state machine, a control server, and an event server. The state machine models a state of service by updating state variables characterizing the equipment. The control server receives requests from remote devices, executes associated commands, and updates the state machine. The event server orchestrates the broadcast on the network of this update to the UPnP devices that have shown interest in this information.
Un poste de contrôle UPnP est capable de découvrir et de contrôler des équipements UPnP du réseau UPnP. Quand un nouvel équipement est découvert par le poste de contrôle, ce dernier obtient une description de ce nouvel équipement, a ainsi connaissance des services offerts par cet équipement, demande une description précise de chaque service disponible et enfin envoie des requêtes de contrôle du service sélectionné. Le poste de contrôle peut aussi souscrire auprès du serveur d'événements afin d'être notifié de tout changement d'état. Le standard UPnP Audio Visual (pour UPnP audio visuel , ci-après référencé UPnP AV ) définit un ensemble d'équipements UPnP (par exemple les télévisions, les magnétoscopes, lecteurs DVD, les lecteurs MP3, les ordinateurs PC, ...) avec leurs services associés, qui sont plus spécifiquement dédiés au monde audio/vidéo numérique domestique. Les trois entités logiques principales d'un réseau UPnP AV (qui met en oeuvre le standard UPnP AV) sont : un serveur de media (ou Media Server en anglais) ayant accès à des contenus multimédia qu'il peut diffuser sur le réseau local, un lecteur de media (ou Media Renderer ) capable de jouer localement ce type de contenus multimédia reçus du réseau, et un poste de contrôle coordonnant les opérations. Le standard UPnP Quality of Service (pour UPnP Qualité de Service , ci-après référencé UPnP QoS ), tel que décrit dans le document de référence UPnP QoS standard v1.0/v2.0 , définit un ensemble de services UPnP relatifs à la gestion de qualité de service, qui sont intégrés à des équipements UPnP. Trois services sont ainsi définis : le service UPnP QosPolicyHolder , ci-après désigné par QosPolicyHolder , qui gère les politiques de Qualité de Service validées par un utilisateur et à appliquer sur le réseau ; le service UPnP QosDevice , ci-après désigné par QosDevice , qui est un service d'un équipement du réseau permettant de recevoir les consignes de QoS à appliquer à un flot de donnée d'un contenu particulier ; et le service UPnP QosManager , ci-après désigné par QosManager , qui, sur ordre d'un Poste de Contrôle voulant mettre en place un flot multimédia, est en charge de recueillir auprès du QosPolicyHolder la politique à appliquer et d'informer les QosDevice sur le chemin du flot des actions à mettre en place. Conformément à ce standard, lors du processus de recherche d'un chemin (ou trajet physique emprunté par un contenu de données depuis un équipement source vers un équipement récepteur) entre une source et un récepteur UPnP, le QosManager (équipement responsable), interroge chaque QosDevice pour connaître les autres équipements qui lui sont proches (au moyen d'une requête GetPathlnformation qui envoie une liste d'adresse MAC des autres équipements présents dans le réseau local de type IP, et détectés par chaque interface réseau du QosDevice). Cependant, certains équipements d'interconnexion du réseau (par exemple des commutateurs ou switches ) ne divulguent pas leurs adresses MAC lors du routage des messages sur le réseau. Ces équipements sont donc invisibles pour les services UPnP QosDevice. De plus, lorsqu'ils ne supportent pas le service UPnP QosDevice, ces équipements sont aussi invisibles pour les services UPnP QosManager. A UPnP control station is able to discover and control UPnP devices from the UPnP network. When new equipment is discovered by the control station, the latter obtains a description of this new equipment, is aware of the services offered by this equipment, asks for a precise description of each available service and finally sends requests for control of the selected service. . The checkpoint can also subscribe to the event server to be notified of any change of state. The UPnP Audio Visual standard (for UPnP visual audio, hereinafter referred to as UPnP AV) defines a set of UPnP devices (eg TVs, VCRs, DVD players, MP3 players, PCs, etc.) with their associated services, which are more specifically dedicated to the domestic digital audio / video world. The three main logical entities of a UPnP AV network (which implements the UPnP AV standard) are: a media server (or Media Server in English) having access to multimedia contents that it can broadcast on the local network, a media player (or Media Renderer) able to play locally this type of multimedia content received from the network, and a control station coordinating operations. The UPnP Quality of Service standard (for UPnP Quality of Service, hereinafter referred to as UPnP QoS), as described in the UPnP QoS Standard v1.0 / v2.0 Reference Document, defines a set of UPnP services related to the management quality of service, which are integrated with UPnP equipment. Three services are defined as follows: the UPnP QosPolicyHolder service, hereinafter referred to as QosPolicyHolder, which manages the QoS policies validated by a user and to be applied on the network; the UPnP service QosDevice, hereinafter referred to as QosDevice, which is a service of a network equipment for receiving the QoS instructions to be applied to a data stream of a particular content; and the UPnP QosManager service, hereinafter referred to as QosManager, which, on the order of a Control Station wishing to set up a multimedia stream, is in charge of collecting from the QosPolicyHolder the policy to be applied and informing the QosDevices about the path of the flow of actions to put in place. According to this standard, during the process of finding a path (or physical path taken by a data content from a source device to a receiving device) between a source and a UPnP receiver, the QosManager (responsible equipment) interrogates each QosDevice to know the other devices that are close to it (by means of a GetPathlnformation request which sends a MAC address list of the other equipments present in the local network of IP type, and detected by each network interface of the QosDevice). However, some network interconnection devices (eg switches or switches) do not disclose their MAC addresses when routing messages over the network. This equipment is therefore invisible to UPnP QosDevice services. In addition, when they do not support the UPnP QosDevice service, these devices are also invisible for UPnP QosManager services.
Le standard UPnP est un standard émergeant, en cours de spécification, et n'est pas encore universellement supporté par les équipements d'infrastructure des réseaux locaux. Les demandes de garantie de QoS proviennent des applications multimédias réparties qui ne se contentent plus du service "au mieux" (ou Best Effort en anglais) de l'Internet. Ces applications vont du simple transfert de données à celles plus complexes telles que la téléphonie, la vidéo à la demande ou la conférence multimédia. Il existe des réseaux locaux traditionnels de type Ethernet qui ne sont pas capables de réserver de la bande passante pour un trafic avec des contraintes spécifiques. Au mieux, les équipements réseau d'interconnexion (tels que des commutateurs ou switches ) établissent une gestion de priorité de leurs files d'attente (classiquement 8 files au maximum) pour des types de flot identiques (par exemple, tous les flots vidéos passent par la même file, ce qui les rendent prioritaires par rapport à un flot Internet classique). Ceci pose problème lorsque l'on considère le cas de plusieurs flots de même priorité, mais avec des contraintes temps réel différentes. Ainsi, le rôle d'un mécanisme de réservation de ressources est d'informer les entités du réseau des besoins QoS des applications multimédia. Ces entités feront alors en sorte de gérer leurs ressources réseaux (telles que la bande passante) afin de supporter tous les critères du flot multimédia à transmettre. Les versions 1 et 2 du standard UPnP QoS sont basées principalement sur une gestion par priorité de QoS. Ainsi, ces versions du standard UPnP QoS ne permettent pas de réaliser de réservation de ressource par flot. On parle pour le standard UPnp QoS de protocole de signalisation centralisée. Le protocole "Resource Reservation Protocol" (ou protocole de réservation de ressources ci-après désigné par protocole RSVP ) est un protocole bien connu de signalisation de réservation de ressource sur Internet. Selon ce protocole, chaque application peut demander l'établissement d'un lien point-à-point et réservé garantissant les critères QoS. On parle alors de protocole de signalisation en ligne. Le protocole RSVP fonctionne au-dessus du protocole [P, et est capable de traverser de multiples réseaux. Ainsi, le protocole RSVP consiste principalement en l'échange de paramètres de QoS entre un équipement source, des équipements intermédiaires et un équipement récepteur avant de mettre en oeuvre une transmission d'un contenu multimédia. Grâce à ces paramètres de QoS, chaque équipement RSVP (équipement mettant en oeuvre le protocole RSVP) participant à la transmission du contenu réserve des ressources propres et configure sa gestion des flots pour répondre aux critères de QoS demandés. Une fois la procédure de réservation achevée, l'équipement source peut envoyer le contenu multimédia. Si l'un des équipements sur le chemin ne peut supporter les paramètres spécifiés pour le nouveau contenu, l'équipement source est informé de cet échec. The UPnP standard is an emerging standard, under specification, and is not yet universally supported by LAN infrastructure equipment. QoS warranty claims come from distributed multimedia applications that are no longer satisfied with the Internet's "best effort" service. These applications range from simple data transfer to more complex ones such as telephony, video on demand or multimedia conferencing. There are traditional local Ethernet networks that are not able to reserve bandwidth for traffic with specific constraints. At best, network interconnection devices (such as switches or switches) prioritize their queues (typically up to 8 queues) for identical stream types (for example, all video streams pass by the same queue, which makes them priority over a conventional Internet flow). This is problematic when one considers the case of several streams of the same priority, but with different real-time constraints. Thus, the role of a resource reservation mechanism is to inform the network entities of the QoS requirements of the multimedia applications. These entities will then manage their network resources (such as bandwidth) to support all the criteria of the multimedia stream to be transmitted. UPnP QoS versions 1 and 2 are based primarily on QoS priority management. Thus, these versions of the UPnP QoS standard do not make it possible to perform resource reservation per stream. We speak for the UPnp QoS standard of centralized signaling protocol. The "Resource Reservation Protocol" (RSVP protocol) is a well known protocol for resource reservation signaling on the Internet. According to this protocol, each application can request the establishment of a point-to-point and reserved link guaranteeing the QoS criteria. This is called an online signaling protocol. The RSVP protocol operates over the [P protocol, and is capable of traversing multiple networks. Thus, the RSVP protocol mainly consists of the exchange of QoS parameters between a source equipment, intermediate equipment and a receiver equipment before implementing a transmission of multimedia content. Thanks to these QoS parameters, each RSVP equipment (equipment implementing the RSVP protocol) participating in the transmission of the content reserves its own resources and configures its management of the streams to meet the requested QoS criteria. Once the reservation procedure is complete, the source equipment can send the multimedia content. If one of the devices on the path can not support the specified parameters for the new content, the source device is notified of this failure.
Cependant, le protocole RSVP ne peut être mis en oeuvre à lui seul dans les réseaux locaux de type Ethernet. En effet, les messages RSVP véhiculés dans la couche réseau 3 sont totalement transparents pour les équipements d'infrastructure réseau évoluant au niveau 2 (par exemple un commutateur). Aussi, le protocole "Subnet Bandwidth Manager" (ci-après désigné par protocole SBM) défini par la norme RFC-2814 est un protocole de signalisation de réservation QoS pour le contrôle d'admission de flux, basé sur le protocole RSVP mais adapté aux réseaux de type IEEE 802. Le protocole SBM consiste à élire un responsable (ou manager en anglais ci-après désigné par DSBM) sur chaque segment du réseau local afin de classifier et garder trace de chaque flot RSVP, et de fournir un contrôle d'admission et une réservation de bande passante pour ces flots. Il est possible que des segments de niveau 2 soient interconnectés par des équipements qui ne sont pas compatibles avec le protocole SBM. Dans ce cas, ces segments sont traités comme un segment unique contrôlé par un DSBM. A la réception d'un message RSVP destiné à un équipement RSVP récepteur appartenant à la couche 3, chaque équipement de ce segment unique doit rechercher le DSBM et lui envoyer ce message RSVP au lieu de l'envoyer à l'équipement récepteur. Actuellement, la plupart des commutateurs de réseau local sont compatibles avec le protocole SBM. Tel qu'expliqué précédemment, le besoin de garantie de QoS (en termes de bande passante et/ou de criticité temps réel) pour des flots multimédia augmente avec le développement des équipements multimédia. Cependant, on s'aperçoit que pour remplir cet objectif de garantie de QoS, une coordination est nécessaire entre les équipements du réseau afin de délivrer des services assurant la QoS depuis la source jusqu'au récepteur. Dans la plupart des réseaux de communication sont intégrés des équipements (noeuds ou terminaux) qui sont compatibles avec le standard UPnP QoS mais également des équipements qui ne le sont pas, on parle alors de réseau hétérogène. Cependant, le standard UPnP QoS ne prévoit aucune interaction avec des équipements qui ne sont pas compatibles avec le standard UPnP QoS. Ainsi, dans ces réseaux hétérogènes, il n'est pas possible d'assurer la QoS de la source au récepteur dans le cas où l'un des équipement traversé n'est pas compatible avec le protocole UPnP QoS. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une technique de réservation de ressources QoS lors de la transmission d'un contenu sur un chemin de transmission comprenant des dispositifs compatibles avec un protocole de signalisation centralisée et des dispositifs non compatibles avec ce protocole mais compatibles avec un protocole de signalisation en ligne. However, the RSVP protocol can not be implemented on its own in Ethernet local area networks. Indeed, the RSVP messages conveyed in the network layer 3 are completely transparent for network infrastructure equipment operating at level 2 (for example a switch). Also, the protocol "Subnet Bandwidth Manager" (hereinafter referred to as SBM protocol) defined by the RFC-2814 standard is a QoS reservation signaling protocol for flow admission control, based on the RSVP protocol but adapted to IEEE 802 type networks. The SBM protocol consists in electing a manager (or manager in English hereinafter referred to as DSBM) on each segment of the local network to classify and keep track of each RSVP flow, and to provide a control of admission and a bandwidth reservation for these streams. It is possible that level 2 segments are interconnected by equipment that is not compatible with the SBM protocol. In this case, these segments are treated as a single segment controlled by a DSBM. Upon receiving an RSVP message for a Layer 3 receiver RSVP equipment, each device in that single segment must search for the DSBM and send that RSVP message instead of sending it to the receiving equipment. Currently, most LAN switches are compatible with the SBM protocol. As explained above, the need for a QoS guarantee (in terms of bandwidth and / or real-time criticality) for multimedia streams increases with the development of multimedia equipment. However, we realize that to fulfill this objective of QoS guarantee, a coordination is necessary between the network equipment in order to deliver QoS services from the source to the receiver. In most communication networks are integrated devices (nodes or terminals) that are compatible with the standard UPnP QoS but also equipment that is not, it is called a heterogeneous network. However, the UPnP QoS standard does not provide for interaction with equipment that is not compatible with the UPnP QoS standard. Thus, in these heterogeneous networks, it is not possible to provide the QoS from the source to the receiver in the case where one of the equipment crossed is not compatible with the UPnP QoS protocol. 3. Objectives of the invention The invention, in at least one embodiment, has the particular objective of overcoming these disadvantages of the prior art. More specifically, an object of the invention, in at least one of its embodiments, is to provide a QoS resource reservation technique when transmitting content over a transmission path comprising protocol-compatible devices. centralized signaling and devices not compatible with this protocol but compatible with an online signaling protocol.
Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit compatible avec les recommandations des protocoles mis en oeuvre. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de réservation de ressource dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif gestionnaire qui est un dispositif dudit premier type. Ce procédé comprend les étapes suivantes : - détection de la présence, sur le chemin de transmission, d'au moins un dispositif du second type qui n'est pas compatible avec le protocole de signalisation centralisé ; -détermination d'un dispositif de transition qui est un dispositif du premier type et qui est aussi compatible avec le protocole de signalisation en ligne ; - envoi au dispositif de transition déterminé d'une demande d'envoi, audit ou auxdits dispositif(s) du second type détecté(s), d'une requête de réservation de ressource conforme au protocole de signalisation en ligne Le principe de l'invention consiste en la commande par un dispositif gestionnaire, lors d'une réservation de ressource pour la transmission d'un contenu, d'au moins un dispositif conforme au protocole de signalisation centralisé qui soit capable de transmettre, à au moins un dispositif non compatible avec le protocole de signalisation centralisé mais compatible avec le protocole de signalisation en ligne, une requête de réservation de ressource conforme au protocole de signalisation en ligne. Another objective of the invention, in at least one of its embodiments, is to implement such a technique that is compatible with the recommendations of the protocols implemented. The invention, in at least one of its embodiments, still aims to implement such a technique that is simple to implement and for a low cost. 4. DESCRIPTION OF THE INVENTION In a particular embodiment of the invention, there is provided a resource reservation method in the context of the transmission of a data content on a transmission path between a source device and a device. receiving device belonging to a communication network, said network comprising: at least one device compatible with a centralized signaling protocol, said device of a first type; and at least one device compatible with an on-line signaling protocol, said device of a second type, said method being implemented by a management device which is a device of said first type. This method comprises the following steps: detection of the presence, on the transmission path, of at least one device of the second type which is not compatible with the centralized signaling protocol; determining a transition device which is a device of the first type and which is also compatible with the on-line signaling protocol; sending to the determined transition device a request for sending, to said detected second type device (s), a resource reservation request conforming to the on-line signaling protocol. The principle of the invention consists in the control by a management device, during a resource reservation for the transmission of a content, of at least one device compliant with the centralized signaling protocol which is capable of transmitting, to at least one incompatible device with the centralized signaling protocol but compatible with the on-line signaling protocol, a resource reservation request according to the on-line signaling protocol.
Ainsi, ce procédé de réservation de ressources selon l'invention permet la transmission de contenus sur un chemin de transmission comprenant des dispositifs compatibles avec un protocole de signalisation centralisée et des dispositifs non compatibles avec ce protocole mais compatibles avec un protocole de signalisation en ligne. Thus, this resource reservation method according to the invention allows the transmission of contents on a transmission path comprising devices compatible with a centralized signaling protocol and devices not compatible with this protocol but compatible with an online signaling protocol.
Ainsi, ce procédé selon l'invention est basé sur des protocoles de réservation de ressource en ligne ou centralisé et suit les recommandations de ces protocoles, ce qui permet de garantir l'interopérabilité entre ces différents protocoles. Par ailleurs, grâce au procédé selon l'invention, il n'est pas nécessaire de modifier les dispositifs qui ne supportent pas le protocole de signalisation centralisé ce qui permet de réduire le coût du réseau de communication. Par ailleurs, le procédé selon l'invention permet de mettre en oeuvre de la réservation de ressource QoS dans un réseau de communication de manière tout à fait transparente pour l'utilisateur. Thus, this method according to the invention is based on online or centralized resource reservation protocols and follows the recommendations of these protocols, which ensures interoperability between these different protocols. Furthermore, thanks to the method according to the invention, it is not necessary to modify the devices that do not support the centralized signaling protocol which reduces the cost of the communication network. Moreover, the method according to the invention makes it possible to implement QoS resource reservation in a communication network in a manner that is completely transparent to the user.
Avantageusement, le procédé selon l'invention comprend également les étapes suivantes : acquisition d'une topologie du réseau de communication ; détermination, parmi les dispositifs du réseau, desdits au moins un dispositifs du premier type. Advantageously, the method according to the invention also comprises the following steps: acquisition of a topology of the communication network; determining, among the devices of the network, said at least one devices of the first type.
Préférentiellement, le procédé comprend en outre une étape de détermination du chemin de transmission du contenu. Selon un premier mode de réalisation avantageux de l'invention, le procédé comprend également l'étape suivante : sélection sur le chemin de transmission d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Preferably, the method further comprises a step of determining the transmission path of the content. According to a first advantageous embodiment of the invention, the method also comprises the following step: selection on the transmission path of a common transition device for at least two devices of the second type detected.
Ainsi, selon ce premier mode de réalisation, la requête de réservation conforme au protocole de réservation en ligne est transmise depuis le dispositif de transition vers le dispositif récepteur sans être arrêtée sur son parcours. Selon un second mode de réalisation avantageux de l'invention, le procédé comprend également l'étape suivante : pour chaque dispositif du second type détecté, sélection sur le chemin de transmission d'un dispositif de transition distinct. Ainsi, selon ce second mode de réalisation, la requête de réservation conforme au protocole de réservation en ligne est arrêtée par un dispositif du premier type présent sur le chemin de transmission directement en aval du dispositif du second, ce dernier ne la transmet donc pas à d'autres dispositifs du chemin de transmission. Préférentiellement, le procédé de réservation comprend également l'étape suivante : - détermination du ou desdits dispositifs du premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne initiée par le dispositif de transition. Avantageusement, le procédé de réservation comprend également l'étape suivante : - envoi à au moins un du ou desdits dispositifs de premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée, préalablement à la demande d'envoi au dispositif de transition d'une requête de réservation de ressource conforme au protocole de signalisation en ligne. Préférentiellement, le procédé de réservation ne comprend pas d'étape d'envoi au(x) dispositif(s) de premier type qui tien(nent) compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée. Thus, according to this first embodiment, the reservation request according to the online reservation protocol is transmitted from the transition device to the receiving device without being stopped on its path. According to a second advantageous embodiment of the invention, the method also comprises the following step: for each device of the second detected type, selection on the transmission path of a separate transition device. Thus, according to this second embodiment, the reservation request according to the online reservation protocol is stopped by a device of the first type present on the transmission path directly downstream of the device of the second, the latter does not transmit it to other devices of the transmission path. Preferably, the reservation method also comprises the following step: determining the one or more devices of the first type that take into account the resource reservation request according to the on-line signaling protocol initiated by the transition device. Advantageously, the reservation method also comprises the following step: sending to at least one of said first type device or devices which take into account the resource reservation request according to the on-line signaling protocol of a reservation request of resource compliant with the centralized signaling protocol, prior to the request to send to the transition device a resource reservation request according to the online signaling protocol. Preferably, the reservation method does not include a step of sending to (x) device (s) of the first type that keeps (n) the resource reservation request according to the on-line signaling protocol of a request. resource reservation according to the centralized signaling protocol.
Selon une caractéristique avantageuse de l'invention, le procédé comprend également une étape initiale de réception par le dispositif gestionnaire d'une requête de transmission avec qualité de service du contenu clu dispositif source vers le dispositif récepteur. According to an advantageous characteristic of the invention, the method also comprises an initial step of reception by the management device of a transmission request with quality of service of the content of the source device to the receiving device.
Avantageusement, le procédé de réservation comprend également une étape de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec de la réservation de ressource pour la transmission du contenu. Dans un autre mode de réalisation, l'invention concerne également un procédé de réservation dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif de transition, qui est un dispositif dudit premier type et qui est aussi compatible avec le protocole de signalisation en ligne. Advantageously, the reservation method also comprises a step of receiving a report from the one or more transition device (s) indicating the success or failure of the resource reservation for the transmission of the content. In another embodiment, the invention also relates to a reservation method in the context of the transmission of data content on a transmission path between a source device and a receiving device belonging to a communication network, said network comprising: at least one device compatible with a centralized signaling protocol, said device of a first type; and at least one device compatible with an on-line signaling protocol, said device of a second type, said method being implemented by a transition device, which is a device of said first type and which is also compatible with the protocol online signage.
Ce procédé comprend les étapes suivantes : réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; - envoi de ladite requête audit dispositif du second type. Avantageusement, la demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne est incluse dans un message de demande de réservation de ressource conforme au protocole de signalisation centralisée. The method includes the steps of: receiving a request to send a resource reservation request in accordance with the on-line signaling protocol to a device of said second type, located on the transmission path and which is not compatible with the centralized signaling protocol; sending said request to said device of the second type. Advantageously, the request to send a resource reservation request that complies with the online signaling protocol is included in a resource reservation request message that complies with the centralized signaling protocol.
Préférentiellement, le procédé de réservation comprend également les étapes suivantes: réception d'une confirmation de réservation de ressource conforme au protocole de signalisation en ligne ; détermination si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire ; dans l'affirmative, transmission au dispositif gestionnaire d'un rapport positif concernant la réservation de ressource pour la transmission du contenu. Selon une caractéristique avantageuse de l'invention, si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire, le procédé de réservation ne comprend pas d'étape d'envoi de ladite confirmation de réservation de ressource vers d'autres dispositifs en amont du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source et le dispositif récepteur. Avantageusement, ce procédé de réservation comprend également les étapes suivantes : réception d'une demande de réservation de ressource conforme au protocole de signalisation en ligne ; détermination si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire a déjà été reçue ; dans l'affirmative, le procédé de réservation ne comprend pas d'étape d'envoi de la demande de réservation de ressource conforme au protocole de signalisation en ligne vers les dispositifs en aval du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source et le dispositif récepteur. Préférentiellement, si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire a déjà été reçue, le procédé comprend également l'envoi d'un rapport positif concernant la demande de réservation de ressource conforme au protocole de signalisation en ligne. Préférentiellement, le procédé de réservation comprend également les étapes suivantes: - réception d'une demande de libération de ressource conforme au protocole de signalisation centralisée ; détermination si la demande de libération de ressource correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire a été préalablement reçue pour au moins un dispositif du second type ; dans l'affirmative, envoi d'une demande de libération de ressource conforme au protocole de signalisation en ligne audit au moins un dispositif du second type. Avantageusement le protocole de signalisation centralisée est le protocole UPnP et le protocole de signalisation en ligne est le protocole SBM.L'invention concerne également un produit programme d'ordinateur., comprenant des instructions de code de programme pour l'exécution des étapes d'au moins un des procédés de réservation tels que précédemment décrits lorsque ledit programme est exécuté sur un ordinateur. Preferably, the reservation method also comprises the following steps: receiving a resource reservation confirmation according to the on-line signaling protocol; determining if the resource reservation confirmation corresponds to a prior request to send a resource reservation request conforming to the on-line signaling protocol by a management device; in the affirmative, transmitting to the managing device a positive report concerning the resource reservation for the transmission of the content. According to an advantageous characteristic of the invention, if the resource reservation confirmation corresponds to a prior request to send a resource reservation request conforming to the online signaling protocol by a management device, the reservation method does not include no step of sending said resource reservation confirmation to other devices upstream of the transition device in the direction of travel of the reservation request on the path between the source device and the receiving device. Advantageously, this reservation method also comprises the following steps: receiving a resource reservation request according to the on-line signaling protocol; determining whether the resource reservation request conforming to the online signaling protocol corresponds to a content for which a resource reservation request complying with the centralized signaling protocol by a management device has already been received; if so, the reservation method does not include a step of sending the resource reservation request according to the on-line signaling protocol to the devices downstream of the transition device in the direction of travel of the request for reservation on the path between the source device and the receiving device. Preferably, if the resource reservation request conforming to the online signaling protocol corresponds to a content for which a resource reservation request complying with the centralized signaling protocol by a management device has already been received, the method also includes sending a positive report regarding the resource reservation request compliant with the online signaling protocol. Preferably, the reservation method also comprises the following steps: receiving a request for the release of a resource that complies with the centralized signaling protocol; determining whether the resource release request corresponds to a content for which a resource reservation request compliant with the online signaling protocol by a management device has been previously received for at least one device of the second type; in the affirmative, sending an on-line signaling protocol compliant resource release request to said at least one device of the second type. Advantageously, the centralized signaling protocol is the UPnP protocol and the online signaling protocol is the SBM protocol. The invention also relates to a computer program product comprising program code instructions for executing the steps of FIG. at least one of the reservation methods as previously described when said program is executed on a computer.
L'invention concerne également un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre au moins l'un des procédés de réservation tels que précédemment décrits. Dans un autre mode de réalisation, l'invention concerne un dispositif gestionnaire apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur à travers ledit réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif gestionnaire étant un dispositif dudit premier type. Ce dispositif gestionnaire comprend : - des moyens de détection d'au moins un dispositif du second type compris sur le chemin de transmission et qui n'est pas compatible avec le protocole de signalisation centralisé; - des moyens de détermination d'un dispositif de transition qui est un dispositif du premier type et qui est compatible avec le protocole de signalisation en ligne ; et - des moyens d'envoi au dispositif de transition d'une demande d'envoi audit ou auxdits dispositif(s) du second type détectés d'une requête de 20 réservation de ressource conforme au protocole de signalisation en ligne. Avantageusement, le dispositif gestionnaire comprend également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Selon une variante avantageuse, le dispositif gestionnaire comprend 25 également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Selon une caractéristique avantageuse, le dispositif gestionnaire comprend également des moyens de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec d[e la réservation de ressource pour la transmission du contenu. Dans un autre mode de réalisation, l'invention concerne un dispositif de transition apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur à travers ledit réseau de communication, ledit réseau comprenant : - au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif de transition étant un dispositif dudit premier type, et qui est aussi compatible avec le protocole de signalisation en ligne. Ce dispositif comprend : des moyens de réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; des moyens d'envoi de ladite requête audit dispositif du second type. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un schéma d'un réseau local dans lequel peut être mis en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention ; - la figure 2 présente un schéma d'un équipement générique mettant en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention ; la figure 3 illustre la mise en oeuvre du procédé de réservation de ressource selon un mode de réalisation de l'invention lors de la transmission avec QoS d'un contenu cO sur un chemin de transmission du réseau local de la figure 1 ; la figure 4 présente les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le QosManager, lors de la transmission de cO ; - la figure 5 présente les étapes principales d'un algorithme de détermination du chemin de transmission de cO mis en oeuvre par le QosManager ; la figure 6 présente les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par un pont sur lechemin de transmission de cO, lors de la transmission de cO ; - les figures 7A et 7B présentent un algorithme des étapes du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont lors de la réception de messages provenant du réseau local relatifs aux protocoles UPnP QoS ou SBM. 6. Description d'un mode de réalisation de l'invention Dans la suite, on se place, dans le cadre d'un mode de réalisation de l'invention, dans un réseau local 100 (dont un schéma est illustré en figure 1) qui comprend notamment : des équipements conformes à un protocole de signalisation centralisée, par exemple le protocole UPnP QoS (dits équipements d'un premier type) ; -des équipements qui ne mettent pas en oeuvre le protocole UPnP QoS mais qui mettant en oeuvre un protocole de signalisation en ligne, par exemple le protocole SBM (dits équipements d'un second type). Bien entendu, les protocoles de signalisation centralisé et en ligne peuvent être tout autre protocole que les protocoles UPnP QoS et SBM. Notamment il est possible de considérer le protocole Ethernet AV à la place du protocole SBM. Le protocole Ethernet AV est une évolution de la norme IEEE 802.3 pour les réseaux locaux avec support QoS pour la transmission de flots de contenus audio/vidéo. Ce protocole est en cours de spécification par le sousgroupe Audio/Video Bridging Task Group du groupe de travail IEEE 802.1. The invention also relates to a storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement at least one of the reservation methods as described above. In another embodiment, the invention relates to a manager device able to reserve the resources of devices of a communication network, using a centralized signaling protocol, in the context of the transmission of a content. data on a transmission path between a source device and a receiver device through said communication network, said network comprising: at least one device compatible with a centralized signaling protocol, said device of a first type; and at least one device compatible with an online signaling protocol, said device of a second type, said management device being a device of said first type. This management device comprises: means for detecting at least one device of the second type included on the transmission path and which is not compatible with the centralized signaling protocol; means for determining a transition device which is a device of the first type and which is compatible with the on-line signaling protocol; and means for sending to the transition device a request for sending to said detected second type device (s) of a resource reservation request conforming to the on-line signaling protocol. Advantageously, the management device also comprises: means for selecting, on the transmission path, a common transition device for at least two devices of the second type detected. According to an advantageous variant, the manager device also comprises: means for selecting, on the transmission path, a common transition device for at least two devices of the second type detected. According to an advantageous characteristic, the management device also comprises means for receiving a report from the one or more transition device (s) indicating the success or failure of the resource reservation for the transmission of the content. In another embodiment, the invention relates to a transition device able to reserve the resources of devices of a communication network, by means of a centralized signaling protocol, in the context of the transmission of a data content on a transmission path between a source device and a receiver device through said communication network, said network comprising: - at least one device compatible with a centralized signaling protocol, said device of a first type; and at least one device compatible with an online signaling protocol, said device of a second type, said transition device being a device of said first type, and which is also compatible with the on-line signaling protocol. This device comprises: means for receiving a request to send a resource reservation request conforming to the on-line signaling protocol to a device of said second type, located on the transmission path and which is not compatible with the centralized signaling protocol; means for sending said request to said device of the second type. 5. List of Figures Other features and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the accompanying drawings, among which: Figure 1 shows a diagram of a local network in which can be implemented the resource reservation method according to an embodiment according to the invention; FIG. 2 shows a diagram of a generic device implementing the resource reservation method according to an embodiment according to the invention; FIG. 3 illustrates the implementation of the resource reservation method according to one embodiment of the invention during the transmission with QoS of a content cO on a transmission path of the local network of FIG. 1; FIG. 4 presents the main steps of the resource reservation method according to one embodiment of the invention, implemented by the QosManager, during the transmission of OC; FIG. 5 presents the main steps of an algorithm for determining the OC transmission path implemented by the QosManager; FIG. 6 presents the main steps of the resource reservation method according to one embodiment of the invention, implemented by a bridge on the OO transmission path, during the transmission of OC; FIGS. 7A and 7B show an algorithm of the steps of the resource reservation method according to one embodiment of the invention, implemented by the bridge when receiving messages originating from the local network relating to UPnP QoS or SBM protocols. . 6. DESCRIPTION OF AN EMBODIMENT OF THE INVENTION In the following, in the context of one embodiment of the invention, a LAN 100 (a diagram of which is illustrated in FIG. which notably comprises: equipment conforming to a centralized signaling protocol, for example the UPnP QoS protocol (so-called equipment of a first type); equipment which does not implement the UPnP QoS protocol but which implements an on-line signaling protocol, for example the SBM protocol (so-called equipment of a second type). Of course, the centralized and online signaling protocols can be any other protocol than the UPnP QoS and SBM protocols. In particular it is possible to consider the Ethernet protocol AV instead of the SBM protocol. The Ethernet AV protocol is an evolution of the IEEE 802.3 standard for local networks with QoS support for the transmission of audio / video content streams. This protocol is being specified by the Audio / Video Bridging Task Group subgroup of the IEEE 802.1 Working Group.
Le réseau local 100 est par exemple un réseau Ethernet mettant en oeuvre le protocole IEEE 802 et permet de mettre en œuvre des communications de type UPnP QoS (au moins entre certains équipements) pour lesquelles chaque équipement UPnP QoS (ou équipement mettant en oeuvre le standard UPnP QoS) du réseau est identifié et communique périodiquement la description de ses services. Le réseau local 100 comprend à la fois des équipements terminaux qui sont visibles par l'utilisateur (par exemple des terminaux multimédia du réseau local 100 qui sont directement contrôlés par l'utilisateur) et des équipements d'infrastructure réseau permettant la liaison entre ces équipements terminaux. The local network 100 is for example an Ethernet network implementing the IEEE 802 protocol and makes it possible to implement UPnP QoS-type communications (at least between certain equipment) for which each UPnP QoS equipment (or equipment implementing the standard UPnP QoS) of the network is identified and periodically communicates the description of its services. The local area network 100 includes both terminal equipments that are visible to the user (for example, multimedia terminals of the local network 100 that are directly controlled by the user) and network infrastructure equipment enabling the connection between these equipments. terminals.
On notera que le réseau local 100 peut aussi bien être un réseau domestique qu'un réseau local d'entreprise, constitué partiellement ou totalement de segments sans fil (par exemple conformes aux normes Wifi ou Bluetooth , marques déposées). La catégorie des équipements terminaux comprend notamment : - un serveur de flot multimédia 110 répondant à la norrne UPnP AV (que l'on appelle également UPnP Media Server ) qui est notamment capable d'émettre en continu des contenus vidéo suivant des protocoles réseau et qui fonctionne en mode connecté (par exemple via le protocole HTTP sur IP) et/ou en mode non connecté (par exemple via le protocole RTP sur le protocole UDP). Ce serveur peut notamment être un ordinateur personnel, un lecteur DVD ou une caméra possédant une connectivi.té IP ; un terminal client 120, disposant d'un service UPnP Media Renderer , qui peut notamment être un ordinateur personnel ou un écran de téléviseur apte à afficher les flots multimédia en provenance du serveur 110 ; - un poste de contrôle UPnP 130, qui peut notamment être un ordinateur personnel, une tablette PC, un assistant personnel (ou PDA), une télécommande proposant à l'utilisateur une sélection d'équipements UPnP sur le réseau local 100 et des contenus multimédia à jouer ; des ordinateurs tels que représentés par H3 et H4. It will be noted that the local network 100 may as well be a home network or a local business network, made up partially or totally of wireless segments (for example compliant with Wifi or Bluetooth standards, registered trademarks). The category of terminal equipment includes: a multimedia stream server 110 corresponding to the standard UPnP AV (also known as UPnP Media Server) which is notably capable of streaming video contents according to network protocols and which operates in connected mode (for example via the HTTP over IP protocol) and / or in unconnected mode (for example via the RTP protocol over the UDP protocol). This server may especially be a personal computer, a DVD player or a camera with IP connectivity; a client terminal 120, having a UPnP Media Renderer service, which may especially be a personal computer or a TV screen capable of displaying the multimedia streams from the server 110; a UPnP 130 control station, which may notably be a personal computer, a tablet PC, a personal assistant (PDA), a remote control providing the user with a selection of UPnP equipment on the local network 100 and multimedia contents to play ; computers as represented by H3 and H4.
La catégorie des équipements d'infrastructure réseau comprend notamment des équipements d'interconnexion 140 qui peuvent notamment être : des équipements de routage de niveau 2 (par exemple des commutateurs ou switches en anglais) ; des ponts entre deux segments du réseau (par exemple, un ordinateur disposant de deux cartes réseau constitue un pont). Ces équipements d'infrastructure réseau 140 implémentent généralement des protocoles de signalisation en ligne QoS tel que le protocole SBM précité (tel que le commutateur 140B ci-après décrit en relation avec la figure 3). Ils peuvent également implémenter le standard UPnP QoS (tel que par exemple le pont 140A ci-après décrit en relation avec la figure 3). Un pont est un matériel d'interconnexion qui relie deux segments Ethernet. A chacun des segments auquel est connecté un pont, est associée une table des adresses MAC des équipements terminaux de ce segment qui est gérée par le pont. Une telle table est construite par le pont à l'aide d'un processus d'apprentissage dans lequel, à chaque émission d'une trame par un équipement, le pont stocke dans la table l'adresse MAC de l'équipement terminal en regard avec le segment concerné. Ces tables permettent au pont de router les trames. En effet, lorsque le pont reçoit une trame provenant de son premier segment, il relaye la trame vers son second segment dans l'un des cas suivants : - l'adresse du destinataire de la trame correspond à une adresse du second segment ; - il s'agit d'une adresse de diffusion (ou broadcast en anglais) ; l'adresse n'est pas connue par le pont. Un commutateur est considéré comme un pont qui a plus de deux interfaces. The category of network infrastructure equipment includes in particular interconnection equipment 140 which may notably be: level 2 routing equipment (for example switches or switches in English); bridges between two segments of the network (for example, a computer with two network cards is a bridge). These network infrastructure equipment 140 generally implement QoS in-line signaling protocols such as the aforementioned SBM protocol (such as the switch 140B hereinafter described in connection with FIG. 3). They can also implement the UPnP QoS standard (such as, for example, the bridge 140A hereinafter described with reference to FIG. 3). A bridge is an interconnect hardware that connects two Ethernet segments. Each of the segments to which a bridge is connected is associated with a table of MAC addresses of the terminal equipments of this segment which is managed by the bridge. Such a table is constructed by the bridge using a learning process in which, each time a frame is transmitted by a device, the bridge stores in the table the MAC address of the terminal equipment next to it. with the segment concerned. These tables allow the bridge to route the frames. Indeed, when the bridge receives a frame from its first segment, it relays the frame to its second segment in one of the following cases: the destination address of the frame corresponds to an address of the second segment; - it is a broadcast address (or broadcast in English); the address is not known by the bridge. A switch is considered a bridge that has more than two interfaces.
Des services conformes au standard UPnP QoS peuvent être embarqués dans certains des équipements du réseau local 100. On considère dans la suite que les serveur de flot multimédia 110, terminal client 120 et poste de contrôle UPnP 130 disposent du service UPnP QosDevice (on les désignera dans la suite par équipements QosDevice). Par ailleurs, le réseau local 100 comprend un service UPnP QosManager . Ce service UPnP QosManager peut être embarqué dans n'importe quel équipement du réseau local 100 disposant préférentiellement d'une plateforme matérielle identique à celle de l'équipement générique 200 décrit ci- après en relation avec la figure 2. Par exemple, il est embarqué dans un équipement 150, que l'on désigne ci-après par QosManager 150 (autrement appelé dispositif gestionnaire dans le cadre de la réservation de ressource pour c0). Le service UPnP QosManager est un service unique pour le réseau local 100. Le standard UPnP QoS précité définit plus précisément les procédures à suivre pour choisir le QosManager actif si plusieurs services sont en concurrence. Dans la suite, on décrit le procédé de réservation de ressource selon un mode de réalisation de l'invention, dans le cadre de la transmission d'un contenu de données c0 sur un chemin de transmission entre un dispositif source (serveur de flot multimédia 110) et un dispositif récepteur (terminal client 120) appartenant au réseau local 100. Ainsi lors de la sélection du contenu multimédia c0 par le poste de contrôle 130, un message UPnP est envoyé au terminal client 120 en vue d'avertir son service Media Renderer du type du contenu multimédia c0 à recevoir (par exemple au moyen d'un message de type Avt_SetAvTransportUri désigné par message 1). En parallèle, le poste de contrôle 130 demande au QosManager 150 de préparer les ressources QoS nécessaires au bon acheminement du contenu multimédia c0 entre le serveur de flot multimédia 110 et le terminal client 120 (par exemple au moyen d'un message de type QM_RequestTrafficQos désigné par message 2). Le QosManager 150 cherche à obtenir le chemin à travers le réseau par lequel passera le contenu multimédia c0, afin de déterminer quels sont les équipements QosDevice pour les informer de la réservation de ressources pour ce contenu c0 (message 3). Si tous ces équipements QosDevice admettent les caractéristiques QoS du contenu c0, le QosManager 150 acquittera la requête du poste de contrôle 130, et ce dernier autorisera le terminal client 120 à jouer le contenu multimédia c0 (par exemple au moyen d'un message de type Avt_Play désigné par message 4). Services conforming to the UPnP QoS standard can be embedded in some of the equipment of the local network 100. It is considered in the following that the media stream server 110, the client terminal 120 and the UPnP control station 130 have the UPnP service QosDevice (they will be designated in the following by QosDevice equipment). In addition, the local network 100 includes a UPnP QosManager service. This UPnP service QosManager can be embedded in any equipment of the local network 100 preferably having a hardware platform identical to that of the generic equipment 200 described below in connection with Figure 2. For example, it is embedded in a device 150, hereinafter referred to as QosManager 150 (otherwise referred to as the manager device in the context of the resource reservation for c0). The UPnP QosManager service is a unique service for Local Area Network 100. The above-mentioned UPnP QoS standard defines more precisely the procedures to be followed to choose the active QosManager if several services compete. In the following, the resource reservation method according to one embodiment of the invention is described, in the context of the transmission of a data content c0 on a transmission path between a source device (multimedia stream server 110). ) and a receiving device (client terminal 120) belonging to the local network 100. Thus during the selection of the multimedia content c0 by the control station 130, a UPnP message is sent to the client terminal 120 in order to warn its Media Renderer service. the type of multimedia content c0 to receive (for example by means of a message type Avt_SetAvTransportUri designated by message 1). In parallel, the control station 130 requests the QosManager 150 to prepare the QoS resources necessary for the proper routing of the multimedia content c0 between the multimedia stream server 110 and the client terminal 120 (for example by means of a QM_RequestTrafficQos type message designated by message 2). The QosManager 150 looks for the path through the network through which the c0 media content will pass, to determine which QosDevice devices inform them of the resource reservation for that c0 content (message 3). If all these QosDevice equipments admit the QoS characteristics of the content c0, the QosManager 150 will acknowledge the request of the control station 130, and the latter will allow the client terminal 120 to play the multimedia content c0 (for example by means of a message of the type Avt_Play designated by message 4).
Le terminal client 120 enverra alors une requête de lecture du contenu multimédia c0 au serveur de flot multimédia 110 (par exemple par un message de type RTSP afin de recevoir le flot multimédia au format de diffusion RTP). Le procédé de réservation de ressource selon l'invention est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans plusieurs machines du réseau local 100, par exemple dans l'équipement générique 200 décrits notamment ci-après en relation avec la figure 2. On présente, en relation avec la figure 2, un schéma d'un équipement générique 200 mettant en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention. Cet équipement générique 200 (qui peut notamment être un micro-ordinateur ou une station de travail) peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant à l'équipement générique 200 des données multimédia. The client terminal 120 will then send a request to read the multimedia content c0 to the multimedia stream server 110 (for example by a message of the RTSP type in order to receive the multimedia stream in the RTP broadcast format). The resource reservation method according to the invention is implemented in the form of software and / or a plurality of sub-software (including a plurality of algorithms described below) which is (are) executed ( s) in several machines of the local network 100, for example in the generic equipment 200 described in particular below with reference to FIG. 2. In connection with FIG. 2, a diagram of a generic equipment 200 implementing implement the resource reservation method according to an embodiment according to the invention. This generic equipment 200 (which may especially be a microcomputer or a workstation) may in particular be connected to any means of storing images, videos, or sounds connected to a graphics card and delivering to the generic equipment 200 multimedia data.
Ainsi, l'équipement générique 200 comporte un bus de communication 202 auquel sont reliés : une unité centrale de traitement 203 (qui est par exemple un microprocesseur référencé CPU) ; une mémoire morte 204 référencée ROM, pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; une mémoire vive 206 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des logiciel(s) précité(s) ; un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec le ou les logiciel(s) selon l'invention, à l'aide d'un clavier 210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique ; une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau local 100, l'interface étant apte à transmettre et à recevoir des données. L'équipement générique 200 comprend également (mais ceci est optionnel) : un disque dur 212 pouvant comporter le ou les logiciel(s) Prog ; - un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter conformément au procédé de réservation de ressource selon l'invention. Le bus de communication 202 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans l'équipement générique 200 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 202, l'unité centrale 203 est susceptible de communiquer des instructions à tout dispositif inclus dans l'équipement générique 200 directement ou par l'intermédiaire d'un autre dispositif de l'équipement générique 200. Thus, the generic equipment 200 comprises a communication bus 202 to which are connected: a central processing unit 203 (which is for example a microprocessor referenced CPU); a read-only memory 204 referenced ROM, which may comprise the aforementioned software (s) and referenced (s) Prog; a random access memory 206 (RAM referenced cache memory), comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned software (s); a screen 208 for viewing data and / or to act as a graphical interface with the network administrator who can interact with the software (s) according to the invention, using a keyboard 210 or any other means such as a pointing device, such as for example a mouse 211 or an optical pen; a communication interface 218 connected to a distributed communication network 220, for example the local network 100, the interface being able to transmit and receive data. The generic equipment 200 also includes (but this is optional): a hard disk 212 may include the software (s) Prog; a floppy disk drive 214 adapted to receive a floppy disk 216 and to read or write to it data processed or to be processed in accordance with the resource reservation method according to the invention. The communication bus 202 allows communication and interoperability between the different devices included in the generic equipment 200 or connected to this equipment. More generally, through the communication bus 202, the central unit 203 is able to communicate instructions to any device included in the generic equipment 200 directly or via another device of the generic equipment 200 .
Le code exécutable de chacun du ou des logiciel(s) précités permettant à l'équipement générique 200 de mettre en oeuvre le procédé de réservation de ressource selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou dans la mémoire morte 204. Selon un premier mode de mise en oeuvre de l'invention, la disquette 216, contient initialement des données ainsi que le code exécutable de chacun du ou des logiciel(s). Ainsi, une fois que ces données et ce code sont lus par l'équipement générique 200, ce dernier le stocke dans son disque dur 212 (ou plus généralement dans tout moyens de stockage de l'équipement 200 tel que la mémoire morte 204). The executable code of each of the aforementioned software (s) enabling the generic equipment 200 to implement the resource reservation method according to the invention can be stored, for example, in the hard disk 212 or in the read-only memory 204. According to a first embodiment of the invention, the floppy disk 216 initially contains data as well as the executable code of each of the software (s). Thus, once this data and this code are read by the generic equipment 200, the latter stores it in its hard disk 212 (or more generally in any storage means of the equipment 200 such as the ROM 204).
Selon un second mode de mise en oeuvre de l'invention, le code exécutable de chacun du ou des logiciel(s) est reçu par l'intermédiaire du réseau local 100, via l'interface de communication 218, pour être lus et stocké sur le disque dur 212 (ou plus généralement dans tout moyens de stockage de l'équipement 200 tel que la mémoire morte 204) par l'équipement générique 200. According to a second embodiment of the invention, the executable code of each of the software (s) is received via the local network 100, via the communication interface 218, to be read and stored on the hard disk 212 (or more generally in any storage means of the equipment 200 such as the read-only memory 204) by the generic equipment 200.
Bien entendu, au lieu de la disquette 216, on peut mettre en oeuvre tout support d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser le ou les logiciel(s) selon l'invention (par exemple, un disque compact (CD-ROM) ou une carte mémoire). Of course, instead of the floppy disk 216, it is possible to implement any information medium that can be read by a computer or by a microprocessor, whether integrated or not, possibly removable, is adapted to store the software (s) ) according to the invention (for example, a compact disc (CD-ROM) or a memory card).
L'unité centrale 203 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des logiciel(s) selon l'invention. Lors de la mise sous tension, le ou les logiciels qui sont stockés dans une mémoire non volatile (par exemple le disque dur 212 ou la mémoire morte 204), sont transférés dans la mémoire vive 206 qui contiendra alors le code exécutable du ou des logiciel(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé de réservation de ressource selon l'invention. Selon un troisième mode de mise en oeuvre de l'invention, l'équipement générique est un appareil programmé qui contient alors le code du ou des logiciel(s) selon l'invention, par exemple figé dans un circuit intégré à application spécifique (tel qu'un circuit ASIC). On illustre, en relation avec la figure 3, la mise en oeuvre du procédé de réservation de ressource selon un mode de réalisation de l'invention lors de la transmission avec QoS de c0 sur un chemin (ou trajet physique emprunté) allant du serveur de flot multimédia 110 (ou dispositif source) vers le terminal client 120 (ou dispositif récepteur) dans le réseau local 100 de la figure 1. On rappelle que le serveur de flot multimédia 110 et le terminal client 120 sont tous deux des équipements QosDevice (c'est-à-dire qu'ils implémentent un service QosDevice conforme au standard UPnP QoS). Entre ces deux équipements sont disposés deux équipements d'interconnexion 140A et 140B (qui peuvent être notamment des équipements de routage de niveau 2 ou des ponts). Ainsi, le chemin de transmission comprend dans le présent cas particulier les dispositifs source 110, récepteur 120 et les deux équipements d'interconnexion 140A et 140B. The central unit 203 controls and directs the execution of the instructions or portions of software code of the software (s) according to the invention. When powering up, the software or software that is stored in a non-volatile memory (for example the hard disk 212 or the read-only memory 204), are transferred into the random access memory 206 which will then contain the executable code of the software or software (s) according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the resource reservation method according to the invention. According to a third embodiment of the invention, the generic equipment is a programmed apparatus which then contains the code of the software (s) according to the invention, for example fixed in an integrated circuit with a specific application (such as as an ASIC circuit). FIG. 3 illustrates the implementation of the resource reservation method according to one embodiment of the invention during transmission with QoS of c0 on a path (or borrowed physical path) from the server of multimedia stream 110 (or source device) to the client terminal 120 (or receiving device) in the local network 100 of FIG. 1. It is recalled that the multimedia stream server 110 and the client terminal 120 are both QosDevice equipments (c). that is, they implement a QosDevice service conforming to the UPnP QoS standard). Between these two devices are arranged two interconnection equipment 140A and 140B (which may be including level 2 routing equipment or bridges). Thus, the transmission path in this particular case comprises the source devices 110, receiver 120 and the two interconnection equipment 140A and 140B.
L'équipement d'interconnexion 140A est par exemple un pont qui conforme au standard UPnP QoS et qui implémente un service QosDevice conforme au mode de réalisation de l'invention. L'équipement d'interconnexion 140B est un commutateur n'implémentant pas de service UPnP mais est conforme avec le protocole de signalisation en ligne SBM. Il s'agit par exemple d'un commutateur classique commercialisé sous la référence CISCO Catalyst de la série 6000. Tel qu'indiqué précédemment en relation avec la figure 1, le service UPnP QosManager est embarqué dans le QosManager 150 qui est identique à l'équipement générique 200 illustré en figure 2. The interconnection equipment 140A is for example a bridge which complies with the UPnP QoS standard and which implements a QosDevice service according to the embodiment of the invention. The 140B interconnect equipment is a switch that does not implement a UPnP service but is compliant with the SBM inline signaling protocol. This is for example a conventional switch marketed under the reference CISCO Catalyst 6000 series. As indicated above in connection with Figure 1, the UPnP QosManager service is embedded in the QosManager 150 which is identical to the generic equipment 200 illustrated in Figure 2.
Le QosManager 150 communique avec les équipements QosDevice 110 et 120 conformément au standard UPnP QoS. Le QosManager 150 reçoit du poste de contrôle 130 les caractéristiques du flot du contenu multimédia c0 ainsi que les adresses des équipements QosDevice 110 et 120. Conformément à la politique de QoS active sur le réseau local 100 et qui est conforme au mode de réalisation de l'invention, les caractéristiques du flot du contenu multimédia c0 permettent de déterminer le type de ressources QoS à mettre en oeuvre dans le cadre de la transmission de ce contenu c0. Dans le cas où la transmission du contenu multimédia c0 est qualifiée de service au mieux (ou Best Effort en anglais), alors, il n'est pas nécessaire de mettre en oeuvre le procédé de réservation de ressource selon le mode de réalisation de l'invention pour la transmission de ce contenu c0. Cependant, le protocole d'admission de ce contenu c0 ne doit pas perturber les transmissions QoS des autres contenus en cours. Dans le cas où le flot du contenu c0 (qui peut être de la vidéo ou de la visiophonie) présente des caractéristiques précises concernant le délai de délivrance garanti, ceci impose une mise en oeuvre d'une réservation de ressource QoS dédiée à ce contenu c0. On rappelle ci-après comment est caractérisé un flot d'un contenu multimédia. La QoS au niveau d'un réseau se décline en quatre paramètres : le débit, la latence, la gigue et la perte. Le débit communément appelé "bande passante" représente la ressource de transmission que nécessite le flot du contenu. La gestion de la bande passante est un élément important pour la garantie de QoS. La latence est définie par le délai de transfert de bout-en-bout (du dispositif source vers le dispositif récepteur) d'un paquet du contenu. Les applications interactives comme la téléphonie présentent une latence maximum tolérable. Si un paquet subit un retard important, ce retard est équivalent pour ces applications à une perte de données. La gigue correspond aux variations de latence des paquets du contenu. La cause principale de l'apparition de la gigue dans la transmission du contenu provient des changements d'intensité de trafic dans les commutateurs. La perte de paquets se produit lorsqu'il y a des erreurs d'intégrité sur les données. La perte de paquet se produit aussi lorsque l'intensité du trafic sur les commutateurs devient supérieure à leur capacité d'écoulement. Elle est une indication de congestion. Afin de limiter cette congestion, la méthode d'isolation des flots de contenus consiste à fournir aux flots demandant une QoS particulière une protection contre les flots perturbateurs. Ainsi, le procédé de réservation selon le mode de réalisation de l'invention ne vise pas à détailler comment se fait la caractérisation d'un flot multimédia, mais présenter une solution afin d'acheminer de bout en bout un flot dit critique avec des garanties de QoS strictes. Afin de caractériser un flot, le standard RFC-2215 définit un objet Token_Bucket_Tspec regroupant les notions précédentes, et qui sera par exemple utilisé par la suite. Les équipements QosDevice 110, 120 et 140A, pilotés par le QosManager 150, sont aptes, conformément à l'invention, à adopter une gestion locale de leurs ressources physiques conforme au protocole de signalisation en ligne SBM. Grâce à l'invention, un équipement QosDevice (par exemple l'équipement d'interconnexion 140A) est capable de diriger une requête de réservation de ressource vers le commutateur 140B n'implémentant pas de service UPnP QoS. De plus, comme expliqué ci-après, en relation avec la figure 4, le QosManager 150 possède des moyens particuliers de détection des équipements qui n'implémentent pas le protocole de signalisation centralisé UPnP QoS tels que le commutateur 140B, et des moyens d'obtention de l'équipement QosDevice idéal et apte à s'adresser au commutateur 140B. Le commutateur 140B met en oeuvre le protocole de signalisation en ligne SBM (RFC-2814) précité et, du fait qu'il est connecté sur le réseau Ethernet, il implémente la norme IEEE 802.1-D. The QosManager 150 communicates with QosDevice 110 and 120 equipment according to the UPnP QoS standard. The QosManager 150 receives from the control station 130 the characteristics of the stream of the multimedia content c0 as well as the addresses of the QosDevice devices 110 and 120. In accordance with the active QoS policy on the local network 100 and which complies with the embodiment of the Invention, the characteristics of the stream of the multimedia content c0 make it possible to determine the type of QoS resources to be used in the context of the transmission of this content c0. In the case where the transmission of the multimedia content c0 is qualified as Best Service (or Best Effort in English), then, it is not necessary to implement the resource reservation method according to the embodiment of the invention. invention for transmitting this content c0. However, the protocol for the admission of this content c0 must not disturb the QoS transmissions of the other contents in progress. In the case where the content stream c0 (which may be video or video telephony) has specific characteristics regarding the guaranteed delivery time, this requires implementation of a QoS resource reservation dedicated to this content c0 . The following is a description of a flow of multimedia content. QoS at the network level is divided into four parameters: throughput, latency, jitter and loss. The rate commonly referred to as "bandwidth" represents the transmission resource that the flow of content requires. Bandwidth management is an important part of the QoS warranty. Latency is defined as the end-to-end transfer delay (from the source device to the receiving device) of a packet of the content. Interactive applications such as telephony have a maximum tolerable latency. If a packet suffers a significant delay, this delay is equivalent for these applications to a loss of data. Jitter is the latency variations of the content packets. The main cause of the appearance of jitter in the transmission of content comes from changes in traffic intensity in the switches. Packet loss occurs when there are integrity errors on the data. Packet loss also occurs when the intensity of the traffic on the switches becomes greater than their flow capacity. It is an indication of congestion. In order to limit this congestion, the method of isolating the content streams consists in providing the streams requesting a particular QoS with protection against disruptive flows. Thus, the reservation method according to the embodiment of the invention is not intended to detail how the characterization of a multimedia stream, but to present a solution for routing end-to-end a so-called critical flow with guarantees strict QoS. In order to characterize a stream, the RFC-2215 standard defines a Token_Bucket_Tspec object grouping the preceding notions, which will be used for example later. The QosDevice 110, 120 and 140A devices, controlled by the QosManager 150, are able, according to the invention, to adopt a local management of their physical resources in accordance with the SBM on-line signaling protocol. Thanks to the invention, a QosDevice equipment (for example the interconnection equipment 140A) is capable of directing a resource reservation request to the switch 140B that does not implement a UPnP QoS service. In addition, as explained below, in connection with FIG. 4, the QosManager 150 has particular means of detecting devices that do not implement the UPnP QoS centralized signaling protocol such as the switch 140B, and means for obtaining the ideal QosDevice equipment suitable for addressing the 140B switch. The switch 140B implements the aforementioned SBM online signaling protocol (RFC-2814) and, because it is connected to the Ethernet network, implements the IEEE 802.1-D standard.
On rappelle que la norme IEEE 802.1D définit un protocole de Spanning Tree (ci-après désigné par protocole STP pour Spanning Tree Protocol ) et un algorithme associé. Le protocole STP est un protocole de communication de couche 2 permettant de supprimer les chemins redondants en construisant un arbre à partir d'un graphe cyclique. Il est ainsi mis en oeuvre par les ponts et commutateurs pour : découvrir les boucles sur le réseau ; créer une topologie logique sans boucles en bloquant certains trajets ; -contrôler la disponibilité de la topologie logique ; - basculer sur une topologie logique de secours. It is recalled that the IEEE 802.1D standard defines a spanning tree protocol (hereinafter referred to as STP protocol for Spanning Tree Protocol) and an associated algorithm. STP is a Layer 2 communication protocol that removes redundant paths by building a tree from a cyclic graph. It is thus implemented by bridges and switches to: discover loops on the network; create a logical topology without loops by blocking certain paths; -control the availability of the logical topology; - switch to a backup logical topology.
Le protocole STP utilise une trame spécifique baptisée BPDU (pour Bridge Protocol Data Unit ) et une adresse multicast qu'en principe seuls les commutateurs écoutent (communications transparentes vis-à-vis des stations finales, qui ne connaissent pas la topologie du réseau). Le programme exécuté dans chaque dispositif de commutation utilisant ce protocole est appelé l'algorithme Spanning Tree (ci-après désigné par algorithme STP). Cet algorithme calcule la topologie du réseau et trouve le meilleur chemin entre deux stations. On présente, en relation avec la figure 4, les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le QosManager 150 (disposant du service UPnP QosManager ), lors de la transmission avec QoS du contenu c0 du serveur de flot multimédia 110 (dispositif source) vers le terminal client 120 (dispositif récepteur). On rappelle que le service UPnP QosManager peut être embarqué dans n'importe quel équipement du réseau local 100 disposant d'une plateforme matérielle identique à celle de l'équipement générique 200 de la figure 2. Le QosManager 150 est unique dans le réseau à un instant donné mais n'est pas nécessairement situé sur le chemin du flot multimédia du contenu c0 (ou chemin de transmission du contenu c0) pour contrôler la QoS de ce flot. Une tache de fond 470 est exécutée continuellement, et consiste à mettre en oeuvre des étapes 480 et 490. Ces deux étapes 480 et 490 ont pour but de mettre à jour régulièrement les données récupérées du réseau local 100. Dans l'étape 480, le QosManager 150 met en oeuvre les algorithmes spécifiés dans la norme IEEE-802.1D permettant de recueillir la topologie du réseau Ethernet 100. The STP protocol uses a specific frame called BPDU (Bridge Protocol Data Unit) and a multicast address that in principle only the switches listen (transparent communications vis-à-vis the end stations, which do not know the topology of the network). The program executed in each switching device using this protocol is called the Spanning Tree algorithm (hereinafter referred to as STP algorithm). This algorithm calculates the network topology and finds the best path between two stations. In relation to FIG. 4, the main steps of the resource reservation method according to one embodiment of the invention, implemented by the QosManager 150 (having the UPnP QosManager service), are presented when transmitting with QoS. content c0 of the multimedia stream server 110 (source device) to the client terminal 120 (receiving device). Recall that the UPnP QosManager service can be embedded in any equipment of the local network 100 having a hardware platform identical to that of the generic equipment 200 of Figure 2. The QosManager 150 is unique in the network to one given moment but is not necessarily located on the path of the multimedia flow of content c0 (or content transmission path c0) to control the QoS of this stream. A background spot 470 is executed continuously, and consists in implementing steps 480 and 490. These two steps 480 and 490 are intended to regularly update the data retrieved from the local network 100. In step 480, the QosManager 150 implements the algorithms specified in the IEEE-802.1D standard for collecting the topology of the Ethernet 100 network.
Selon cette norme IEEE-802.1D, les équipements d'interconnexion 140A et 140B se communiquent la topologie Spanning Tree en échangeant des messages de configuration BPDU (pour Bridge Protocol Data Unit ). Ces messages BPDU contiennent notamment des informations relatives à l'adresse de l'équipement d'interconnexion et aux adresses, priorités et coûts de chacun de ses ports. According to this IEEE-802.1D standard, the interconnection equipment 140A and 140B communicate the Spanning Tree topology by exchanging BPDU (Bridge Protocol Data Unit) configuration messages. These BPDU messages contain information relating to the address of the interconnection equipment and the addresses, priorities and costs of each of its ports.
Le QosManager 150 a souscrit à la réception de ces messages BPDU. Une telle souscription peut être effectuée par l'intermédiaire du protocole GMRP (pour GARP Multicast Registration Protocol qui est défini par le protocole IEEE 802.1P). Les messages BPDU sont ainsi obtenus en écoutant sur l'adresse MAC de diffusion nommée "Bridge Group Address". Dans l'étape 490, le QosManager 150 écoute les messages de découverte de services et de machines dans le réseau comprenant les équipements QosDevice implémentant le standard UPnP QoS. Le protocole SSDP (pour Simple Service Discovery Protocol ) spécifié par le standard UPnP utilise le protocole HTTP sur le protocole UDP. Avantageusement, cette étape 490 peut être considérée comme étant une étape d'un poste de contrôle UPnP spécifique au recensement des services UPnP QosDevice du réseau. Les informations échangées entre les équipements QosDevice et le poste de contrôle sont limitées aux messages de détection fournissant des informations de base sur les équipements et leurs services ainsi qu'une URL de description qui peut être utilisée pour rassembler des informations supplémentaires sur les équipements et leurs services : une fois un service découvert, il est possible de récupérer le fichier XML décrivant précisément les fonctionnalités de ce service. The QosManager 150 has subscribed to the receipt of these BPDU messages. Such a subscription can be made via the GMRP protocol (for GARP Multicast Registration Protocol which is defined by the IEEE 802.1P protocol). BPDU messages are thus obtained by listening on the broadcast MAC address named "Bridge Group Address". In step 490, the QosManager 150 listens for service and machine discovery messages in the network including QosDevice devices implementing the UPnP QoS standard. The SSDP protocol (for Simple Service Discovery Protocol) specified by the UPnP standard uses the HTTP protocol on the UDP protocol. Advantageously, this step 490 may be considered as a step of a UPnP checkpoint specific to the census of UPnP QosDevice services of the network. The information exchanged between the QosDevice equipment and the control station is limited to detection messages providing basic information about the equipment and their services as well as a description URL that can be used to gather additional information on the equipment and its associated equipment. services: once a service is discovered, it is possible to retrieve the XML file describing precisely the functionalities of this service.
Selon une variante de ce mode de réalisation, dans cette étape 490, le QosManager 150 émet des requêtes de découverte relatives au service UPnP QosDevice , afin que les équipements implémentant ce service se fassent connaître. En effet, afin de limiter le nombre de messages SSDP, seuls les changements sont théoriquement envoyés sur le réseau local 100. According to a variant of this embodiment, in this step 490, the QosManager 150 issues discovery queries relating to the UPnP service QosDevice, so that the equipment implementing this service becomes known. Indeed, in order to limit the number of SSDP messages, only the changes are theoretically sent on the local network 100.
On notera que le protocole SSDP est cité à titre d'exemple, et que tout autre protocole d'avertissement de modification sur UPnP peut être mis en oeuvre dans le cadre de la présente invention. De manière simple, les résultats issus de cette étape 490 consistent en la mise à jour régulière d'une liste d'équipements UPnP disposant de service UPnP QosDevice . It should be noted that the SSDP protocol is cited as an example, and that any other change warning protocol on UPnP can be implemented within the scope of the present invention. In a simple way, the results resulting from this step 490 consist of the regular updating of a list of UPnP equipment having UPnP QosDevice service.
Pour chaque équipement QosDevice, le QosManager 150 envoie un message QD_GetPathlnformation (conforme au standard UPnP QoS) afin que cet équipement QosDevice communique au QosManager 150 les adresses MAC connues par lui (les adresses MAC de tous les ports de l'équipement, ainsi que les adresses MAC d'autres équipements connectés à chacun des ports). Ceci correspond à la méthode de détection UPnP classique de la topologie du réseau local, dont les limitations ont préalablement été décrites. Par exemple, en réponse à une telle requête, un équipement QosDevice de type commutateur de niveau 2 avec 4 ports renvoie une description telle que la description de l'annexe 1. For each QosDevice device, the QosManager 150 sends a QD_GetPathlnformation message (conforming to the UPnP QoS standard) so that this QosDevice device communicates to the QosManager 150 the MAC addresses known to it (the MAC addresses of all the ports of the equipment, as well as the MAC addresses of other equipment connected to each of the ports). This corresponds to the traditional UPnP detection method of the local network topology, whose limitations have been previously described. For example, in response to such a request, a QosDevice switch-level device with 4 ports returns a description such as the description in Appendix 1.
Dans une étape 400, le QosManager 150 reçoit une requête d'établissement d'un flot pour le contenu cO avec qualité de service (par exemple un message QM_RequestTrafficQos spécifié par le standard UPnP QoS pour le service QosManager) en provenance du poste de contrôle UPnP 130. La requête contient notamment des informations sur les caractéristiques du flot du contenu cO à transmettre, ainsi que celle du serveur de flot multimédia 110 (dispositif source) et du terminal client 120 (dispositif récepteur). L'annexe 2 donne un exemple d'une telle requête. Grâce aux informations fournies par les champs SourceAddress et DestinationAddress de la requête de l'annexe 2, dans une étape 410, le QosManager 150 obtient les adresses MAC Ethernet du serveur de flot multimédia 110 et du terminal client 120. Pour ce faire, il peut être mis en oeuvre le protocole DNS et/ou le protocole ARP. Ensuite, à partir des informations obtenues lors de la tâche de fond 470, le QosManager 150 calcule le chemin de transmission de niveau 2 du contenu cO depuis le serveur de flot multimédia 110 vers le terminal client 120. Ce calcul utilise les adresses MAC des serveur de flot multimédia 110 et terminal client 120 afin de mettre en oeuvre l'algorithme Spanning Tree. Ainsi ce procédé de réservation de ressource n'a pas pour but l'optimisation du calcul du chemin du Spanning Tree, mais offre la particularité de détecter les équipements QosDevice rencontrés sur le chemin de transmission du contenu cO. Le calcul du chemin de transmission du contenu cO est plus détaillé ci-après, en relation avec la figure 5. A l'issue de l'étape 410, on obtient la liste des équipements d'interconnexion 140 ordonnancés depuis le serveur de flot multimédia 110 vers le terminal client 120 présents sur le chemin de transmission du contenu cO. Une boucle (comprenant des étapes 420, 430, 440 et 450) est alors mise en oeuvre afin de classifier ces équipements 140 selon qu'ils sont des équipements d'interconnexion implémentant le standard UPnP QoS (tel que le pont 140A) ou des équipements d'interconnexion n'implémentant pas le standard UPnP QoS (tel que le commutateur 140B). Dans l'étape 420, le QosManager 150 se focalise sur un équipement d'interconnexion donné dans la liste des équipements d'interconnexion 140 du chemin de transmission de cO, puis dans l'étape 430, il vérifie si cet équipement donné implémente le protocole de signalisation centralisé UPnP' QoS. Si l'équipement donné n'implémente pas le standard UPnP QoS mais implémente le protocole SBM, le QosManager 150 sélectionne sur le chemin de transmission un unique dispositif de transition conforme au protocole UPnP QoS et qui est situé en amont de l'équipement donné dans le sens de parcours du chemin de transmission par la requête de réservation. Puis, dans une étape 450, le QosManager 150 envol, au dispositif de transition, une demande d'envoi d'une requête de réservation de ressources conforme au protocole de signalisation en ligne. Cette demande d'envoi, sous la forme d'un message UPnP classique, ne fait pas partie des actions classiques du standard UPnP QoS. Selon un premier mode de réalisation de l'invention, le QosManager 150 sélectionne un unique dispositif de transition pour l'ensemble des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Ainsi, ce dispositif de transition unique est situé en amont de chacun des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Selon un second mode de réalisation de l'invention, pour chacun des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM le QosManager 150 sélectionne un dispositif de transition distinct. Puis, ledispositif de transition, après avoir reçu la demande d'envoi, envoie la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné. Du fait que l'équipement donné implémente le protocole SBM, cette 10 demande de réservation de ressource est réalisée en envoyant un message SBM PATH en direction du terminal client 120 (destinataire du flot). Selon une variante de l'invention, le QosManager 150 détermine les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné, 15 préalablement à la demande d'envoi faite au dispositif de transition. Le QosManager peut ainsi réordonner les requêtes de réservation adressées aux QosDevices sur le chemin de transmission et envoyer aux QosDevices ainsi déterminés un message QD_SetupTrafficQoS tel que spécifié par le standard UPnP QoS. Ainsi, ces QosDevices recevront en premier lieu la requête de 20 réservation selon le protocole UPnP QoS avant de recevoir la requête de réservation selon le protocole SBM qui sera propagée par l'équipement n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Ceci permet d'éviter les conflits de réservation de ressources lorsque les deux protocoles, UPnP QoS et SBM, sont conjointement utilisés pour un même chemin 25 de transmission. Selon une autre variante de l'invention, le QosManager 150 après avoir déterminé les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné, peut ne plus les prendre en compte à l'étape 420. La réservation de ressources 30 auprès de ces QosDevices s'effectuera alors à la propagation de la requête de réservation selon le protocole SBM par l'équipement n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Le comportement des équipements QosDevices à la réception d'une requête de réservation de ressources selon les protocoles UPnP QoS et SBM sera détaillé lors de la description des figures 7A et 7B. Conformément à la présente invention, préférentiellement mais non exclusivement, outre l'étape 450, le QosManager 150 demande explicitement à l'équipement QosDevice situé en amont de l'équipement donné d'effectuer une confirmation de la réservation des ressources QoS selon la méthode en vigueur dans le protocole de signalisation en ligne SBM. Du fait que l'équipement donné implémente le protocole SBM, cette confirmation est réalisée en envoyant un message SBM RESV en direction du serveur de flot multimédia 110 (source de c0). Selon une variante (non représentée) du mode de réalisation de l'invention, cette confirmation de réservation n'est pas demandée par le QosManager 150 car les équipements QosDevice peuvent automatiquement répondre à la demande de réservation de ressources dans le protocole de signalisation en ligne SBM (tel que cela est expliqué ci-après en relation avec la figure 8). Si l'équipement donné implémente le standard UPnP QoS, alors dans une étape 440, le QosManager 150 transmet à l'équipement donné une requête de QoS classique du standard UPnP QoS (par exemple cette requête est un message QD_SetupTrafficQoS spécifié par le standard UPnP QoS pour le service QosDevice). Avantageusement, le message QD_SetupTrafficQoS est particularisé. In a step 400, the QosManager 150 receives a request to establish a stream for the quality of service OC content (for example a QM_RequestTrafficQos message specified by the UPnP QoS standard for the QosManager service) from the UPnP control station. 130. The request contains in particular information on the characteristics of the flow of the content cO to be transmitted, as well as that of the multimedia stream server 110 (source device) and the client terminal 120 (receiving device). Appendix 2 gives an example of such a request. Using the information provided by the SourceAddress and DestinationAddress fields of the request in Annex 2, in a step 410, the QosManager 150 obtains the Ethernet MAC addresses of the media stream server 110 and the client terminal 120. To do this, it can be implemented the DNS protocol and / or the ARP protocol. Then, from the information obtained during the background task 470, the QosManager 150 calculates the level 2 transmission path of the content cO from the multimedia stream server 110 to the client terminal 120. This calculation uses the MAC addresses of the servers of multimedia stream 110 and client terminal 120 in order to implement the spanning tree algorithm. Thus this resource reservation process is not intended to optimize the calculation of the Spanning Tree path, but has the particularity of detecting the QosDevice equipment encountered on the transmission path of the content cO. The calculation of the transmission path of the content cO is more detailed below, in connection with FIG. 5. At the end of step 410, the list of interconnection devices 140 scheduled from the multimedia stream server is obtained. 110 to the client terminal 120 present on the path of transmission of the content cO. A loop (comprising steps 420, 430, 440 and 450) is then implemented in order to classify these equipments 140 according to whether they are interconnect equipment implementing the UPnP QoS standard (such as the bridge 140A) or equipment. interconnection that does not implement the UPnP QoS standard (such as switch 140B). In step 420, the QosManager 150 focuses on a given interconnection equipment in the list of interconnection equipment 140 of the OC transmission path, then in step 430, it checks whether this given equipment implements the protocol. centralized UPnP 'QoS signaling system. If the given equipment does not implement the UPnP QoS standard but implements the SBM protocol, the QosManager 150 selects on the transmission path a single UPnP QoS-compliant transition device that is located upstream of the equipment given in the direction of travel of the transmission path by the reservation request. Then, in a step 450, the QosManager 150 flies, to the transition device, a request to send a resource reservation request according to the online signaling protocol. This send request, in the form of a standard UPnP message, is not part of the standard actions of the UPnP QoS standard. According to a first embodiment of the invention, the QosManager 150 selects a single transition device for all the equipment of the path not implementing the UPnP QoS standard but only the SBM protocol. Thus, this unique transition device is located upstream of each of the equipment of the path not implementing the standard UPnP QoS but only the SBM protocol. According to a second embodiment of the invention, for each of the equipment of the path not implementing the UPnP QoS standard but only the SBM protocol, the QosManager 150 selects a separate transition device. Then, the transition device, after receiving the sending request, sends the resource reservation request according to the on-line signaling protocol to the given equipment. Since the given equipment implements the SBM protocol, this resource reservation request is made by sending an SBM PATH message to the client terminal 120 (stream recipient). According to a variant of the invention, the QosManager 150 determines the QosDevices that will be impacted by the resource reservation request compliant with the on-line signaling protocol to the given equipment, prior to the request for sending made to the transition device. . The QosManager can thus reorder the reservation requests addressed to the QosDevices on the transmission path and send the QosDevices thus determined a QD_SetupTrafficQoS message as specified by the UPnP QoS standard. Thus, these QosDevices will first receive the reservation request according to the UPnP QoS protocol before receiving the reservation request according to the SBM protocol that will be propagated by the equipment not implementing the UPnP QoS standard but only the SBM protocol. This avoids resource reservation conflicts when the two protocols, UPnP QoS and SBM, are jointly used for the same transmission path. According to another variant of the invention, the QosManager 150 after determining the QosDevices that will be impacted by the resource reservation request compliant with the on-line signaling protocol to the given equipment, may no longer take them into account. Step 420. The reservation of resources 30 with these QosDevices will then be carried out with the propagation of the reservation request according to the SBM protocol by the equipment not implementing the UPnP QoS standard but only the SBM protocol. The behavior of the QosDevices equipment upon receipt of a resource reservation request according to the UPnP QoS and SBM protocols will be detailed in the description of FIGS. 7A and 7B. In accordance with the present invention, preferentially but not exclusively, in addition to step 450, the QosManager 150 explicitly requests the QosDevice equipment located upstream of the given equipment to confirm the reservation of the QoS resources according to the method in question. force in the SBM online signaling protocol. Because the given equipment implements the SBM protocol, this confirmation is accomplished by sending an SBM RESV message to the media stream server 110 (c0 source). According to a variant (not shown) of the embodiment of the invention, this reservation confirmation is not requested by the QosManager 150 because the QosDevice equipment can automatically respond to the resource reservation request in the online signaling protocol. SBM (as explained below in connection with FIG. 8). If the given equipment implements the UPnP QoS standard, then in a step 440, the QosManager 150 transmits to the given equipment a standard QoS query of the UPnP QoS standard (for example this request is a QD_SetupTrafficQoS message specified by the UPnP QoS standard. for the QosDevice service). Advantageously, the QD_SetupTrafficQoS message is particularized.
Comme le standard UPnP QoS permet d'ajouter des éléments spécifiques dans une structure XML, par exemple, le QosManager 150 ajoute une variable dans la structure TrafficDescriptor qui sera comprise par l'équipement donné s'il implémente le procédé de réservation de ressource selon l'invention. Cette variable est ignorée par les dispositifs n'implémentant pas le procédé de réservation de ressource selon l'invention. Since the UPnP QoS standard allows you to add specific elements in an XML structure, for example, the QosManager 150 adds a variable in the TrafficDescriptor structure that will be understood by the given device if it implements the resource reservation process according to the 'invention. This variable is ignored by the devices that do not implement the resource reservation method according to the invention.
Cette variable est par exemple désignée par: <prv: MyPrivateFl ag 1>TRUE</prv: MyPrivateFlag 1>. La valeur TRUE précise que le terminal client 120 doit envoyer une requête de réservation dans le second protocole. La valeur FALSE (ou l'absence de cette variable) ne modifie pas le comportement habituel. Un exemple de message QD_SetupTrafficQoS envoyé sur le réseau est donné en annexe 3. Selon un mode préférentiel de réalisation de l'invention, le QoSManager est capable d'émettre en parallèle plusieurs messages QD_SetupTrafficQoS sur le réseau. Selon un mode de réalisation de l'invention conforme au standard UPnP QoS, le QoSManager reste en attente d'une réponse à cette requête correspondant au résultat de l'établissement de la réservation de ressource QoS pour la transmission du contenu. Ce rapport est établi par le système de transition comme décrit ci-après à l'étape 660. This variable is for example designated by: <prv: MyPrivateFl ag 1> TRUE </ prv: MyPrivateFlag 1>. The value TRUE specifies that the client terminal 120 must send a reservation request in the second protocol. The value FALSE (or the absence of this variable) does not modify the usual behavior. An example of a QD_SetupTrafficQoS message sent over the network is given in Appendix 3. According to a preferred embodiment of the invention, the QoSManager is capable of transmitting several QD_SetupTrafficQoS messages in parallel on the network. According to one embodiment of the invention according to the UPnP QoS standard, the QoSManager remains waiting for a response to this request corresponding to the result of the establishment of the QoS resource reservation for the transmission of the content. This ratio is established by the transition system as described below in step 660.
Selon le mode préférentiel de réalisation de l'invention, une distinction des équipements QosDevice pouvant implémenter le procédé de réservation de ressource selon l'invention et de ceux qui ne peuvent pas est rnise en oeuvre lors de l'étape 490 précitée (permettant de détecter tous les équipements QosDevice du réseau). According to the preferred embodiment of the invention, a distinction between QosDevice equipment that can implement the resource reservation method according to the invention and those that can not be implemented during the aforementioned step 490 (making it possible to detect all QosDevice network equipment).
Par exemple, pour un équipement déterminé, la possibilité d'implémenter le procédé de réservation de ressource selon l'invention ou non peut être testée par l'examen des descriptifs XML (comprenant par exemple un numéro de série, un code produit spécifique, un nom de modèle spécifique ou un numéro de modèle spécifique) de l'équipement déterminé. For example, for a given piece of equipment, the possibility of implementing the resource reservation method according to the invention or not can be tested by examining the XML descriptions (comprising, for example, a serial number, a specific product code, a specific model name or a specific model number) of the specified equipment.
Une autre solution pour réaliser un tel test peut consister à offrir un champ descriptif propriétaire dans la structure de retour du message GetDeviceCapabilities proposé par l'interface UPnP QosDevice. Ainsi, l'étape 430 (de vérification si l'équipement donné implémente le standard UPnP QoS) peut être modifiée afin de vérifier si l'équipement donné peut également implémenter le procédé de réservation de ressource selon l'invention et de vérifier si cet équipement donné est le dernier de la liste des équipements du chemin de transmission du contenu c0 avant un éventuel prochain équipement n'implémentant pas le standard UPnP QoS. On se place dans le cadre d'un flot multimédia (correspondant au contenu c0) qui est directionnel vers le terminal client 120 (équipement récepteur), cependant l'invention s'applique également dans le cas de flots en direction de plusieurs terminaux clients, auquel cas, il existe plusieurs chemins de transmission du contenu c0 à mettre en oeuvre. On présente, en relation avec la figure 5, les étapes principales d'un algorithme de détermination d'un chemin de transmission de c0 entre le serveur de flot multimédia 110 et le terminal client 120 selon un mode de réalisation de l'invention. Cet algorithme est mis en oeuvre par le QosManager 150 dans le cadre de l'étape 410 de la figure 4 précédemment décrite. Lors d'une étape 510, le QosManager 150 obtient les adresses IP du serveur de flot multimédia 110 et du terminal client 120 du flot du contenu c0 (spécifié dans le message reçu à l'étape 400 du procédé de la figure 4). Lors d'une étape 520, le QosManager 150 obtient à partir de ces adresses IP, leurs adresses MAC Ethernet équivalentes, qui permettront par la suite de déterminer le chemin de transmission de niveau 2 du contenu c0 depuis le serveur de flot multimédia 110 et le terminal client 120. Lors d'une étape 530, le QosManager 150 détermine le chemin de transmission de c0 à l'aide de l'algorithme Spanning Tree tel que spécifié par la norme IEEE 802.1D. Lors d'une étape 540, à l'aide des résultats de lors de l'étape 490 précitée (permettant de détecter tous les équipements QosDevice du réseau), le QosManager 150 recherche dans le chemin de transmission de c0 chaque équipement implémentant le standard UPnP QoS (par comparaison entre les adresses MAC d'un équipement du chemin avec l'adresse MAC de chaque équipement QosDevice). Une fois identifiés les équipements QosDevice présents sur le chemin, à l'étape 550, le QosManager procède à l'identification des équipements n'implémentant pas le standard UPnP QoS. Conformément à l'invention, préférentiellement, on ne recherchera pas à créer un chemin directement avec les informations reçues du standard UPnP QoS, car cela pourrait conduire à plusieurs chemins théoriques. La norme 802.1D prévoit cette hypothèse et l'algorithme Spanning Tree reflète toujours le chemin réel emprunté par le flot multimédia. Le chemin résultant de ces opérations est une liste d'équipements identifiés par leurs adresses MAC, dont ceux supportant le service UPnP QosDevice sont marqués (selon une variante, on peut aussi distinguer ceux ne supportant pas l'invention tel que précédemment expliqué en relation avec la figure 4). On illustre, en relation avec la figure 6, les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont 140A (conforme au protocole UPnP QoS), lors de la transmission de c0 du serveur de flot multimédia 110 vers le terminal client 120 suite à une requête du QosManager 150. Dans une étape 600, le service UPnP QosDevice du pont 140A reçoit une requête, provenant du QosManager 150, d'établissement d'une transmission avec QoS (cette requête est par exemple un message QD_SetupTrafficQos ) du contenu c0 du serveur de flot multimédia 110 vers le terminal client 120. Le standard UPnP QoS précise que la requête contient notamment une indication sur les caractéristiques (notamment sa structure XML TrafficDesriptor, ou sa structure Tspec) du flot du contenu c0 à transmettre, qui correspondent à celles reçues par le QosManager 150 en provenance du poste de contrôle 130. Another solution for performing such a test may be to provide a proprietary descriptive field in the return structure of the GetDeviceCapabilities message provided by the UPnP QosDevice interface. Thus, step 430 (checking whether the given equipment implements the UPnP QoS standard) can be modified to verify whether the given equipment can also implement the resource reservation method according to the invention and to check whether this equipment given is the last in the list of equipment in the c0 content path prior to a possible next device not implementing the UPnP QoS standard. It is placed in the context of a multimedia stream (corresponding to the content c0) which is directional towards the client terminal 120 (receiving equipment), however the invention also applies in the case of flows towards several client terminals, in which case, there are several content transmission paths c0 to implement. In relation to FIG. 5, the main steps of an algorithm for determining a transmission path of c0 between the multimedia flow server 110 and the client terminal 120 according to one embodiment of the invention are presented. This algorithm is implemented by QosManager 150 as part of step 410 of FIG. 4 previously described. In a step 510, the QosManager 150 obtains the IP addresses of the media stream server 110 and the client terminal 120 of the content stream c0 (specified in the message received at step 400 of the method of FIG. 4). In a step 520, the QosManager 150 obtains from these IP addresses, their equivalent Ethernet MAC addresses, which will subsequently determine the level 2 transmission path of the content c0 from the media stream server 110 and the client terminal 120. In a step 530, the QosManager 150 determines the transmission path of c0 using the Spanning Tree algorithm as specified by the IEEE 802.1D standard. In a step 540, using the results of the above-mentioned step 490 (to detect all QosDevice devices in the network), the QosManager 150 searches the transmission path of each device implementing the UPnP standard. QoS (comparing the MAC addresses of a device in the path with the MAC address of each QosDevice device). Once identified the QosDevice devices present on the path, in step 550, the QosManager proceeds to the identification of the devices not implementing the UPnP QoS standard. According to the invention, preferentially, it will not be sought to create a path directly with the information received from the UPnP QoS standard, since this could lead to several theoretical paths. The 802.1D standard provides for this assumption and the Spanning Tree algorithm always reflects the actual path taken by the multimedia stream. The path resulting from these operations is a list of equipment identified by their MAC addresses, of which those supporting the UPnP service QosDevice are marked (alternatively, it is also possible to distinguish those not supporting the invention as previously explained in connection with Figure 4). FIG. 6 illustrates the main steps of the resource reservation method according to one embodiment of the invention, implemented by the bridge 140A (in accordance with the UPnP QoS protocol), during the transmission of c0 from the multimedia stream server 110 to the client terminal 120 following a request from the QosManager 150. In a step 600, the UPnP service QosDevice of the bridge 140A receives a request, from the QosManager 150, for establishment of a transmission with QoS ( this request is, for example, a message QD_SetupTrafficQos) of the content c0 of the multimedia stream server 110 to the client terminal 120. The UPnP QoS standard specifies that the request contains in particular an indication of the characteristics (in particular its XML structure TrafficDesriptor, or its structure Tspec ) of the stream of contents c0 to be transmitted, which correspond to those received by the QosManager 150 from the control station 130.
Dans une étape 610, suite à cette requête, le pont 140A met en place les procédures classiques pour valider et préparer les ressources locales à la mise en place de la politique QoS. Par d'exemple, si le flot multimédia du contenu c0 présente des contraintes d'acheminement fortes, alors une réservation de ressources peut consister à offrir une priorité pour ce flot en regard des autres flots en cours de transferts. Pour cela, le pont 140A modifie dynamiquement l'allocation des priorités des FIFO de ses ports d'entrée et de sortie relatifs au chemin de transmission du contenu c0. Au niveau des ressources locales, on utilise dans le cadre de la présente invention les techniques classiques de mise en place de QoS. En effet, il existe un grand nombre de méthodes de l'état de l'art précisant la relation entre les caractéristiques d'un flot et les priorités à appliquer sur les ports d'un équipement de commutation. Dans une étape 620, le pont 140A vérifie si l'admission du flot c0 a été effectuée avec succès. In a step 610, following this request, the bridge 140A sets up the standard procedures to validate and prepare local resources for the implementation of the QoS policy. For example, if the multimedia stream of content c0 has strong routing constraints, then a resource reservation may consist in offering a priority for this stream compared to the other streams being transferred. For this purpose, the bridge 140A dynamically modifies the priority allocation of the FIFOs of its input and output ports relative to the transmission path of the content c0. At the level of local resources, it is used in the context of the present invention the conventional techniques of QoS implementation. Indeed, there are a large number of state-of-the-art methods that specify the relationship between the characteristics of a stream and the priorities to be applied to the ports of a switching equipment. In a step 620, the bridge 140A checks whether the admission of the flow c0 has been carried out successfully.
En cas d'échec de l'admission du flot, dans une étape 660, le pont 140A transmet au QosManager 150 un message d'erreur relatif à la réservation de ressource pour la transmission de c0. Ainsi, le résultat de la requête de réservation est retourné au QosManager 150 comme précisé dans le standard UPnP QoS. Un échec de l'étape 610 peut être par exemple dû à une insuffisance de ressources disponibles (par exemple lorsque trop de flots sont réservés dans ce pont 140A). D'autre part, un message d'erreur peut également être transmis au QosManager 150 par le pont 140A lors de l'occurrence d'une double réservation de ressource pour la transmission d'un même contenu. En cas de succès de l'admission du flot, dans une étape 630, le pont 140A vérifie s'il a reçu, en provenance du QosManager 150, une demande d'envoi, à un dispositif non conforme au protocole UPnP QoS mais conforme au protocole SBM tel que le commutateur 104B, d'une requête de réservation de ressource conforme au protocole SBM (tel qu'indiqué ci-dessus en relation avec la figure 4). S'il a reçu une telle demande, alors le pont 140A est un dispositif de transition au sens de la présente invention vis-à-vis du commutateur 140B par exemple. Ainsi, si le pont 140A n'est pas un dispositif de transition au sens de la présente invention, alors un rapport positif est retourné par l'étape 660, confirmant que les ressources locales ont été mises en place correctement. Au contraire, si le pont 140A est un dispositif de transition au sens de la présente invention, alors, dans une étape 640, le pont 140A envoie une requête de réservation de ressource conforme au protocole SBM (construite à partir des spécifications du flot multimédia et ci-après désignée par requête SBM) au commutateur 140B. Puis, dans une étape 650, le pont 140A attend la confirmation SBM à cette requête. Puis dans l'étape 660, le pont 140A confirme au QosManager 150 la réservation de ressource conforme au protocole SBM pour la transmission de c0. En option, lorsque le flot c0 ne comporte pas de caractéristique suffisamment critique pour nécessiter une réservation de ressource, et en accord avec la politique de qualité de service en vigueur sur le réseau, le pont 140A peut mettre en oeuvre une autre technique pour indiquer aux équipements de type 140B la manière de gérer le flot c0. Par exemple, le pont 140A peut enregistrer les caractéristiques du flot (adresses IP et ports utilisés) afin, lors de la détection de paquets de ce flot, d'estampiller ces paquets selon une priorité choisie (par exemple en application de la norme IEEE 802.1Q). In the event of failure of the admission of the stream, in a step 660, the bridge 140A transmits to the QosManager 150 an error message relating to the reservation of resource for the transmission of c0. Thus, the result of the reservation request is returned to the QosManager 150 as specified in the UPnP QoS standard. A failure of step 610 may be due for example to a lack of available resources (for example when too many flows are reserved in this bridge 140A). On the other hand, an error message can also be transmitted to the QosManager 150 by the bridge 140A when the occurrence of a double resource reservation for the transmission of the same content. In the event of success of the admission of the stream, in a step 630, the bridge 140A checks whether it has received, from the QosManager 150, a request for sending, to a device that does not conform to the UPnP QoS protocol but complies with the SBM protocol such as the switch 104B, a resource reservation request according to the SBM protocol (as indicated above in connection with Figure 4). If it has received such a request, then the bridge 140A is a transition device within the meaning of the present invention with respect to the switch 140B for example. Thus, if the bridge 140A is not a transition device in the sense of the present invention, then a positive report is returned by step 660, confirming that the local resources have been put in place correctly. On the contrary, if the bridge 140A is a transition device in the sense of the present invention, then, in a step 640, the bridge 140A sends a resource reservation request according to the SBM protocol (constructed from the specifications of the multimedia stream and hereinafter referred to as SBM request) to switch 140B. Then, in a step 650, the bridge 140A waits for confirmation SBM to this request. Then, in step 660, the bridge 140A confirms to the QosManager 150 the resource reservation according to the SBM protocol for the transmission of c0. Optionally, when the stream c0 does not have a critical enough characteristic to require a resource reservation, and in accordance with the quality of service policy in force on the network, the bridge 140A can implement another technique to indicate to type 140B equipment how to manage the flow c0. For example, the bridge 140A can record the characteristics of the flow (IP addresses and ports used) in order to detect packets of this stream, to stamp these packets according to a chosen priority (for example in application of the IEEE 802.1 standard). Q).
On illustre, en relation avec les figures 7A et 7B, un algorithme comprenant les étapes du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont 140A (conforme au protocole UPnP QoS et au protocole SBM), lors de la réception de messages provenant du réseau local 100 relatifs aux protocoles UPnP QoS ou SBM. FIGS. 7A and 7B illustrate an algorithm comprising the steps of the resource reservation method according to one embodiment of the invention implemented by the bridge 140A (in accordance with the UPnP QoS protocol and the SBM protocol). ), when receiving messages from the local network 100 relating UPnP QoS or SBM protocols.
Le pont 140A conforme à l'invention doit au préalable (par exemple lors de son initialisation) mettre en place les actions nécessaires au bon déroulement du protocole SBM. Ainsi, par exemple, lors de l'initialisation, le pont 140A : participe à l'élection du responsable DSBM sur les différents segments connectés du réseau local 100, en accord avec la norme SBM ; - se déclare sur le réseau UPnP comme supportant un service QosDevice (de manière classique selon la norme UPnP QoS). Puis, comme pour chaque équipement de commutation classique, une gestion des flots réservés en cours doit être effectuée par le pont 140A. Les protocoles SBM et UPnP QoS sont tous les deux basés sur une description du flot selon un typage token-bucket , ce qui facilite les correspondances entre ces deux protocoles. De manière préférentielle, un objet Tspec tel que définit dans le protocole RFC-2215 est associé à chaque flot multimédia requérant des ressources QoS. Selon une mise en oeuvre particulière de l'invention, deux étiquettes nommées SBM_flag et UPnP_flag sont associées à chaque objet Tspec, et une liste de ces trois éléments est régulièrement mise à jour comme décrit ci-après. Cette liste peut indifféremment être stockée dans une mémoire vive, ou à accès rapide de type flash du pont 140A. Préférentiellement, cette liste comprend des sous-listes dont l'une 10 correspond aux flots validés et l'autre correspond aux flots en attente de validation par le système local. On présente ci-après une liste des valeurs que peuvent prendre les étiquettes SBM_flag et UPnP_flag. L'étiquette SBM_flag peut prendre les valeurs suivantes : 15 - valeur 0 si la QoS pour le flot est gérée par protocole SBM ; valeur 1 si la QoS pour le flot est gérée par le protocole SBM sur le port d'entrée relatif au flot du dispositif commutateur local (le pont 140A) ; valeur 2 si le dispositif local (pont 140A) a initié une réservation SBM sur le port de sortie relatif au flot ; 20 - valeur 3 si le dispositif local (pont 140A) a initié une réservation SBM sur le port de sortie relatif au flot, et si la QoS de ce flot est contrôlée par le protocole SBM sur un port d'entrée du pont 140A. L'étiquette UPnP_flag peut prendre les valeurs suivantes : valeur 0 si la QoS pour le flot n'est pas contrôlée par le protocole UPnP 25 QoS ; valeur 1 si la QoS pour le flot est contrôlée par le protocole UPnP QoS. Dans une étape 700, le pont 140A vérifie si le message reçu est un message conforme au protocole UPnP QoS. Si le message reçu n'est pas un message conforme au protocole UPnP 30 QoS, alors dans une étape 720, le pont 140A vérifie s'il s'agit d'un message conforme au protocole SBM. S'il ne s'agit pas d'un message conforme au protocole SBM, alors il est mis fin à l'algorithme dans une étape 790. S'il s'agit d'un message conforme au protocole SBM, l'algorithme se poursuit (cf. A) tel qu'indiqué ci-après notamment en relation avec l'étape 730. S'il s'agit d'un message UPnP QoS relatif à l'interface offerte au QosManager 150, alors dans une étape 701, le pont 140A vérifie si le message reçu est une commande du QosManager 150 demandant la réservation de ressources QoS pour un contenu donné (par exemple le contenu cO). Il s'agit notamment du message QD_SetupTrafficQoS décrit à l'étape 440 précitée en relation avec la figure 4. Si le message reçu est une commande du QosManager 150 demandant la réservation de ressources QoS pour le contenu cO, alors les étapes 702 à 708 sont mises en oeuvre. The bridge 140A according to the invention must first (for example during its initialization) implement the necessary actions for the smooth running of the SBM protocol. Thus, for example, during initialization, the bridge 140A: participates in the election of the DSBM manager on the different connected segments of the local network 100, in accordance with the SBM standard; - declares on the UPnP network as supporting a QosDevice service (conventionally according to the UPnP QoS standard). Then, as for each conventional switching equipment, a reserved reserved stream management must be performed by the bridge 140A. The SBM and UPnP QoS protocols are both based on a description of the flow according to token-bucket typing, which facilitates the correspondence between these two protocols. Preferably, a Tspec object as defined in the RFC-2215 protocol is associated with each multimedia stream requiring QoS resources. According to a particular implementation of the invention, two labels named SBM_flag and UPnP_flag are associated with each object Tspec, and a list of these three elements is regularly updated as described below. This list can indifferently be stored in a random access memory, or fast access flash type of the bridge 140A. Preferably, this list includes sub-lists, one of which corresponds to the validated streams and the other corresponds to the streams awaiting validation by the local system. The following is a list of the values that the SBM_flag and UPnP_flag tags can take. The SBM_flag tag can take the following values: 15 - value 0 if the QoS for the stream is managed by SBM protocol; value 1 if the QoS for the stream is handled by the SBM protocol on the input port relative to the local switch device stream (the bridge 140A); value 2 if the local device (bridge 140A) initiated an SBM reservation on the output port relative to the stream; 20 - value 3 if the local device (bridge 140A) has initiated an SBM reservation on the output port relative to the stream, and if the QoS of this stream is controlled by the SBM protocol on an input port of the bridge 140A. The UPnP_flag tag can take the following values: value 0 if the QoS for the stream is not controlled by the UPnP 25 QoS protocol; value 1 if the QoS for the stream is controlled by the UPnP QoS protocol. In a step 700, the bridge 140A checks whether the received message is a message conforming to the UPnP QoS protocol. If the received message is not a UPnP 30 QoS compliant message, then in step 720, the bridge 140A checks whether it is a SBM compliant message. If it is not an SBM compliant message, then the algorithm is terminated in a step 790. If it is a SBM compliant message, the algorithm continues (see A) as indicated below in particular in connection with step 730. If it is a UPnP QoS message relating to the interface offered to the QosManager 150, then in a step 701, the bridge 140A checks whether the received message is a command from the QosManager 150 requesting the reservation of QoS resources for a given content (for example the content cO). This includes the QD_SetupTrafficQoS message described in step 440 above in connection with FIG. 4. If the message received is a command from the QosManager 150 requesting the reservation of QoS resources for the content cO, then the steps 702 to 708 are implemented.
Ainsi, pour le contenu spécifié par le message QD_SetupTrafficQos (par exemple le contenu cO), dans l'étape 702, le pont 140A vérifie s'il est demandé d'effectuer une réservation de ressource de type SBM en plus des actions UPnP habituelles. Cette étape correspond à l'étape 630 précitée en relation avec la figure 6. Thus, for the content specified by the QD_SetupTrafficQos message (e.g., the content cO), in step 702, the bridge 140A checks whether it is requested to make a resource reservation of the SBM type in addition to the usual UPnP actions. This step corresponds to the aforementioned step 630 in connection with FIG. 6.
S'il est demandé d'effectuer une réservation de ressource de type SBM, dans l'étape 706, le pont 140A envoie une requête PATH en direction de la machine 120 (donc sur le port de sortie qu'empruntera le contenu cO). Ce message permet de faire en sorte que les équipements non conformes au protocole UPnP QoS admettent cO dans leur liste de réservation de ressources. If it is requested to make an SBM type resource reservation, in step 706, the bridge 140A sends a PATH request to the machine 120 (thus on the output port that the content cO will borrow). This message ensures that equipment that does not comply with the UPnP QoS protocol will accept cO in their resource reservation list.
Dans une étape 706a, le pont 140A vérifie si l'étiquette SBM_flag de cO possède la valeur 1 (un objet Tspec étant associé au contenu cO). Si l'étiquette SBM_flag de cO possède la valeur 1, dans une étape 706b, le contenu cO est tamponné avec les étiquettes UPnP_flag à 1 et SIM_flag à 3. Si l'étiquette SBM_flag de cO ne possède pas la valeur 1, dans une étape 706c, le contenu cO est tamponné avec les étiquettes UPnP_flag à 1 et SBM_flag à . La valeur 2 de l'étiquette SBM_flag indique que c0 à été demandé par le protocole UPnP QoS avec une initiation de réservation SBM pour un flux nouveau, alors que la valeur 3 indique que c0 était déjà connu du côté du port d'entrée du pont 140A et qu'une réservation est lancée sur le port de sortie du pont 140A. Ensuite, les ressources locales sont vérifiées par le pont 140A dans l'étape 707 afin d'appliquer la mise en place de la politique QoS locale pour le contenu c0. In a step 706a, the bridge 140A checks whether the SBM_flag tag of cO has the value 1 (a Tspec object being associated with the content cO). If the label SBM_flag of cO has the value 1, in a step 706b, the content cO is buffered with the labels UPnP_flag at 1 and SIM_flag at 3. If the label SBM_flag of cO does not have the value 1, in a step 706c, the content cO is buffered with the labels UPnP_flag at 1 and SBM_flag at. The value 2 of the SBM_flag label indicates that c0 was requested by the UPnP QoS protocol with an SBM reservation initiation for a new flow, while the value 3 indicates that c0 was already known on the bridge input port side. 140A and a reservation is initiated on the 140A bridge exit port. Then, the local resources are checked by the bridge 140A in step 707 in order to apply the implementation of the local QoS policy for the content c0.
Selon une variante conforme à l'invention de ce mode de réalisation, la disponibilité des ressources locales est vérifiée avant la gestion par le protocole SBM des autres machines (ceci correspond au fait que l'étape 707 est mise en oeuvre avant l'étape 706). En cas de succès, dans une étape 708, les caractéristiques du flot multimédia (Tspec, SBM_flag, UPnP_flag) sont stockées dans la liste des flots en cours d'admission (la réponse SBM RESV n'a pas encore été reçue). Dans l'étape 702, s'il n'est pas demandé d'effectuer une réservation de ressource de type SBM, dans l'étape 703, le pont 140A vérifie si la valeur de l'étiquette SBM_flag de c0 est non nulle (un objet Tspec étant associé au contenu c0) c'est-à-dire si c0 est déjà connu localement comme étant conforme au protocole SBM. On peut noter que le fait que l'étiquette SBM_flag soit non nulle équivaut à avoir reçu la description de ce contenu préalablement par un message SBM PATH, par exemple dans le cas d'un équipement 140A placé entre un équipement 140B et le dispositif récepteur 120. According to a variant according to the invention of this embodiment, the availability of local resources is verified before management by the SBM protocol of the other machines (this corresponds to the fact that step 707 is implemented before step 706 ). If successful, in a step 708, the characteristics of the multimedia stream (Tspec, SBM_flag, UPnP_flag) are stored in the list of streams being admitted (the SBM RESV response has not yet been received). In step 702, if it is not requested to make an SBM resource reservation, in step 703, the bridge 140A checks whether the value of the SBM_flag tag of c0 is non-zero (a object Tspec being associated with the content c0) that is to say if c0 is already known locally as being in conformity with the SBM protocol. It should be noted that the fact that the label SBM_flag is non-zero is equivalent to having received the description of this content previously by an SBM PATH message, for example in the case of a device 140A placed between a device 140B and the receiving device 120 .
Dans le cas où l'étiquette SBM_flag de c0 est nulle, l'étape 705 ci-après décrite est directement mise en oeuvre. Dans le cas où l'étiquette SBM_flag de c0 est non nulle, dans une étape 704, une réponse de confirmation SBM RESV est envoyée en direction du dispositif source 110 dans le but d'être interceptée par le pont 140A ayant émis le message SBM PATH. 38 Ensuite, dans une étape 705, c0 est marqué comme étant connu par le protocole UPnP QoS. Ensuite l'étape 707 précitée est mise en œ uvre suivie par l'étape 708 précitée si ce n'est que les caractéristiques de c0 ('l'spec, SBM_flag, UPnP_flag) sont stockées non plus dans la liste des flots en cours d'admission, mais dans la liste des flots confirmés. Si le message reçu n'est pas une commande du QosManager 150 demandant la réservation de ressources QoS pour le contenu c0, alors, dans une étape 710, le pont 140A vérifie si le message reçu est une commande du QosManager 150 demandant la libération (ou relâche) de ressources QoS pour un flot multimédia donné (par exemple le contenu c0). Il s'agit notamment du message QD_ReleaseTrafficQoS spécifié par le standard UPnP QoS se rapportant au service QosDevice. Si ce n'est pas le cas, dans l'étape 790, il est mis fin à l'algorithme. Si le message reçu est une commande du QosManager 150 demandant la libération de ressources QoS pour c0 et si c0 est référencé comme étant conforme au protocole SBM (étape 711), dans une étape 712, le pont 140A envoie un message de libération des ressources distantes désigné par SBM TEARDOWN en direction du dispositif source 110, dans le but d'être capté par un autre dispositif sur le chemin de transmission de c0. Dans les étapes 713 et 714, les ressources locales sont libérées (étape 713) et les caractéristiques du flot sont supprimées des listes qui les contiennent (étape 714). On se place dans la suite dans le cas où le message reçu n'est pas un message conforme au protocole UPnP QoS, mais est un message conforme au protocole SBM. In the case where the SBM_flag tag of c0 is zero, step 705 hereinafter described is directly implemented. In the case where the SBM_flag label of c0 is non-zero, in a step 704, an SBM RESV confirm response is sent towards the source device 110 in order to be intercepted by the bridge 140A having sent the SBM PATH message. . Then, in a step 705, c0 is marked as being known by the UPnP QoS protocol. Then the above-mentioned step 707 is carried out followed by the above-mentioned step 708 except that the characteristics of c0 ('spec, SBM_flag, UPnP_flag) are no longer stored in the current stream list. admission, but in the list of confirmed waves. If the received message is not a command from the QosManager 150 requesting the reservation of QoS resources for the content c0, then in a step 710, the bridge 140A checks whether the received message is a command from the QosManager 150 requesting the release (or release) of QoS resources for a given multimedia stream (eg content c0). This includes the QD_ReleaseTrafficQoS message specified by the UPnP QoS standard pertaining to the QosDevice service. If it is not the case, in step 790, the algorithm is terminated. If the received message is a command from the QosManager 150 requesting the release of QoS resources for c0 and if c0 is referenced as being in accordance with the SBM protocol (step 711), in a step 712, the bridge 140A sends a remote resource release message designated SBM TEARDOWN to the source device 110, for the purpose of being picked up by another device on the transmission path of c0. In steps 713 and 714, the local resources are released (step 713) and stream characteristics are removed from the lists that contain them (step 714). We put in the following in the case where the received message is not a message compliant with the UPnP QoS protocol, but is a message compliant with the SBM protocol.
Dans une étape 730, le pont 140A vérifie si le message reçu est un message SBM PATH rapportant une demande de réservation de ressources. Si le message reçu est un tel message SBM PATH, alors dans une étape 731, le pont 140A vérifie si le flot (par exemple le contenu c0) concerné n'est pas déjà connu localement dans l'une des listes (un objet Tspec étant associé à co). In a step 730, the bridge 140A checks whether the received message is an SBM PATH message reporting a resource reservation request. If the message received is such an SBM PATH message, then in a step 731, the bridge 140A checks whether the stream (for example the content c0) concerned is not already known locally in one of the lists (a Tspec object being associated with co).
Si c0 n'est pas connu, alors c0 est un nouveau flot commandé par le protocole SBM et, dans une étape 734, le pont 140A enregistre les paramètres Tspec de cO en conservant l'identification de sa provenance (l'étiquette SBM_flag est fixée à 1). Dans une étape 735, les ressources locales sont alors préparées pour cO de la même manière qu'à l'étape 707 précitée. Puis, il est mis fin à l'algorithme dans l'étape 790. Par contre, si cO est déjà référencé, dans une étape 732, le pont 140A vérifie si l'étiquette SBM_flag de cO présente la valeur 0 (c'est-à-dire vérifie si cO n'est pas référencé comme étant conforme au protocole SBM). Si la valeur de l'étiquette SBM_flag est 0, alors, dans une étape 733, le pont 140A met cette valeur à jour en remplaçant la valeur 0 par la valeur 1. Puis, il est mis fin à l'algorithme dans l'étape 790. En effet, les actions de réservation ont déjà été prises en compte car cO est déjà connu. Si la valeur de l'étiquette SBM_flag est non nulle, alors, dans une étape 736, le pont vérifie si la valeur de l'étiquette SBM_flag est 2 (initiation d'une réservation en direction du dispositif récepteur 120). Si la valeur de l'étiquette SBM_flag n'est pas égale à 2, alors, il est mis fin à l'algorithme dans l'étape 790. Si la valeur de l'étiquette SBM_flag est égale à 2, alors, dans une étape 737, le pont 140A met cette étiquette à jour (en remplaçant la valeur 2 par la valeur 3) pour se souvenir que le protocole SBM connaît aussi le flot sur le port d'entrée du commutateur. Puis, il est mis fin à l'algorithme dans l'étape 790. Selon une variante de l'invention, non représentée ici par souci de simplification, lorsque le QosDevice reçoit un message PATH pour l'établissement d'un flot concernant le contenu cO selon le protocole SBM, il vérifie si le flot concerné n'est pas déjà connu localement dans l'une des listes. Si le flot concerné a déjà fait l'objet d'une requête de réservation selon le protocole UPnP QoS, les ressources nécessaires à l'établissement du flot sont déjà réservées. Le QosDevice peut alors envoyer en retour du message PATH un message RESV indiquant que l'étape de réservation a été concluante. Le message PATH n'est alors pas propagé au(x) dispositif(s) en aval du QosDevice dans le sens de parcours de la requête de réservation. Ce message RESV sera alors retourné au dispositif en amont du QosDevice dans le sens de parcours de la requête de réservation. Ce message sera intercepté par le QosDevice qui était émetteur de la requête de réservation selon le protocole SBM sur demande du QosManager. Un rapport sur le résultat de l'allocation des ressources pourra alors être adressé au QosManager. Cette variante est mise en place quand le QosManager 150 a déterminé un équipement non compatible avec le protocole UPnP QoS sur le chemin entre l'équipement source et l'équipement récepteur du contenu c0, puis a sélectionné un QosDevice, dit équipement de transition sur ce chemin et a déterminé les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne. Comme déjà décrit, le QosManager 150 peut alors réordonner les requêtes de réservation de ressources et envoyer aux QosDevices, qui seront impactés par la requête de réservation en ligne, une requête de réservation de ressources QD_SetupTrafficQoS tel que spécifié par le standard UPnP QoS avant d'envoyer la requête au dispositif de transition. Ces QosDevices reçoivent ainsi une requête de réservation selon le protocole UPnP QoS avant de recevoir une requête de réservation selon le protocole SBM. If c0 is not known, then c0 is a new stream controlled by the SBM protocol and, in a step 734, the bridge 140A stores the Tspec parameters of cO while retaining the identification of its provenance (the SBM_flag label is fixed to 1). In a step 735, the local resources are then prepared for cO in the same manner as in the above-mentioned step 707. Then, the algorithm is terminated in step 790. On the other hand, if cO is already referenced, in a step 732, the bridge 140A checks whether the SBM_flag tag of cO has the value 0 (that is, ie verifies if cO is not referenced as conforming to the SBM protocol). If the value of the label SBM_flag is 0, then, in a step 733, the bridge 140A updates this value by replacing the value 0 by the value 1. Then, the algorithm is terminated in the step 790. Indeed, the reservation actions have already been taken into account because it is already known. If the value of the label SBM_flag is non-zero, then, in a step 736, the bridge checks whether the value of the label SBM_flag is 2 (initiation of a reservation towards the receiving device 120). If the value of the label SBM_flag is not equal to 2, then the algorithm is terminated in step 790. If the value of the label SBM_flag is equal to 2, then in a step 737, the 140A bridge updates this label (replacing the value 2 with the value 3) to remember that the SBM protocol also knows the flow on the switch's input port. Then, the algorithm is terminated in step 790. According to a variant of the invention, not shown here for the sake of simplification, when the QosDevice receives a PATH message for the establishment of a flow concerning the content cO according to the SBM protocol, it checks whether the flow concerned is not already known locally in one of the lists. If the flow concerned has already been the subject of a reservation request according to the UPnP QoS protocol, the resources required to establish the flow are already reserved. The QosDevice can then send back the message PATH a RESV message indicating that the reservation step was conclusive. The PATH message is then not propagated to the device (s) downstream of the QosDevice in the direction of travel of the reservation request. This RESV message will then be returned to the device upstream of the QosDevice in the direction of travel of the reservation request. This message will be intercepted by the QosDevice which sent the reservation request according to the QosManager's request-based SBM protocol. A report on the result of the resource allocation can then be sent to the QosManager. This variant is implemented when the QosManager 150 has determined a device not compatible with the UPnP QoS protocol on the path between the source equipment and the receiver equipment of the content c0, then selected a QosDevice, said transition equipment on this path and determined the QosDevices that will be impacted by the resource reservation request compliant with the online signaling protocol. As already described, the QosManager 150 can then reorder the resource reservation requests and send to QosDevices, which will be impacted by the online reservation request, a QD_SetupTrafficQoS resource reservation request as specified by the UPnP QoS standard prior to send the request to the transition device. These QosDevices thus receive a reservation request according to the UPnP QoS protocol before receiving a reservation request according to the SBM protocol.
Selon les figures 7A et 7B, si le message reçu n'est pas un message SBM PATH, alors dans une étape 740, le pont 140A vérifie s'il s'agit d'un message SBM TEARDOWN rapportant une demande d'annulation de réservation de ressources. Si le message reçu est un message SBM TEARDOWN, alors dans une étape 741, les actions classiques de libération des ressources QoS locales sont exécutées. Dans une étape 742, le pont 1.40A vérifie si la valeur de l'étiquette UPnP_flag est 0. Si la valeur de l'étiquette UPnP_flag n'est pas 0, alors, l'étape 744 ci-après décrite est directement mise en oeuvre. According to FIGS. 7A and 7B, if the received message is not an SBM PATH message, then in a step 740, the bridge 140A checks whether it is a TEARDOWN SBM message reporting a reservation cancellation request. of resources. If the received message is a TEARDOWN SBM message, then in a step 741, the traditional local QoS resource release actions are executed. In a step 742, the bridge 1.40A checks whether the value of the UPnP_flag tag is 0. If the value of the UPnP_flag tag is not 0, then the step 744 described below is directly implemented. .
Si la valeur de l'étiquette UPnP_flag est 0, alors dans une étape 743, le pont 140A avertit le QosManager 150 de ce fait. Ensuite, dans une étape 744, les caractéristiques actuelles du contenu sont supprimées des listes. Ainsi, les étapes 742 à 744 permettent d'indiquer au service QosManager 150 toute modification d'un état du pont 140A courant. Ainsi, si le contenu à libérer est référencé comme étant conforme au protocole UPnP QoS (UPnP_flag à 1), l'étape 743 permet d'avertir le QosManager 150 du changement. Ceci permet au QosManager 150 : de localiser précisément une portion de segments non compatibles avec le protocole UPnP QoS dans laquelle il y a eu un problème, et, le cas échéant, de demander l'application d'autres caractéristiques moins sévères pour ce contenu ou de faire passer le contenu par un autre chemin de transmission. Cette notification peut être réalisée par exemple au moyen d'une variable d'événement QosState , dont la modification est aussitôt notifiée au service QosManager 150 selon le protocole GENA (pour General lEvent Notification Architecture ) utilisé par le protocole UPnP QoS. L'interface QD_GetQosState définie par UPnP QoS permet notamment d'indiquer les flots actifs sur le dispositif 140A, et sera appelée par le service QosManager 150 en réception de l'événement. If the value of the label UPnP_flag is 0, then in a step 743, the bridge 140A warns the QosManager 150 accordingly. Then, in a step 744, the current features of the content are removed from the lists. Thus, steps 742 through 744 enable the QosManager 150 service to indicate any change in a state of the current bridge 140A. Thus, if the content to be released is referenced as being in accordance with the UPnP QoS protocol (UPnP_flag at 1), step 743 is used to notify the QosManager 150 of the change. This allows the QosManager 150: to precisely locate a portion of segments not compatible with the UPnP QoS protocol in which there was a problem, and, if necessary, to request the application of other less severe features for this content or to pass the content through another transmission path. This notification can be carried out for example by means of a QosState event variable, the modification of which is immediately notified to the QosManager 150 service according to the GENA (General lEvent Notification Architecture) protocol used by the UPnP QoS protocol. The interface QD_GetQosState defined by UPnP QoS makes it possible in particular to indicate the active flows on the device 140A, and will be called by the service QosManager 150 in reception of the event.
Si le message reçu n'est ni message SBM PATH, ni un message SBM TEARDOWN,alors dans une étape 750, le pont 140A vérifie s'il s'agit d'un message SBM RESV rapportant une confirmation de réservation de ressources. S'il s'agit d'un message SBM RESV rapportant une confirmation de réservation de ressources, dans une étape 751, le pont 140A vérifie si le contenu est en cours de réservation. Si le contenu est totalement inconnu, alors l'algorithme ne prend pas en compte ce message puis, il est mis fin à l'algorithme (ce cas n'est pas représenté sur les figures 7A ou 7B). Lorsque les ressources pour le flot sont réservées (y compris le cas où l'on 30 reçoit ce message SBM RESV pour un flot déjà réservé pour lequel l'étape 751 précitée donne un résultat négatif), alors l'étape 755 ci-après décrite est mise en oeuvre. Le passage direct à l'étape 755 évite d'effectuer une nouvelle réservation des ressources en plus de celle déjà réalisée. Si le flot fait partie des flots en cours de réservation, il passe dans la catégorie/liste des flots acquittés dans une étape 752 : c'est-à-dire que les ressources locales préparées en vue de leur réservation en référence à l'étape 735 sont réellement mise en oeuvre pour la transmission du contenu c0. Dans une étape 753, le pont 140A vérifie si la valeur de l'étiquette UPnP_flag est 0, c'est-à-dire si le contenu est référencé comme étant compatible 10 au protocole UPnP QoS. Si la valeur de l'étiquette UPnP_flag n'est pas 0, alors, l'étape 755 ci-après décrite est directement mise en oeuvre. Si la valeur de l'étiquette UPnP_flag est 0, alors dans une étape 754, le pont 140A avertit le QosManager 150 de ce fait. Ensuite, dans l'étape 755, le pont 15 140A vérifie si le flot réservé est également connu sur le port d'entrée du pont 140A (c'est-à-dire si l'étiquette SBM_flag possède la valeur 3). Si l'étiquette SBM_flag ne possède pas la valeur 3, il est mis fin à l'algorithme dans l'étape 790. Si l'étiquette SBM_flag possède la valeur 3, dans une étape 756, le pont 20 140A autorise la propagation de la confirmation de réservation RESV en direction du dispositif source. Puis, il est mis fin à l'algorithme dans l'étape 790. Si le message reçu n'est ni message SBM PATH, ni un message SBM TEARDOWN, ni un message SBM RESV, alors il est mis fin à l'algorithme dans l'étape 790. If the received message is neither an SBM PATH message nor a TEARDOWN SBM message, then in a step 750, the bridge 140A checks whether it is an SBM RESV message reporting a resource reservation confirmation. If it is an SBM RESV message reporting a resource reservation confirmation, in a step 751, the bridge 140A checks whether the content is being reserved. If the content is totally unknown, then the algorithm does not take into account this message and then the algorithm is terminated (this case is not shown in FIGS. 7A or 7B). When the resources for the stream are reserved (including the case where this SBM RESV message is received for an already reserved stream for which the above-mentioned step 751 gives a negative result), then step 755 described below is implemented. Direct passage to step 755 avoids re-booking the resources in addition to the one already performed. If the stream is part of the stream being reserved, it passes into the category / list of the streams acknowledged in a step 752: that is to say that the local resources prepared for their reservation with reference to the stage 735 are actually implemented for the transmission of the content c0. In a step 753, the bridge 140A checks whether the value of the UPnP_flag tag is 0, i.e., whether the content is referenced as being compatible with the UPnP QoS protocol. If the value of the label UPnP_flag is not 0, then step 755 hereinafter described is directly implemented. If the value of the UPnP_flag tag is 0, then in a step 754, the bridge 140A warns the QosManager 150 accordingly. Then, in step 755, the bridge 140A checks whether the reserved stream is also known on the input port of the bridge 140A (i.e. if the SBM_flag tag has the value 3). If the label SBM_flag does not have the value 3, the algorithm is terminated in step 790. If the label SBM_flag has the value 3, in a step 756, the bridge 140A authorizes the propagation of the RESV reservation confirmation towards the source device. Then, the algorithm is terminated in step 790. If the received message is neither an SBM PATH message, nor a TEARDOWN SBM message, nor an SBM RESV message, then the algorithm is terminated. step 790.
25 Ainsi, à partir de messages élémentaires conformes au protocole UPnP QoS, le procédé de réservation de ressource selon l'invention permet de conduire une réservation de ressource complémentaire envers des équipements non conformes au protocole UPnP QoS.Thus, from elementary messages compliant with the UPnP QoS protocol, the resource reservation method according to the invention makes it possible to conduct an additional resource reservation towards equipment that does not comply with the UPnP QoS protocol.
30 ANNEXE 1 <DeviceReachableMacs zn-ilns="http://www.upnp.org/schemas/PathInformation.xsd" xmlns:xs.i="http://www.w3.org/2001/XMLSchema-instance" ..ns :prv="http: / /myPrivate . corn" mmins :prv2="http: //myPrivate2.com" zsi:scbemaLocatioo="http://www.0 n .org/sche as/2athInfom tion.xs d Pathlnformation.xsd"> <1,Ln.kReachableMa.:;s> kid> <Bridgeld>Bridge0</BridgeId> <ReachableMac>112233aabb03</ReachableMac> </LinkReachableMacs> <LinkReachableMacs> <Linkld>ethl</Linkld> <Bridgeld>BridgeO</Bridgeld> <ReachabieMac>112233aabbO7</ReachableMac> <ReachableIYJac>112233aabbO5</Reachable2ac> </LinkReachableMacs> <LinkReachableMacs> <Linkld>eth2</LinkId> <Bridge1d>Bridge0</Bridgeid <ReachableMac>112233aabb02</Reachablemac> <Reachab:1eMac>112233aabbOl</ReachableMac> <Reachabi.eMac>112233aabbO4</Reachabl.eMac> </LinkReachableMacs> <LinkReachableMacs> <LinkId>eth3</LinkId> <BridgeId>Bridge0</Eridgeld> </LinkReachabIelviacs> </DeviceReachabieMacs> ANNEXE 2 <InitialTrafficDescriotc r > <TrafficDescriptor> <TrafficHandle>any-string</TrafficHandle> <TrafficId> <SourceAddress> <Ipv4>192.168.1.102</Ipv4> </SourceAddress> <DestinationAddress> <Ipv4>192.168.1.150</Ipv4> </DestinationAddress> <IpProtocol>1</IpProtocol> </Trafficld> <AvailableOrderedTspecList> <Tspec> <Tspeclndex>2</Tspeclndex> <MeanDataRate>10000</MeanDataRate> <PeakDataRate>20000</PeakDataRate> <TrafficClass>AV</TrafficClass> </Tspec> </AvailableOrderedTspecList> <ActiveTspeclndex>2</ActiveTspeclndex> <TrafficImportanceNumber>3</TrafficImportanceNumber> <TrafficLeaseTime>6666</TrafficLeaseTime> </TrafficDescriptor> </In:i.ti.alTraft i.cDescript:or> ANNEXE 3 POST /QosDevice/control HTTP/1.1 HOST: 172.20.3.123:50041 SOAPACTION: "urn:schemas-upnp- org:service:QosDevice:l#SetupTrafficQos" CONTENT-TYPE: text/xml ; charset="utf-8" Content-Length: 1157 <?xml version="1.0" encoding="utf-8"?> <s:Envelope s:encodingStyle="http://schemas.xmisoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Body> <u:SetupTrafficQos xmins:u="urn:schemas-upnporg:service:QosDevice:1"> <SetupTrafficDescriptor> <TrafficDescriptor> <TrafficHandle>any-string</TrafficHandle> <Trafficld> <SourceAddress> <Ipv4>192.168.1.104</Ipv4> <PrefixLength>24</PrefixLength> </SourceAddress> </Trafficld> <AvailableOrderedTspecList> <Tspec> <Tspeclndex>2</Tspeclndex> <MeanDataRate>10000</MeanDataRate> <PeakDataRate>20000</PeakDataRate> <TrafficClass>Gaming</TrafficClass> </Tspec> </AvailableOrderedTspecList> <ActiveTspeclndex>2&1t;/ActiveTspeclndex> <TrafficlmportanceNumber>3< /TrafficlmportanceNumber> <TrafficLeaseTime>6666</TrafficLeaseTime> <prv:MyPrivateFlagl>true</prv:MyPrivateFlagl> </TrafficDescriptor> </SetupTrafficDescriptor> <QosStateld>QosDevice-0000</QosStateId> </u: SetupTrafficQos> </s:Body> </s:Envelope>30 ANNEX 1 <DeviceReachableMacs zn-ilns = "http://www.upnp.org/schemas/PathInformation.xsd" xmlns: xs.i = "http://www.w3.org/2001/XMLSchema-instance". .ns: prv = "http: // myPrivate.corn" mmins: prv2 = "http: //myPrivate2.com" zsi: scbemaLocatioo = "http: //www.0 n .org / sche as / 2athInfom tion.xs d Pathlnformation.xsd "> <1, Ln.kReachableMa.:; s> kid> <Bridgeld> Bridge0 </ BridgeId> <ReachableMac> 112233aabb03 </ ReachableMac> </ LinkReachableMacs> <LinkReachableMacs> <Linkld> ethl </ Linkld> <Bridgeld> BridgeO </ Bridgeld> <ReachabieMac> 112233aabbO7 </ ReachableMac> <ReachableIYJac> 112233aabbO5 </ Reachable2ac> </ LinkReachableMacs> <LinkReachableMacs> <Linkld> eth2 </ LinkId> <Bridge1d> Bridge0 </ Bridgeid <ReachableMac> 112233aabb02 </ Reachablemac> <Reachab: 1eMac> 112233aabbOl </ ReachableMac> <Reachabi.eMac> 112233aabbO4 </Reachabl.eMac> </ LinkReachableMacs> <LinkReachableMacs> <LinkId> eth3 </ LinkId> <BridgeId> Bridge0 </ Eridgeld> < / LinkReachabIelviacs> </ DeviceReachabieMacs> APPENDIX 2 <InitialTrafficDescriotc r> <TrafficDescri ptor> <TrafficHandle> any-string </ TrafficHandle> <TrafficId> <SourceAddress> <Ipv4> 192.168.1.102 </ Ipv4> </ SourceAddress> <DestinationAddress> <Ipv4> 192.168.1.150 </ Ipv4> </ DestinationAddress> < IpProtocol> 1 </ IpProtocol> </ Trafficld> <AvailableOrderedTspecList> <Tspec> <2 </ Tspeclndex> <MeanDataRate> 10000 </ MeanDataRate> <PeakDataRate> 20000 </ PeakDataRate> <TrafficClass> AV </ TrafficClass> < / Tspec> </ AvailableOrderedTspecList> <ActiveTspeclndex> 2 </ ActiveTspeclndex> <TrafficImportanceNumber> 3 </ TrafficImportanceNumber> <TrafficLeaseTime> 6666 </ TrafficLeaseTime> </ TrafficDescriptor> </In:i.ti.alTraft i.cDescript: or> APPENDIX 3 POST / QosDevice / control HTTP / 1.1 HOST: 172.20.3.123:50041 SOAPACTION: "urn: schemas-upnp-org: service: QosDevice: l # SetupTrafficQos" CONTENT-TYPE: text / xml; charset = "utf-8" Content-Length: 1157 <? xml version = "1.0" encoding = "utf-8"?> <s: Envelope s: encodingStyle = "http://schemas.xmisoap.org/soap/ encoding / "xmlns: s =" http://schemas.xmlsoap.org/soap/envelope/ "> <s: Body> <u: SetupTrafficTo xmins: u =" urn: schemas-upnporg: service: QosDevice: 1 " > <SetupTrafficDescriptor> <TrafficDescriptor> <TrafficHandle> any-string </ TrafficHandle> <Trafficld> <SourceAddress> <Ipv4> 192.168.1.104 </ Ipv4> <PrefixLength> 24 </ PrefixLength> </ SourceAddress> </ Trafficld> < AvailableOrderedTspecList> <Tspec> <Tspeclndex> 2 </ Tspeclndex> <MeanDataRate> 10000 </ MeanDataRate> <PeakDataRate> 20000 </ PeakDataRate> <TrafficClass> Gaming </ TrafficClass> </ Tspec> </ AvailableOrderedTspecList> <ActiveTspeclndex> 2 &1t; / ActiveTspeclndex> <TrafficlmportanceNumber> 3 </ TrafficlmportanceNumber> <TrafficLeaseTime> 6666 </ TrafficLeaseTime> <prv: MyPrivateFlagl> true </ prv: MyPrivateFlagl> </ TrafficDescriptor> </ SetupTrafficDescriptor> <QosStateld> QosDevice-0000 </ QosStateId> < / u: SetupTrafficQos> </ s: Body> </ s: In velope>
Claims (26)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0605015A FR2901943B1 (en) | 2006-06-06 | 2006-06-06 | A RESOURCE RESERVATION METHOD WHEN TRANSMITTING CONTENT IN A COMMUNICATION NETWORK, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING DEVICE |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0605015A FR2901943B1 (en) | 2006-06-06 | 2006-06-06 | A RESOURCE RESERVATION METHOD WHEN TRANSMITTING CONTENT IN A COMMUNICATION NETWORK, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING DEVICE |
Publications (2)
Publication Number | Publication Date |
---|---|
FR2901943A1 true FR2901943A1 (en) | 2007-12-07 |
FR2901943B1 FR2901943B1 (en) | 2008-12-12 |
Family
ID=37697916
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR0605015A Expired - Fee Related FR2901943B1 (en) | 2006-06-06 | 2006-06-06 | A RESOURCE RESERVATION METHOD WHEN TRANSMITTING CONTENT IN A COMMUNICATION NETWORK, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING DEVICE |
Country Status (1)
Country | Link |
---|---|
FR (1) | FR2901943B1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009094933A1 (en) * | 2008-01-22 | 2009-08-06 | Huawei Technologies Co., Ltd. | Method for processing the packet network tunnel, communication system, and apparatus thereof |
RU2496277C2 (en) * | 2009-05-26 | 2013-10-20 | Нокиа Корпорейшн | Method and apparatus for multimedia session transfer |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030005130A1 (en) * | 2001-06-29 | 2003-01-02 | Cheng Doreen Yining | Audio-video management in UPnP |
US20050165899A1 (en) * | 2003-12-29 | 2005-07-28 | Mazzola Diego R. | Provisioning quality of service in home networks using a proxy interface |
-
2006
- 2006-06-06 FR FR0605015A patent/FR2901943B1/en not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030005130A1 (en) * | 2001-06-29 | 2003-01-02 | Cheng Doreen Yining | Audio-video management in UPnP |
US20050165899A1 (en) * | 2003-12-29 | 2005-07-28 | Mazzola Diego R. | Provisioning quality of service in home networks using a proxy interface |
Non-Patent Citations (1)
Title |
---|
YAVATKAR INTEL D HOFFMAN TELEDESIC Y BERNET MICROSOFT F BAKER CISCO M SPEER SUN MICROSYSTEMS R: "SBM (Subnet Bandwidth Manager):<BR>A Protocol for RSVP-based Admission Control over IEEE 802-style networks", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, May 2000 (2000-05-01), XP015008597, ISSN: 0000-0003 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009094933A1 (en) * | 2008-01-22 | 2009-08-06 | Huawei Technologies Co., Ltd. | Method for processing the packet network tunnel, communication system, and apparatus thereof |
RU2496277C2 (en) * | 2009-05-26 | 2013-10-20 | Нокиа Корпорейшн | Method and apparatus for multimedia session transfer |
Also Published As
Publication number | Publication date |
---|---|
FR2901943B1 (en) | 2008-12-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8577739B2 (en) | Device and a method for ordering product at a premises via an integrated multimedia service system | |
FR2906666A1 (en) | Internal end-to-end quality of service resource reservation method for e.g. Internet protocol network, involves reserving resource in manager to transmit data content on path of sub-network that is not connected to targeted interface | |
EP2262170B1 (en) | Management of shared access network | |
US8306033B2 (en) | Methods, systems, and computer program products for providing traffic control services | |
EP1451982A1 (en) | Data structure, method, and system for multimedia communications | |
EP3603024B1 (en) | Method for recommending a communication stack | |
US20130304877A1 (en) | System and method for dynamic configuration of isn store-based overlay network | |
FR2925808A1 (en) | COMMUNICATION METHOD IN A NETWORK COMPRISING A PRIMARY NETWORK AND A SECONDARY NETWORK | |
EP2460322B1 (en) | Method and system for the automatic selection of transmission media | |
WO2010061119A1 (en) | Method and system for regulating reboot traffic in a telecommunications network | |
EP2767060B1 (en) | Gateway, and method, computer program and storage means corresponding thereto | |
EP2856719B1 (en) | Technique for communication in an information-centred communication network | |
EP2332332A1 (en) | Method and device for redirecting a data flow monitoring query | |
FR2922398A1 (en) | SYSTEM FOR INTERCONNECTING BETWEEN AT LEAST ONE COMMUNICATION APPARATUS AND AT LEAST ONE REMOTE INFORMATION SYSTEM AND INTERCONNECTION METHOD | |
FR2901943A1 (en) | Quality of service resource reserving method for e.g. Ethernet network, involves sending send request to device, and sending resource reservation request conforming to on-line signalization protocol to infrastructure device | |
WO2012010803A1 (en) | Furnishing of information by a mobile terminal in a network | |
US11996930B2 (en) | Traffic management architecture | |
US11849163B2 (en) | Redundant video stream generation | |
EP2031809A1 (en) | Method for processing data streams in a telecommunication network | |
FR3011704A1 (en) | METHOD FOR IMPLEMENTING A COMMUNICATION SESSION BETWEEN A PLURALITY OF TERMINALS | |
FR2908577A1 (en) | Quality of service resource managing method for e.g. domestic network, involves sending information representing accepted value to receiver device to initialize transmission of content based on window size equal to accepted value | |
WO2023047068A1 (en) | Method for controlling access to an application service implemented in a telecommunications network, method for processing a message for controlling access to the application service, and corresponding devices, control equipment, client equipment, system and computer programs | |
CN117880542A (en) | CDN cluster source returning method based on long connection and CDN cluster based on long connection | |
FR3101498A1 (en) | Method for controlling a data flow associated with a process within a shared network | |
EP3769535A1 (en) | Method for distributing content |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ST | Notification of lapse |
Effective date: 20140228 |