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

Abstract

The method involves detecting the presence of a network infrastructure device (140) e.g. personal computer, on a transmission path, where the device is not compatible with a centralized signalization protocol e.g. universal plug and play (UPnP) protocol. A device e.g. switch, compatible with an on-line signalization protocol e.g. subnet bandwidth manager (SBM) protocol, is determined. A send request is sent to the latter device and a resource reservation request conforming to the on-line signalization protocol is sent to the device (140). Independent claims are also included for the following: (1) a computer program product comprising program code instructions for the execution of stages of a method for reserving a resource for an uplink transmission (2) a computer readable medium storing instructions executable by a computer for implementing a method for reserving a resource for an uplink transmission (3) a managing device for reserving a resource for an uplink transmission.

Description

Method of reserving a resource when transmitting content

  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).

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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).

  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.

  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 .

  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).

  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.

  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).

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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).

  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.

  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.

  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.

  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).

  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.

  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.

  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.

  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.

  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.

  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 .

  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.

  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).

  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.

  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. .

  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.

  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.

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 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)

  A resource reservation method in the context of transmitting data content on a transmission path between a source device (110) and a receiving device (120) belonging to a communication network (100), 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 method being implemented by a management device (150) which is a device of said first type, characterized in that comprises the following steps: detection of the presence, on the transmission path, of at least one device of the second type that 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 device (s) of the second detected type (s), a resource reservation request according to the on-line signaling protocol.   2. Reservation method according to claim 1, characterized in that it 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.   3. Reservation method according to claim 1, characterized in that it also comprises the following step: for each device of the second type detected, selection on the transmission path of a separate transition device.   4. Reservation method according to any one of claims 1 to 3, characterized in that it also comprises the following step: -determination of said first type of devices that take into account the resource reservation request according to the online signaling protocol initiated by the transition device.   5. Reservation method according to claim 4, characterized in that it also comprises the following step: - sending to at least one or said first type devices that take into account the resource reservation request according to the protocol of online signaling of a resource reservation request according to the centralized signaling protocol, prior to the request to send to the transition device a resource reservation request according to the on-line signaling protocol.   6. Reservation method according to claim 4, characterized in that it does not include a step of sending to the (x) device (s) of the first type which takes into account the resource reservation request. in accordance with the on-line signaling protocol of a resource reservation request conforming to the centralized signaling protocol.   7. Reservation method according to any one of claims 1 to 6, characterized in that it also comprises an initial step of reception by the management device (150) of a transmission request with quality of service of the device content. source to the receiving device.   8. Booking method according to any one of claims 1 to 7, characterized in that it also comprises a step of receiving a report from the at least one transition device (s) indicating the success or failure of the resource reservation for the transmission of the content.   A resource reservation method in the context of transmitting data content on a transmission path between a source device (110) and a receiving device (120) belonging to a communication network (100), 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 signaling system, characterized in that it comprises the following steps: receiving a request to send a resource reservation request compliant with the online signaling protocol to a device of said second type, located on the path which is not compatible with the centralized signaling protocol; sending said request to said device of the second type.   10. Reservation method according to claim 9, characterized in that the request to send a resource reservation request according to the online signaling protocol is included in a resource reservation request message according to the signaling protocol. centralized.   11. Booking method according to any one of claims 9 and 10, characterized in that it also comprises the following steps: receiving a resource reservation confirmation according to the online signaling protocol; determining whether 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 (150); in the affirmative, transmitting to the management device (150) a positive report concerning the resource reservation for the transmission of the content.   12. Reservation method according to claim 11, characterized in that, if the resource reservation confirmation corresponds to a prior request to send a resource reservation request according to the on-line signaling protocol by a management device ( 150), the reservation method does not include a 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 (110) and the receiving device (120).   13. Reservation method according to any one of claims 9 to 12, characterized in that it 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 on-line signaling protocol corresponds to a content for which a resource reservation request conforming to the centralized signaling protocol by a management device has already been received if it is, the method of reservation 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 reservation request on the path between the source device (110) and the receiving device (120).   14. Reservation method according to claim 13, characterized in that, if the resource reservation request complies with the online signaling protocol corresponds to a content for which a resource reservation request complies with the centralized signaling protocol by a device. manager (150) has already been received, the method also includes sending a positive report regarding the resource reservation request according to the on-line signaling protocol.   15. Reservation method according to any one of claims 9 to 14, characterized in that it also comprises the following steps: receiving a resource release request according to the centralized signaling protocol; determining whether the resource release request corresponds to a content for which a resource reservation request according to the online signaling protocol by a management device (150) has been previously received for at least one device of the second type - in the affirmative sending an on-line signaling protocol compliant resource request to said at least one device of the second type.   16. Reservation method according to any one of claims 1 to 15, characterized in that the centralized signaling protocol is the UPnP protocol and in that the online signaling protocol is the SBM protocol.   17. Computer program product, characterized in that it comprises program code instructions for performing the steps of the reservation method according to any one of claims 1 to 8 and / or 9 to 16, when said program is running on a computer.   18. Storage medium, possibly totally or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the reservation method according to any one of claims 1 to 8 and / or 9 to 16.   19. 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 data content on a transmission path between a device source (110) and a receiver device (120) through said communication network (100), 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 management device (150) being a device of said first type, characterized in that the management device comprises: detection means of 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 according to the on-line signaling protocol.   20. Management device according to claim 19, characterized in that it also comprises: means for selecting, on the transmission path, a common transition device for at least two devices of the second type detected.   21. Management device according to claim 19, characterized in that it also comprises: means for selecting, on the transmission path, a separate transition device for each device of the second detected type.   22. Managerial device according to any one of claims 19 to 21, characterized in that it also comprises means for receiving a report from the at least one transition device (s) indicating the success or failure of the resource reservation for the transmission of the content.   23. Transition 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 data content on a transmission path between a source device (110) and a receiver device (120) through said communication network (100), 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, characterized in that it 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.   24. Transition device according to claim 23, characterized in that it also comprises: means for receiving a resource reservation confirmation according to the on-line signaling protocol; means for determining whether 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 (150); means for transmitting to the management device (150) a positive report concerning the reservation of resource for the transmission of the content, said transmission means being activated if the resource reservation confirmation corresponds to a prior request for transmission of a resource reservation request according to the on-line signaling protocol by a management device (150).   25. Transition device according to claim 24, characterized in that, if the resource reservation confirmation corresponds to a prior request to send a resource reservation request according to the online signaling protocol by a management device ( 150), the transition device does not activate means for 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 device source (110) and the receiver device (120).   26. Transition device according to any one of claims 23 to 25, characterized in that it also comprises: means for receiving a resource reservation request according to the on-line signaling protocol; means for determining whether the resource reservation request conforming to the on-line signaling protocol corresponds to a content for which a resource reservation request conforming to the centralized signaling protocol by a management device (150) has already been received; means for 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 reservation request on the path between the source device (110) and the receiving device (120), said sending means not being activated if the resource reservation request according to the on-line signaling protocol corresponds to a content for which a resource reservation request complies with the centralized signaling protocol by a manager device (150) has already been received.