JP2010035203A - Method for controlling multicast transmission cost and its device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To collect cost information required to be applicable to each charge system so that an operator calculates a charge for an user. <P>SOLUTION: A method for probing a network in order to obtain information for an unit cost of a new session in a multicast network, includes a step of transmitting a probe query message from a downstream device to a upstream device, a step of allowing an upstream device to receive the probe query message, update the local information of the session in the address of the downstream device if the upstream device is receiving a traffic for a session, and estimate an initial unit cost of the new session, and a step of returning a probe answer message to a transmission source of the probe query message. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to multicast transmission, specifically, management of multicast transmission cost.

  Multicast transmission or multicast routing is a method for using the network efficiently. In multicast routing, a tree-type path connecting a source and several receivers is created. This tree includes nodes and branches so that there is a transmission path from the source to each of the receivers. According to this tree structure, the transmission paths from different receivers to a certain node in the tree where the paths are branched are partially the same. By sending only one copy of the packet through each link in the tree, a certain network efficiency can be achieved. At each branch point, the packet is duplicated and a copy of the packet is sent over each downstream link. Here, “downstream” refers to the direction from the source to the receiver, and “upstream” refers to the direction from the receiver to the source.

  FIG. 1 schematically shows a network configuration used for multicast transmission. In FIG. 1, three different individual networks 100, 105 and 110 are shown. These are, for example, networks that are separated by different domains in the IP address space. That is, these are three different types of networks, for example, network 100 is a LAN, network 105 is a mobile network, and network 110 is a wireless LAN network.

  In the network 100, a source 115 of a session to be distributed, which is “downstream”, that is, an arbitrary server capable of distributing information to a receiver, is arranged. This source is, for example, a video streaming server with different channels, a news server (also with different channels), or a provider of information or services.

  The receiver 120 is a device such as a PC, a PDA, or a mobile phone that receives information distributed downstream. In the downstream at the time of multicast transmission, a certain packet is delivered only once as long as possible. For example, in FIG. 1, a packet is delivered only when necessary from the source 115 toward the edge device 125 in the network 105. For example, at device 125, the packet is duplicated and delivered separately to intermediate router 130 or other edge device 135. Further division into two downstream links is performed at router 130 and the duplicated packets are sent separately to edge devices 140 and 145 from this router. That is, the packet is sent once through each link in the tree.

  For purposes of explanation, note that multicast routing is not limited to the IP multicast standard, but refers to any method that can send only one copy of a packet on each link in the tree.

  As is clear from the foregoing, multicasting a large amount of data to a large number of receivers requires a large cost because multicast traffic is duplicated at each branch point in the network. Network resources are always limited, for example, in terms of bandwidth. Thus, increased network usage results in increased costs and possibly reduced reliability. Network traffic caused by multicast routing is a major concern and some countermeasures need to be taken. Therefore, the use of the terms “cost”, “session cost” or “network cost” in the following not only imply an economic point of view or concept, but also have limited (respective) network resources. And that the accumulated resources reflect a certain value. Here, part of this value is used by each transmission, and thus corresponds to “cost” in the sense of the percentage of the “value” of the overall network.

  The concept of “cost”, which is a parameter corresponding to the percentage of network resources, is more economical, “charging”, ie, charging a user or assigning “cost” to a corresponding monetary value. It must be distinguished from the concept.

  Therefore, it is important to distinguish the concepts of fees and costs. Fee refers to the amount paid by the customer. Pricing or charging schemes are based on costs and other issues such as market structure and price stability. In contrast, cost refers to the value given to network resources by the operator. The present invention relates to a method for monitoring, controlling and managing costs associated with multicast sessions of network traffic. Based on this, network providers or operators can apply their own pricing schemes.

  As an example, a range of network services from basic services to advanced services may be born in the future. The basic service is similar to the current best effort service with universal connectivity but no quality guarantee. Advanced services provide a certain quality level or a guaranteed quality level.

  It is each provider that determines the fee structure used in the network. For example, the user is provided with a distinction between basic and advanced network services. This means that there is a fee structure in which the user pays a flat fee for basic services, and advanced services such as wide bandwidth can be obtained on demand. A flat fee is a fee that is paid only to subscribe to a service, apart from the traffic generated or consumed by the user.

  If the client pays only for traffic generated or consumed, a per-use fee applies. The charge for each use is determined statically or dynamically. The former method is based on factors such as time zone and destination, while the latter method is based on the current demand for resources and the overall network load.

  There are several approaches to representing a cost allocation scheme suitable for multicast traffic. Non-Patent Document 1 proposes a scheme called equal link split downstream that distributes costs between receivers. However, this scheme has some drawbacks, such as requiring changes to all routers in the network, and does not mention how to deal with the dynamics of multicast sessions.

  Non-Patent Document 2 describes a scheme that allows flexible allocation of costs between receivers of sessions in a network having a single level of service. In order to calculate and allocate the cost of each session, a mechanism based on servers located in each domain has been proposed. However, this does not mention the mechanism used to allocate costs between receivers. Furthermore, this approach is not suitable for use in networks that can provide services with different quality levels, and the servers located in each domain become a single point of failure.

  Non-Patent Document 3 proposes a layered framework for charging multicast traffic in an ATM network. The fee information is sent in RSVP (ReServation Protocol) messages that are merged in the path from the receiver to the transmitter. Costs are assigned to senders based on information contained in the reservation message, but this framework does not mention how to allocate costs between receivers. Furthermore, this approach also requires changes to all routers.

  Non-Patent Document 4 discloses Receiver-driven Layered Multicast (RLM), which was the first receiver-driven adaptation mechanism for adaptation of reception quality. The number of channels included in a session increases based on parameters such as packet loss, unless the quality of service represented by the number of packet losses indicates some limit. However, RLM does not take into account any user budget or budget when determining the threshold for the upper limit of quality, and has a long convergence time because it is a gradual approach to increasing the number of channels. .

Herzog et al. , “Sharing the“ cost ”of multicast trees: an axiomatic analysis”, IEEE / ACM Transactions on Networking, 5 (6): 847-860, December 1997. Henderson et al. , "Protocol-independent multicast pricing", Proc. of International Works on Networking and Operating System Support for Digital Audio and Video (NOSSDAV), Chapel HILL, North Carolina, USA, USA, USA Carle et al. “Charging and Accounting for QoS-enhanced IP multicast”, Proc. Of IFIP 6TH International Works on Protocols for High-Speed Network, Salem, Massachusetts, USA, August 1999. McCanne et al. “Receiver drive Multicast”, Proc. Of Symposium on Communications Architectures and Protocols (SIGCOMM), Palo Alto, USA, August 1996.

  In order to determine the fee structure, the operator needs information on the transmission cost in order to calculate the fee for each use. In addition, accurate information is useful for periodically updating the flat fee structure. Accordingly, it is an object of the present invention to enable an operator to collect necessary cost information applicable to an individual fee structure in order to calculate a charge for a user.

  A rate adaptation system with multimedia applications according to an embodiment of the present invention allows some quality degradation. However, the degree of tolerance depends on the cost of the multimedia session. Therefore, it is important to control rate adaptation while taking into account how much the user is willing to pay, that is, considering the user's budget. Furthermore, there is a need to obtain information about transmission costs in the network.

  According to one embodiment, a method of probing a network to obtain information about a unit cost of a new session in a multicast network, wherein a source of a session from a downstream device is obtained to obtain a unit cost for the session. Sending a probe query message including information about the new session to an upstream device located in the direction; and the upstream device if the upstream device is already receiving traffic for the session. A stream device receiving the probe query message, updating the local information of the session with the address of the downstream device, and estimating a unit cost of the new session; To return to the transmission source of the collar messages information about the initial unit cost of a session, the method comprising the steps of returning a probe answer message to the sender of the probe query message is provided.

  The unit cost obtained by this embodiment can be used to calculate the cost of the session given to the channel and the transmission rate of the individual channel.

  According to one embodiment, the method stores information about the channel of the new session in addition to information about the address of the downstream device if the upstream device has not yet received traffic for the session. And further forwarding a probe query message in the direction of the source of the session.

  This makes it possible to find an upstream device for which a session is already established, thereby enabling multicast transmission for a new session.

  According to an embodiment, the method is based on a total cost for the total available bandwidth in the upstream device and a unit charge as a percentage of the total available bandwidth, and a transmission cost per unit bandwidth. And approximating the unit cost.

  This allows the determination of unit costs under a given economic boundary condition at a certain device in the network.

  According to one embodiment, the method includes returning the probe answer message in a downstream direction, wherein each unit in each downstream device through which the probe answer message passes on its way to the destination of the new session. Cost is updated.

  “Traveling” probe answer messages and updating them at each network device is an efficient and accurate way to approximate the total unit cost based on the network devices for which the session has already arrived at the destination.

  According to one embodiment, the method includes adding a local unit upstream cost received via the probe answer message and a local unit downstream cost to obtain a total unit downstream cost. .

  According to one embodiment, the method is located at the edge of a network, checking whether the upstream device has already received traffic for the session, estimating the unit cost Generating the probe answer message only at a network device.

  This only requires that a mechanism for estimating unit costs be implemented on the edge devices in the network so that most of the existing network infrastructure, such as intermediate routers, can be used without any changes. Become.

  According to one embodiment, the method includes a step in which an intermediate network device not located at an edge in the network transparently forwards the probe query message and the probe answer message.

  Transparent transmission is actually transferring these messages in the sense that the intermediate network device simply forwards the messages related to the cost estimation process and must recognize and process the content. "does not process.

  According to an embodiment, the method includes one or more free space in an existing network protocol in which the probe query message, the probe answer message, and the unit cost information are different from a field reserved for payload transmission. Includes steps sent by field.

  This is an efficient way of using existing network protocols to transfer messages and information related to cost estimation processing through devices such as intermediate routers in existing network infrastructure.

  According to one embodiment, the method includes receiving a probe answer message including information about a unit cost of a session from an upstream device, and at a device that has received the probe answer message, a method of a session carried by the probe answer message. Updating a unit cost; and forwarding the probe answer message to a destination of the session.

  According to an embodiment, the method includes: in each upstream device that has received the probe query message, information about the new session, its destination and channel, and the downstream device that is the source of the probe query message And updating the session information to store information about.

  Updating information about active sessions or newly established sessions is useful to allow cost allocation for multiple users. Furthermore, it keeps the network device informed about active sessions and established sessions.

  According to one embodiment, the method includes setting a timer when an upstream device does not receive traffic for the new session identified by a probe query message and receives the probe query message; Erasing information stored for this session if the timer for the new session expires and the rate for this session is still zero.

  This ensures that the network device is not flooded with information about sessions that are no longer active, or sessions that have never existed before (eg due to budget issues).

  According to one embodiment, the method includes the step of storing information identifying a session and information regarding the cost of the session only at an edge device of the network.

  This keeps the need for modification of an existing network low when implementing one embodiment of the present invention.

  According to one embodiment, the method includes the step of only the edge device of the devices in the network generating a probe query message and a probe answer message. This also reduces the need for modification of the existing network when implementing one embodiment of the present invention.

  According to one embodiment, the method is a method for controlling a reception data rate of a session including a plurality of channels distributed to a receiver via a multicast network on a receiver basis, wherein the unit cost and each channel Determining the number of channels allowed by the budget based on the rate and the budget for the transmission cost, and running an acceptable number of channels for the session based on budget considerations. Including methods.

  This allows for rapid adjustment of channel selection based on cost considerations. The unit cost can be determined by the method according to the above-described embodiment.

  According to one embodiment, the method includes the step of determining allowed channels based on the budget or even the priority of individual channels. This takes into account the priority selection made by the user.

  According to one embodiment, the method generates a probe query message in response to a start signal for initiating a session at a destination and queries for the unit cost of the session and sends the probe query to the source of the session. Forwarding a message; receiving a probe answer message from an upstream device located in the direction of the source of the session and having information on unit cost; and from the channel with the highest priority based on the received information First subscribing to an acceptable number of channels according to the budget determined for the session.

  According to one embodiment, the method repeatedly receives a cost adjustment message including updated information about the cost of a session at the destination of the session, and the updated cost is lower than the budget for the session Subscribing to the number of additional channels allowed by the budget and starting from the session with the lowest priority until the budget criteria are met if the updated cost is higher than the budget. Unsubscribing the channel.

  This allows for continuous updates about proper selection of channels.

  According to one embodiment, the method comprises the steps of a network processing different classes of services, sessions belonging to a class, and classes assigned all values and corresponding total bandwidths; And estimating the unit cost depending on the class to which the session belongs.

  This takes into account that the network is divided into different classes with different values assigned to unit bandwidth.

  According to one embodiment, a method for allocating transmission costs within a multicast network among downstream links, wherein (1) an indication relating to upstream costs, which is the cost of a session received by the device from the upstream direction. Receiving information from an upstream device, including: (2) allocating the upstream cost between downstream links originating from the device based on a certain allocation scheme; , (3) determining a local cost for each downstream link based on the total rate of each session and the total bandwidth and corresponding cost of the network; and (4) a step for each downstream link ( 2) By adding the resulting cost resulting cost and Step (3), the method comprising calculating a total cost for each downstream link is provided.

  According to an embodiment, the method includes the step of the allocation of the transmission cost between the downstream links being performed separately for each session on each downstream link.

  According to one embodiment, the method includes allocating the cost of each session on each downstream link among edge devices in the network that receive the respective session via the downstream link.

  According to one embodiment, the method forwards a cost adjustment message including information about transmission costs on the respective downstream links to downstream devices in each downstream link in the network; and the downstream devices Updating the upstream cost based on the received cost adjustment message.

  According to one embodiment, the method comprises the step of forwarding the cost adjustment message to the edge device located in the direction of the downstream link, wherein the edge device is upstream costed to the downstream edge device. Processing the cost adjustment message in providing information regarding.

  According to one embodiment, the method includes the step of the cost adjustment message individually including cost information for each session in the downstream link.

  According to one embodiment, the method includes a cost adjustment message from an upstream device, a cost leave message from a downstream device notifying about channel or session cancellation, and cost information at the network device. Can be triggered by one or more of a timer that is repeatedly set to ensure repetitive updates.

  According to one embodiment, in a multicast transmission network, a method in which customer terminals allocate transmission costs among customers connected to edge devices in the network, based on the reception rate used by each customer A method is provided that includes the step of allocating the cost of a delivering session among customers who have subscribed to the delivering session.

  According to one embodiment, the method uses channels based on allocating an approximate cost for a session in an access link among the channels of the session based on a ratio between the rate of each channel and the total rate of the session. Distributing the cost of each channel evenly among each customer. This allows the accumulation of channel costs allocated to each customer based on the channels that each customer subscribes to.

  According to one embodiment, the method carries the total cost acquired for each session to each customer device through a cost adjustment message, and the total cost information as input to a received data rate control method according to another embodiment. Using a step.

  According to one embodiment, an apparatus for probing a network to obtain information about unit costs of a new session in a multicast network, the downstream device for obtaining unit costs for the session A transmitter for transmitting a probe query message including information about the new session towards an upstream device located in the direction of the source of the session, the upstream device receives the probe query message, and If the upstream device is already receiving traffic for the session, update the local information of the session with the address of the downstream device and approximate the initial unit cost of the new session And a responder for returning a probe answer message to the probe query message sender to return information on the initial unit cost of the session to the probe query message sender. Is done.

  According to a further embodiment, an apparatus comprising an element or unit for performing a method according to an embodiment of the invention is provided.

It is a figure which shows the network structure by one Embodiment of this invention. It is a figure which shows typically the mode of signal transmission in embodiment of this invention. It is a figure which shows typically the mode of signal transmission in embodiment of this invention. It is a flowchart which shows one Embodiment of this invention. 6 is a flowchart illustrating a further embodiment of the present invention. 6 is a flowchart illustrating a further embodiment of the present invention. 6 is a flowchart illustrating a further embodiment of the present invention.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

  Embodiments of the present invention relate to multicast transmission in a network. This embodiment relates to various elements that are closely related to each other. These elements or mechanisms are budget-based rate control (BRC), unit cost probing (PUC), transmission cost allocation (STC), and cost per customer allocation (DCC). . These mechanisms are described in more detail below, but the above abbreviations are used to indicate these mechanisms.

  According to one embodiment, a mechanism is provided for performing budget-based rate control for a session. A session is, for example, a video session that includes several channels with different theme content. A user can use a multimedia application running on his or her terminal to identify, for example, the channels that he wants to deliver and the sources that deliver sessions containing those channels. Can join such a session. The user can further specify or assign priorities to the individual channels selected for the session that the user subscribes to. Alternatively, the priority of one or more of these channels can be determined in advance. If the user already has a running session or the user wants to open more than one session, the user can assign a priority to each session according to one embodiment. it can. Once a session is defined by the user and the user joins, a further procedure according to an embodiment of the present invention is as follows.

  Once a user joins a session, the unit cost for that session is obtained. This is done, for example, by a probing mechanism for probing unit costs, described in detail below. Based on such a probe, a cost parameter related to the session, for example, “unit cost” is acquired. This is, for example, the cost of transmitting 1 bit per second for this session. Based on the “unit cost” obtained in this way, the total cost of the session defined by the user is calculated. . This calculation is based on the rates of the individual channels belonging to this session. Therefore, based on the definition of the session that the user has subscribed to, ie the selected channel and their rate, the total cost of this session is based on the unit cost giving the cost for a unit bit rate (eg 1 bit / second). Calculated.

  The total cost calculation is performed at the network device that requested the start of the session, that is, the destination of the session or the final downstream device in the downstream path originating from the source device. Once the “destination device” or “receiving device” receives the unit cost parameter from the upstream device in response to the probe query message, it begins calculating the total cost of the session.

  When the total cost of the session defined by the user exceeds the user's limit (“budget”), rate adaptation for the purpose of “cost control” begins to operate. That is, it ensures that the costs associated with the session are within the budget. For this reason, according to the adaptation mechanism, only the number of channels that can be distributed within the range not exceeding the budget is subscribed. Preferably, this is done by starting with the channel with the highest priority.

  With such a mechanism, the transmission rate of a session can be adapted instantaneously (without any delay) up to the user's budget, thereby resembling a receiver hierarchical multicast (RLM) driven by packet loss as a parameter. Long convergence times associated with complex mechanisms can be avoided. Furthermore, this RLM does not consider any budget issues.

  According to one embodiment, the number of channels can be adjusted based on, for example, updated information regarding session costs. This updated information is provided by a mechanism such as “allocation of cost per customer” described later.

  FIG. 1 schematically shows a network configuration according to an embodiment of the present invention. This figure shows which elements are implemented and functioning in which part of the network. As can be seen from FIG. 1, the BRC is implemented in the receiver. The BRC receives a unit cost transmitted from the upstream device as an input. Thus, as long as the network can provide unit costs for the session on demand, the BRC need only be implemented at the receiver without any modifications to the rest of the network.

  FIG. 1 further shows in which network elements they need to be implemented with respect to other mechanisms such as PUC or STC and DDC.

  According to one embodiment, the receiving device can subscribe to and maintain two or more sessions simultaneously. In such a case, there is an individual budget for each session, or an overall budget is established for the full cost of all sessions. In the former case, the system operates as described above by individually determining permissible channels for each session so as not to exceed the budget. In the case of the latter overall budget, these channels can be determined based on the priority of each channel. Alternatively, for example, the channel with the highest priority for this session is selected one by one (starting with the session with the highest priority) based on the ranking of the session. Subsequently, the channel with the highest priority for the next session is selected, and so on until the channel with the highest priority for the session with the lowest priority is selected. A selection scheme can also be used. If the budget has not been exceeded, the procedure is repeated until the second most important channel is selected for the highest priority session and the budget is exceeded if more channels are allowed. Continue to.

  Note that the network offers different classes of service (eg of different quality levels) and that in this case a session belongs to a class and the unit cost can be determined separately for each class. Don't be. Usually, higher quality services require more network resources, so the unit cost for services belonging to the “higher class” is higher.

  Hereinafter, a mechanism for probing a unit cost according to an embodiment (hereinafter also referred to as PUC) will be briefly described.

The PUC provides information on the approximate unit cost for a newly delivered session to the control function of the terminal (the receiving device that is the “target” of the new downstream session). Thus, the PUC probes the network device at the edge of the network between the customer where the session exists and the first network device. Referring to FIG. 2, the PUC is shown briefly. There is an active session S 1 between the source 215 and the receiver 240. This session is distributed to the receiver 240 via the (edge) device 225 and the other (edge) device 235. Here, the user of device 220 wants to start a new session and also determines the desired source (device 215), channel, and possibly the channel priority (if there is no predetermined one). Coincidentally, this new session is in principle not identical (or a subset of S1) to the existing session S1, which allows the use of multicast. Subsequently, the query message PROBE transferred to the source device. QRY is generated. There is no active session on the first edge device 235 to which this query arrives that is (at least in part) the same as requested. This query message is therefore forwarded further upstream in order to search for nodes in the network where the same session is already operating (at least in part). This query message reaches the node 225 in which the same session is already operating (edge) after passing through the intermediate node 230. This means that the node 225 can be used as a branch point for multicast transmission and that the (local) cost for this session can be determined at this node. In order to inform the receiving device of the unit cost of this session, the unit cost for this session obtained based on this determination is the probe answer message (PROBE). Through the same path via (AWR).

The same session is Probe Checking whether the network device that has received the Qry message is already operating can be performed, for example, based on a session identifier that identifies the session. Here, the session provided by the source includes a predetermined series of channels, which are assigned a “session identifier”. This session identifier is then used by the receiving device that initiates the new session and assigned to the newly created session. Here, the newly established session does not have to include all of the channels belonging to the “all sessions” provided by the source, but forms and defines a newly established session It should be noted that the user can select some of these channels provided by the source under the session identifier for. However, a newly established session needs to include at least a “subset” of “all sessions” provided by the source under a session identifier. As an example, a session having session identifier S1 and provided by source X includes channels 1, 2, 3, 4, 7, 8, and 9, and information that such a session can be delivered is received by the receiving device. To be told. Subsequently, the user can select a newly opened session at his / her receiving device, and can select, for example, channels 1, 2, and 4 as channels to be included in the session. This session is still identified by the session identifier S1. This session identifier is Probe In response to receiving a Query message, it can be used by the network device to check whether such a session is already running on this network device (and is being delivered to a different destination). If so, Probe _ AWR message containing the local unit cost is generated and returned. According to one embodiment, the channel identifier can also be used to identify the session, for example by using the first channel of this session, or the channel conventionally used as the channel identifier.

  Based on the received answer message and cost information, the receiving device can determine the (actual) cost of the session and use an acceptable number of channels without exceeding the user's budget.

  According to the above example, the same session as requested at the intermediate node 230 is not operating, so the query message is further forwarded in the upstream direction. However, according to one embodiment, the query message is forwarded further upstream without generating a response at the intermediate device 230 even if the same session is running at the intermediate device 230. According to this embodiment, only edge devices such as devices 225 and 235 in the network generate query messages (and answer messages). Thereby, when implementing this embodiment, it is not necessary to modify an existing network for an intermediate node such as the node 235. Intermediate nodes need only be able to (transparently) forward query messages and answer messages, for example by using free fields in existing network protocols that are not evaluated by intermediate nodes.

  It should be noted that the query message can also be used to inform the network device about the characteristics of the newly delivered session, such as the destination, source, and channels belonging to the session.

  The PUC probes the network to obtain information about the unit cost of the session to be delivered, and determines the convergence time required to reach a good reception quality level with an emphasis on the customer's budget and the budget-based adaptation mechanism (e.g. BRC) can be shortened.

  It should be noted that the unit cost sent to the customer (user or network) can reflect the fee structure agreed between the customer and its network provider. This means that cost information exchanged between the provider and the customer can be modified by the provider's billing system. Also, if a probe message (and corresponding answer message) moves across a network or domain boundary, this may be sent in an answer message, for example, to reflect pricing for sessions across networks of different providers Affects the unit cost.

  According to one embodiment, the probe query message is forwarded in the upstream direction until the corresponding session reaches the already operating device. If there is no active session between the source and any terminal of the user, the probe query moves in the upstream direction towards the edge device in the network that is closest to the source. In a standard multicast environment, the source of the multicast transmission that provides the session is between this edge device and the source to establish the session by an edge device in the network that delivers at least data further downstream. And the session is already working. If the user or receiving device has not yet requested a provided session, the edge device in the network drops the session packet received from the source. Thus, for the first probe query message received for a session, this network edge device generates a probe answer message and sends it in the downstream direction with the (all) local unit cost at this network edge device.

  According to a further embodiment, a mechanism (hereinafter also referred to as STC) for allocating the transmission cost of multicast transmission to the downstream link is provided. According to one embodiment, this takes into account the dynamics of the multicast tree in a class-based network. In such networks, network operators provide the ability to distinguish between different network classes of traffic. Here, the different network classes each have a different cost, for example providing different quality levels. The STC according to one embodiment distributes the upstream transmission cost of the multicast tree among the downstream links only at the edge devices in the class-based network. It should be noted that the term upstream transmission cost means the cost that the session has by being transmitted from the source to the current edge device. For this reason, at each edge device, the STC collects information about the cost of the session provided by upstream neighboring devices and is used by the total rate of the session (the sum of the rates for each channel) and this session. Distribute costs among downstream edge devices taking into account network class bandwidth and costs. That is, the bandwidth and cost of the network class used by this session corresponds to “all values” assigned by the network operator to which class (to which this session belongs). Furthermore, the total rate of the session (derived from the measuring device) corresponds to a proportion of all this value based on allocating the total rate of the session according to the bandwidth of the class to which the session belongs.

  When neighboring devices are located at different network edges, the cost transferred from the upstream neighboring device to the downstream neighboring device should reflect the pricing structure agreed between the two network providers. Should be noted. This means that the cost information exchanged between the provider and the customer can be modified by the provider's charging mechanism. It should further be noted that the definition of value for bandwidth and cost for each network class is a matter of policy and not the actual cost allocation mechanism (STC). Instead of simply conveying the upstream cost to the downstream device, the STC allocates the cost of the session to be distributed across the downstream links of the edge device, thereby reducing the session cost at each external interface. This allows the network provider to attract and retain customers by giving them a good trade-off between quality and cost.

  According to a further embodiment, a mechanism (hereinafter also referred to as DCC) for the allocation of costs per customer is provided. This mechanism distributes the cost of this delivering session among the customers who subscribe to the delivering session based on the reception rate used by each customer. Thus, the DCC collects information about each session from the terminal and considers the number of channels each customer has subscribed to and the rate of each channel, thereby reducing the cost of these sessions (given by the STC, etc.) Distribute among all customers receiving these sessions. It should be noted that the cost sent to the customer reflects the fee structure agreed between the customer and the access network provider. This means that the cost information exchanged between the provider and customer can be modified by the provider's billing mechanism.

  Referring now to FIG. 1, a typical network configuration is shown that further represents which of the aforementioned components are installed in which part of the network. As can be seen from FIG. 1, only BRC is to be installed in the terminal, whereas other mechanisms such as PUC, STC and DCC are installed in the network. Furthermore, all functions required by the PUC, STC and DCC are located in the edge device without interfering with the internal router. While PUC and STC are active at all edge devices, DCC is only active at the network edge that acts as an access gateway to individual customers. This indicates that embodiments of the present invention can be implemented without modification to all routers in an existing network, and instead only require modification at the terminal (receiver) and edge device.

  FIG. 2 shows the signaling used by the mechanism described above. FIG. 2a shows signaling triggered by BRC, which is used by the PUC to collect information about the unit cost of this multicast session when a new customer joins the multicast session. . FIG. 2b shows the signaling used by the STC and DCC to convey cost information. The STC conveys information about the cost of the session on each downstream link, while the DCC conveys information about the cost associated with each customer. As shown in FIG. 2b, the STC and DCC according to one embodiment are triggered by a timer, and the DCC uses another mechanism such as STC to allocate the cost of each session between each downstream link on which the session exists. Use output as input. A more detailed description of these mechanisms according to embodiments of the present invention follows.

  First, BRC according to an embodiment will be described in detail with reference to FIGS. 2a and 3. Here, when referring to BRC, PUC, STC, and DCC as “mechanism”, it is understood by those skilled in the art that such “mechanism” can be realized in a network device by appropriately programming a microprocessor in the network device. Note that it will be immediately apparent. Thus, such a mechanism may cause the microprocessor and possibly the peripheral device to have some software code that operates as described herein, or a gate array that is designed to operate as described herein, It can be realized by any electronic device or certain hardware such as an integrated circuit. In view of the foregoing, the term “mechanism” as used herein should be understood as a method that includes a series of steps that, when executed, correspond to the operation of a network device as described herein. It is.

The BRC receives an application signal indicating the start or end of a session, and sends a probe answer (Prob) from the network. Message (also called Awr) and cost adjustment (Cost There are three triggers: message reception (also called Adj). Processing described below is executed in response to such an event.

When an application signal is received that starts a session.
Joining a session (eg initiated by a user using a multimedia application running on the user's terminal) is information about all channels that together define the session to be delivered (eg source, channel identifier, priority of each channel) , Rate) and the customer's budget for the session. This corresponds to, for example, step 305 in FIG. Since this occurs when IP multicast is used to create a distribution tree, the source and channel identifiers are IP addresses. These information are received and stored by the BRC implemented as a software component that is installed and operating on the user's terminal according to one embodiment (step 310 of FIG. 3).

After storing information about the session, the BRC queries the probe query (hereinafter Probe) to query for the approximate unit cost of the session. Step 315) of FIG. 3, also called Qry, is sent to the source of the multicast session. This is also shown, for example, in FIG. 2a showing a probe query message originating from device 220 when the user of device 220 newly joins an existing session S1 being used by the user of device 240. The purpose of the probe query message going in the upstream direction is a message including information on unit cost, a so-called probe answer (hereinafter referred to as Probe). Triggering the return of a message (also called Awr).

Probe Receiving the Awr message (step 320 in FIG. 3).
This message provides information about the approximate unit cost of the session. The method of actually collecting this information in the network will be described later in connection with PUC. Based on this unit cost for each channel and the rate of each channel (already stored in response to the session start signal), the BRC approximates the cost of each channel (step 325 in FIG. 3). After this, the BRC starts with the channel with the highest priority and subscribes to the number of channels acceptable by the customer's budget (step 330 in FIG. 3).

Cost adjustment (Cost Adj) Message reception.
BRC has Cost with updated information regarding session cost An Adj message is periodically received (step 335 in FIG. 3). The method for updating the cost information in the network will be described in detail later in connection with the STC. The received update cost information is used to adjust the number of channels (step 340 in FIG. 3). This is done as follows according to one embodiment.

  (A) If the updated cost is lower than the customer's budget for the session, the BRC subscribes to the channel as much as allowed by the budget (the channel starts with the most important one). The number of channels to join is calculated based on the unit cost of the session and the rate of each channel.

  (B) If the updated cost is higher than the customer's budget, the BRC cancels the channel as long as the cost is higher than the budget (the channel cancels starting from the non-critical one). If the budget is not sufficient to maintain the basic channel of the session, a signal is sent to the application requesting the user to increase the budget. If the budget does not increase, the BRC performs a process of leaving the session as described below. If not, repeat steps (a) and (b) as described above.

Receive application signal to end session.
The BRC exits all channels of the session (step 350) and deletes all information about the session (step 355) (according to one embodiment, if the system is IPv4 or IPv6, respectively, IGMPv3 Or a cancel message (which is MLDv2) (step 345 in FIG. 3). In an application signal, a session can be identified by a session identifier, which is a dedicated identifier or, in some embodiments, for example, a channel identifier that identifies a session by convention.

  When a BRC joins a channel, the channel identifier and optionally the channel rate are included (if there is nothing predetermined or not unchanged). Information about the channel must be sent upstream to trigger the return of a response carrying information about the unit cost of the session along with information identifying the session (eg, by using a channel identifier). That is, a mechanism that allows this information to be conveyed should preferably be provided by an existing networking mechanism or protocol.

  The present invention relates to multicast, and some mechanism for constructing a multicast tree already exists in the network in which the present invention is implemented. As an example, IGMPv3 or MLDv2 is used at the access point for Ipv4 and Ipv6, respectively. IGMPv3 is described in “Internet Group Management Protocol, version 3, RFC3376, IETF, October 2002” by Cain et al. , IETF, June 2004 ”.

  As described above, auxiliary data fields of IGMPv3 and MLDv2 reports can be used in the same way as SIP (Session invitation protocol) INVITE messages to carry data. IGMPv3 and MLDv2 reports, standards for group messages, allow routers to collect information about individual users because the “host suppression” mechanism that existed in previous versions has been removed. In any case, the message used to join the channel must also contain the most important channel identifier in the session. BRC can use IGMPv3 and MLDv2 reports or SIP (Session Invitation Protocol) BYE messages (including unsubscribed channel identifiers) to unsubscribe from the channel. Alternatively, other protocols or data fields of other protocols can be used.

  BRC in one embodiment can be combined with a rate-based adaptation mechanism such as RLM that adjusts the number of channels based on the rate of packet loss. One possible combination in this scenario is to have a BRC that controls the increase in reception rate and a mechanism like RLM that controls such a decrease in rate (if too much packet loss occurs). I will.

  BRC needs information about the unit cost of a session in order to operate. This information is provided by a PUC (Probing Unity Costs) mechanism which will be described in more detail below with reference to FIG.

The PUC according to one embodiment is Prob Qry message reception and Prob Awr message reception and Zero There are three triggers: the end of a timer called a rate timer. After one of these events, processing as described below is executed.

Probe from downstream devices Get Qry message.
Probe for a session (eg, identified by its session identifier) In response to the reception of Qry (step 400 in FIG. 4), the PUC operates when the PUC operates. It is checked whether the device that has obtained Qry has already received traffic for such a session (ie, there is such a local session operating on this device) (step 405). If so, the PUC first receives the received probe. The local information of the session is updated with the address of the downstream device that is the transmission source of Qry (step 410). The PUC is then based on the local unit rate of the session (eg, 1 bit / second), the bandwidth allocated to the class used by this session, and the cost of this class. Estimate the local unit cost for the session in the link that received the Qry. As an example, assuming that the (total) bandwidth of the class to which the session belongs is 1 Gbit / s and that the corresponding (total) cost is 2000 euros, 1 bit for 1 session in this class The unit cost per second is 2000/10 ⁹ euros.

Probe to get the “all” unit cost of a session The “local” unit cost obtained so far for the session in the link from which the Query was obtained is added to the “unit upstream cost” of this session. This unit upstream cost is calculated from the upstream direction to Probe. It is the cost caused by the data moving to the device that received the Qry message. This unit upstream cost is calculated based on the upstream cost and the rate of the session (which can be determined based on an instrument that measures the received data rate that is located in the upstream interface). By dividing the upstream cost (already stored in the device by an existing session) by the data rate, the unit upstream cost can be obtained. These unit upstream costs added to the local unit cost (ie, “unit downstream cost”) are Give the total local unit cost for the session at the device that received the Qry message.

The resulting total unit cost is calculated as Probe Probe returned to the sender of the Qry message Included in the Awr message. According to one embodiment, all messages are sent with an IP alert option set to be obtained by a PUC located in the path to the destination.

  If at step 405 the result is that the device has not yet received traffic for the session, the PUC stores information about the channel of the session in addition to information about the address of the downstream device (step 425).

In addition, according to an embodiment, information about the receiving interface can be stored. Subsequently, the PUC moves toward the source of the session to be distributed. Forward the Qry message. After all these processes are completed, the PUC is zero. Set the Rate timer. Probe When a Qry message is received by an upstream edge device in the middle of the upstream, the procedure at this device is performed in the same manner as described above.

Probe from upstream device Get Awr message.
Probe for a session (specified by the most important channel) In response to the reception of Awr (step 435), the PUC Update the unit cost of the session sent through the Awr message and forward this message to its destination. For this reason, PUC is a probe. Estimate the local unit cost for the downstream link starting from the device that received the Awr message. This is Probe As described in the previous case in connection with the reception of the Qry message, the bandwidth allocated to the network class to which the session belongs, the corresponding cost or value allocated to this bandwidth, and the unit of the session ( Based on the downstream) rate. This gives the local unit cost of the session and must be added to the unit upstream cost to get the total unit cost. However, this unit upstream cost is This information is received as information included in the Awr message, and is the same as the total unit cost acquired in the device located one step up in the upstream direction.

In other words, for the first time in the upstream direction, the probe in the same session is operating on the probe. Upon receipt of the Qry message, the total downstream unit cost in this device for the newly established session on this device is estimated by adding the local unit upstream cost and the local unit cost in the downstream direction. The The local unit upstream cost can be obtained by dividing the rate of an already active session (measurable by the instrument) coming from the upstream direction by the upstream cost of the already active session. Since the device monitors the status of the cost of an active session, the latter information is available on this device. Also, the local unit upstream cost is calculated when the currently active session starts. Since it has been distributed once to this device by the Awr message, it can be acquired. The local unit (downstream) cost is estimated based on the total bandwidth and all values assigned to it, and the unit rate (eg 1 bit / second). The total unit downstream cost is the sum of the local unit upstream cost and the local unit downstream cost for this device.

Once the total unit (downstream) cost is calculated at this device (by adding the local unit cost to the local unit upstream cost), it is conveyed in the downstream direction. In each (edge) device in the downstream direction, the total unit cost is calculated from the upstream direction to the Probe. It is updated by adding the local unit downstream cost to the value of the local unit upstream cost received via the AWR message. A probe that requests the start of a session, which can select a channel suitable for the session to protect the budget based on the total unit cost, This procedure continues in the downstream direction until it receives an Awr message (and the total unit cost carried and constantly updated by this message in the middle of the downstream direction).

Zero End of the rate timer.
When this timer expires for a particular session (step 445), the PUC erases the stored information for this session if the rate for this session is still zero (step 450). This sometimes erases records in the device for sessions that are no longer active or that have not been activated (eg due to budget limits).

Hereinafter, the distribution of the transmission cost between the downstream links will be described in detail by referring to FIG. 5 which explains the operation of STC in detail. This mechanism in one embodiment is Adj message reception and Cost Receiving Lve message and Split There are three triggers: the end of the Costs timer. The following processing is executed after such an event.

Cost from upstream device Receiving an Adj message.
Cost for a series of sessions (specified by session identifier) After receipt of the Adj message (step 500 in FIG. 5), the STC checks whether these sessions are still active on the device (step 505). For all sessions that no longer exist, the STC Cost meaning Cost Leave to the source of the Adj message An Lve message is sent (step 510). For all sessions that are still locally active, the STC updates local information regarding the upstream cost of these sessions (step 515).

Split End of the Costs timer (step 520 in FIG. 5).
When this timer expires, the STC executes the following process to update the cost of the session in the device (step 525).

(A) Regarding each session. Allocate these upstream costs among the downstream links where sessions exist. An example calculation considers the ratio of the session upstream rate to the session rate in each downstream link. Suppose the upstream link rate (ie, the rate at which sessions enter the device from the upstream direction) is 100, downstream link A has a rate of 80, and downstream link B has a rate of 70. Assuming that the downstream link C has a rate of 100, the upstream costs are the downstream links A and B such that A is 80/100 of the upstream cost, B is 70/100, and C is 100/100. And C. The rate of the session on the downstream link is estimated based on the rate of each of the channels and the value collected from the instruments present on the link. The session upstream rate is Cost It can be collected in an Adj message or based on instruments installed at the upstream interface of the edge device.

  As an alternative, it is also possible to allocate costs so that A is 80/250, B is 70/250, and C is 100/250 in the above example. This takes into account the benefits that the network provider gains from using multicast and transfers this benefit directly to the customer. In other words, the more people participating in a multicast session, the less network resources are required (as compared to serving the same number of people via unicast transmission), resulting in higher costs between users. Can be distributed at.

  In another embodiment, the cost can be allocated based on the ratio of the upstream cost of the session and the number of downstream links in which the session exists. In the above example, the upstream costs for the downstream links A, B, and C are each 1/3 of the upstream cost.

  (B) For each downstream link. Estimate the local cost of each delivering session on this link based on the local rate of the session, the bandwidth allocated to the network class used by this session, and the cost of this class. Note that the mechanism used to set the class bandwidth and cost for each link on each edge device is a matter of policy and does not affect the behavior described in principle herein. It is. By way of example only, assume that the bandwidth allocated to the network class used by the session is 200, the value of this class is 100, and the session uses a rate of 4 to deliver on this downstream link. The local cost of the session is 4/200 * 100 = 2.

  After this determination, the total cost of the session on the downstream link is calculated by adding the local cost of the session in this link and the upstream cost share of this session (the value calculated in step a). The

(C) For each edge device in each downstream link.
Note that the STC collects information about each downstream edge device (information about its address and the number of channels for each session present in such a downstream device) using a probe mechanism such as the PUC described above. Should. This information can be used to more accurately allocate downstream link costs.

  According to one embodiment, the transmission cost of each session on each downstream link calculated in step b is distributed among all downstream edge devices operating this session. As an example, the determination of the cost of the downstream link from device 125 to device 130 in FIG. 1 results in a value of 100, and the cost of the downstream link from device 125 to device 135 results in a value of 50. Assume that The resulting total downstream link cost is 150, but since device 125 knows that devices 135, 140, and 145 are running the same session, device 125 may be devices 135 and 140, for example. And 145, the total cost of 150 can be distributed among these three devices.

  It should be noted that without the provider performing this allocation, it can decide to simply send the cost (step b) calculated for each downstream link to all downstream edge devices reachable via this downstream link. It is. This means that in the example of FIG. 1, devices 140 and 145 must each bear a session cost of 100.

Once cost allocation has been made among all edge devices that receive this session, the STC has a Cost with information about the costs of all sessions present in this device. Send an Adj message to each downstream edge device.

Cost Leave (Cost from downstream device Lve) Receive message.
After receiving such a message (step 535), the STC From the list of edge devices of each session included in the Lve message, Cost The address of the edge device that sent the Lve message is deleted (step 540).

According to one embodiment, at the edge access gateway (the gateway accessed by an individual customer's terminal), the communication with the individual customer that arrives through this gateway is performed by the DCC described in detail below, so that the STC mechanism Is Cost Cost not sent Adj message Do not process Lve messages.

FIG. 6 provides a more detailed explanation of the operation of the DCC (cost per customer) mechanism. This mechanism consists of obtaining a subscription message or a subscription cancellation message from the terminal, and Dist. Costs It has two triggers, that is, a timer end called a Recv timer. The following processing is executed after such an event.

Obtaining a subscription / subscription message with information about the customer.
Information gathered in IGMPv3 and MLDv2 reports, or SIP INVITE or BYE messages, sent by a BRC-like mechanism to know the channel of each session and used to convey join or unsubscribe messages Is used (step 600 in FIG. 6). After receiving such a message, the DCC stores each session information by deleting information about the new channel or deleting information about the existing channel, if the message is to join or unsubscribe to a channel, respectively. The local information is updated (step 605). If the updated cost is subsequently determined, this updated information is used. Such an update can be triggered by the expiration of a timer, for example as described below.

Dist Costs Recv timer expires.
When this timer expires (step 610 in FIG. 6), the DCC determines the cost of each session (the cost of each session on the access link has been calculated by a mechanism such as the STC so far) between the customers who have joined each session (Step 615). For example, the cost is distributed (or updated) by the following steps.

  (A) Allocate an estimated cost for sessions on the access link between channels within a session based on the ratio between the rate of each channel and the total rate of the session. The rate of each channel, and thus the session, is estimated locally based on the instrument (unless provided by BRC).

  (B) For each channel. The DCC distributes the cost of each channel evenly among the customers using each channel.

(C) For each customer. The DCC adds the cost per channel estimated in step b, after which this estimated total cost is An Adj message is sent to the customer's terminal (for example, a mechanism such as BRC).

  With the mechanism described above, the cost of the session from the source to the access point is distributed among all end users operating the session on the user's terminal.

Claims (40)

A method of probing a network to obtain information about the unit cost of a new session in a multicast network,
Probe query containing information about the new session from a downstream device to an upstream device located in the source direction within the session to obtain the unit cost as a cost per unit bandwidth of the session Sending a message;
Estimating the unit cost of the new session when the upstream device receives the probe query message and the upstream device is already receiving traffic for the session;
Returning a probe answer message to the probe query message source to return information about the initial unit cost of the session to the probe query message source. Storing information regarding the channel of a new session in addition to information regarding the address of the downstream device, if the upstream device has not yet received traffic regarding the session;
The method of claim 1, further comprising: further forwarding the probe query message in the direction of the source of the session to be delivered.   Estimating the unit cost based on a total cost for the total available bandwidth in the upstream device and a unit rate as a percentage of the total available bandwidth, wherein the unit cost is a unit The method according to claim 1 or 2, further comprising the step of: transmission cost per bandwidth. Returning the probe answer message in the downstream direction;
The unit cost in the probe answer message is updated in each downstream device that is on its way to the destination of the new session.
The method as described in any one of Claims 1-3. The step of updating the unit cost includes:
The method of claim 4, comprising adding a local unit upstream cost received via the probe answer message and a local unit downstream cost to obtain a total unit downstream cost.   Checking whether the upstream device has already received traffic for the session, estimating the unit cost, and generating the probe answer message are only performed by network devices located at the edge in a network. The method according to any one of claims 1 to 5, wherein   The method according to claim 1, wherein an intermediate network device not located at an edge in a network is configured to transparently forward the probe query message and the probe answer message. .   The probe query message, the probe answer message, and unit cost information are carried by one or more free fields of an existing network protocol that are different from the fields reserved for payload transmission. Item 8. The method according to any one of Items 1 to 7. Receiving from a certain upstream device a probe answer message containing information about the unit cost of the session;
Updating a unit cost related to a session carried by the probe answer message at a device that has received the probe answer message;
The method according to claim 1, further comprising the step of transferring the probe answer message to a destination of the session.   In each upstream device that receives the probe query message, to store information about the new session, its destination and its channel, and information about the downstream device that is the source of the probe query message, The method according to claim 1, further comprising the step of updating session information. While an upstream device has not received traffic for the new session identified by a probe query message and receives the probe query message, setting a timer;
11. When the timer expires for the new session, the method further comprises: erasing stored information for the session if the rate for the session is still zero. The method described in 1.   The method according to any one of claims 1 to 11, wherein information identifying a session and information relating to a cost of the session are stored only in an edge device in the network.   The method according to any one of claims 1 to 12, wherein only an edge device among devices in a network generates the probe query message and the probe answer message. A receiver-based method for controlling a received data rate for a session including a plurality of channels delivered to a receiver via a multicast network, comprising:
Determining the number of channels allowed by the budget based on the unit cost, the rate for each channel, and the budget for transmission costs;
Executing an acceptable number of channels for a session based on budget considerations.   The method according to claim 14, wherein the unit cost is determined by the method according to claim 1.   16. A method according to claim 14 or 15, wherein an acceptable channel is determined based on the budget and the priority of individual channels. In response to a start signal for initiating a session at the destination, generating a probe query message to query for the unit cost of the session and forwarding the probe query message toward the source of the session;
Receiving a probe answer message from an upstream device located in the direction of the source of the session and having information on the unit cost;
17. The method further comprises: starting from the channel with the highest priority based on the received information and subscribing to an acceptable number of channels according to the budget determined for the session. The method according to one item. Repeatedly receiving a cost adjustment message containing updated information regarding the cost of the session at the destination of the session;
If the updated cost is lower than the budget for the session, subscribing to additional channels to the extent acceptable by the budget;
18. If the updated cost is higher than the budget, further comprising deregistering the channel from the session starting from the channel with the lowest priority and filling the budget. The method according to item. The network is capable of handling different classes of service, sessions belonging to a class and classes with all assigned values and corresponding full bandwidth;
For a session, the unit cost is estimated according to the class to which the session belongs.
The method according to any one of claims 1 to 18. An apparatus for probing the network to obtain information about the unit cost of a new session in a multicast network,
Probe query message containing information about the new session from the downstream device to the upstream device located in the direction of the source in the session to obtain the unit cost as the cost per unit bandwidth of the session A transmission unit for transmitting
A receiving unit that approximates a unit cost of the new session when the upstream device receives the probe query message and the upstream device is already receiving traffic for the session;
An apparatus comprising: a response unit that returns a probe answer message to the source of the probe query message in order to return information on the initial unit cost of the session to the source of the probe query message.   If the upstream device has not yet received traffic for the session, it stores information about the channel of the new session in addition to information about the address of the downstream device, and sends the probe query message to the 21. The apparatus of claim 20, further comprising a storage unit that further transfers in a source direction.   An approximate unit that approximates the unit cost based on a total cost for total bandwidth available in the upstream device and a unit rate as a percentage of the total available bandwidth, wherein the unit cost is The apparatus according to claim 20 or 21, further comprising a rough estimation unit, which is a transmission cost per unit bandwidth. A return unit for returning the probe answer message in the downstream direction;
The update unit that updates the unit cost in each downstream device through which the probe answer message passes on the way to the destination of the new session. apparatus.   24. The apparatus of claim 23, wherein the update unit adds a local unit upstream cost received via a probe answer message and a local unit downstream cost to obtain a total unit downstream cost. .   The check of whether the upstream device has already received traffic for the session, the unit cost estimate, and the generation of the probe answer message are performed only by a network device located at an edge in a network. 25. The device according to any one of claims 20 to 24, wherein:   The apparatus according to any one of claims 20 to 25, wherein an intermediate network device not located at an edge in a network is configured to transparently forward the probe query message and the probe answer message. .   The probe query message, the probe answer message and the information on the unit cost are carried by one or more empty fields of an existing network protocol different from the field reserved for payload transmission. 27. Apparatus according to any one of claims 20 to 26. A receiving unit that receives from the upstream device a probe answer message containing information about the unit cost of the session;
In the device that has received the probe answer message, an update unit that updates a unit cost of the session carried by the probe answer message;
The apparatus according to any one of claims 20 to 27, further comprising: a transfer unit configured to transfer the probe answer message toward a destination of the session.   In each upstream device that has received the probe query message, to store information about the new session, its destination and its channel, and information about the downstream device that is the source of the probe query message, 29. Apparatus according to any one of claims 20 to 28, further comprising a unit for updating session information. A timer is set when an upstream device receives the probe query message while not receiving traffic for the new session identified by a probe query message;
30. The timing unit according to any one of claims 20 to 29, further comprising a timing unit that erases information stored for the session if the timer for the new session expires and the rate for the session is still zero. The apparatus according to one item.   The apparatus according to any one of claims 20 to 30, wherein information for specifying a session and information on a cost of a session are stored only in an edge device in the network.   32. The apparatus according to any one of claims 20 to 31, wherein only the edge device of devices in a network generates the probe query message and the probe answer message. An apparatus for controlling a reception data rate of a session including a plurality of channels distributed to a receiver via a multicast network on a receiver basis,
Determine the number of channels allowed by the budget based on the unit cost, the rate for each channel, and the budget for the transmission cost, and run an acceptable number of channels for the session based on budget considerations A device comprising a decision unit.   The apparatus according to claim 33, wherein the unit cost is determined by the apparatus according to any one of claims 20 to 32.   35. An apparatus according to claim 33 or 34, wherein an acceptable channel is determined based on the budget and the priority of individual channels. A generating unit that generates a probe query message to query for the unit cost of the session and forwards the probe query message to the source of the session in response to a start signal to start a session at the destination;
A receiving unit that is located in the direction of the source of the session and receives a probe answer message from an upstream device having information on unit cost;
36. A subscription unit starting from the channel with the highest priority based on the received information and further subscribing to an acceptable number of channels according to the budget determined for the session. The device according to any one of the above. A receiving unit that repeatedly receives a cost adjustment message including updated information regarding the cost of the session at the destination of the session;
A subscription unit that subscribes to additional channels allowed by the budget if the updated cost is lower than the budget for the session;
37. A subscription cancellation unit that, when the updated cost is higher than the budget, starts from the channel with the lowest priority and until the budget is satisfied, the subscription cancellation unit from the session. The apparatus as described in any one of. The network is capable of handling different classes of services, sessions belonging to a class, and classes assigned all values and corresponding total bandwidth,
The unit cost is estimated for a session depending on the class to which the session belongs.
The apparatus according to any one of claims 33 to 37.   A computer program comprising computer-executable code enabling a method according to any one of claims 1 to 19 to be executed on a computer.   40. A data carrier that stores or embodies the computer program of claim 39.

Images