Data transmission using a multihoming protocol as SCTP

Abstract

Method of transmission of data between a server and a client, said transmission using a multihoming protocol, as SCTP, over a network comprising at least one principal link and one secondary link connecting the server and the client, said method comprising the steps of: a) set-up of a connection between the server and the client; b) allocation of a bandwidth over the principal link to the transmission of data from the server to the client; c) transmission of data from the server to the client over the principal link as long as said allocated bandwidth is not fully used; and d) if the allocated bandwidth has been fully used, transmission of data from the server to the client over the secondary link.

Claims

1. A method of transmission of data to a client using a multihoming transport protocol, said method comprising: establishing a transport layer session with the client by transmitting, to the client, characteristics of a plurality of links with the client, the plurality of links comprising a unidirectional link broadcasting at least one transport stream and a bi-directional link, said characteristics comprising at least one of a flag indicating a nature of each link, said nature being chosen amongst bidirectional, send-only and receive-only; allocating bandwidth over the unidirectional link used to transmit data to the client; transmitting data to the client over the unidirectional link as long as said allocated bandwidth is not fully used; and if the allocated bandwidth has been fully used, transmitting remaining data to the client over the bi-directional link.

2. The method of claim 1, wherein the multihoming transport protocol is a Stream Control Transmission Protocol, SCTP, or an extension of SCTP.

3. The method of claim 1, wherein the characteristics are incorporated in a control message.

4. The method of claim 1, wherein said characteristics comprise, for each link, a delay for the transmission of data through the link.

5. The method of claim 4, wherein the flag is encoded over 4 bits, the bandwidth is encoded over 28 bits and the delay is encoded over 16 bits.

6. The method of claim 1, wherein the allocating of the bandwidth is carried out before establishing the session.

7. The method of claim 1, wherein the allocating of the bandwidth is carried out after establishing the session.

8. The method of claim 1, wherein the data comprises delay sensitive packets and non-delay sensitive packets, the delay sensitive packets are transmitted first and the non-delay sensitive packets are then transmitted over a remaining bandwidth in the unidirectional link and/or the bi-directional link.

9. An apparatus to transmit data to a client using a multihoming transport protocol, said apparatus comprising: a memory; at least one processor configured to: transmit, to the client, characteristics of a plurality of links with the client so as to establish a transport layer session with the client, the plurality of links comprising a unidirectional link broadcasting at least one transport stream and a bi-directional link, said characteristics comprising, for each link, at least one of a flag indicating a nature of each link, said nature being chosen amongst bidirectional, send-only and receive-only; allocate a bandwidth over the unidirectional link used to transmit data to the client; transmit data to the client over the unidirectional link as long as said allocated bandwidth is not fully used; and transmit remaining data to the client over the bi-directional link, if the allocated bandwidth has been fully used.

10. The apparatus of claim 9, wherein the multihoming transport protocol is a Stream Control Transmission Protocol, SCTP, or an extension of SCTP.

11. The apparatus of claim 9, wherein the characteristics are incorporated in a control message.

12. The apparatus of claim 9, wherein said characteristics comprise, for each interface, a delay for transmitting data through the interface.

13. The apparatus of claim 12, wherein the flag is encoded over 4 bits, the bandwidth is encoded over 28 bits and the delay is encoded over 16 bits.

14. The apparatus of claim 9, wherein the at least one processor is further configured to allocate the bandwidth before establishing the session.

15. The apparatus of claim 9, wherein the at least one processor is further configured to allocate the bandwidth after establishing the session.

16. The apparatus of claim 9, wherein the data comprises delay sensitive packets and non-delay sensitive packets, the delay sensitive packets are transmitted first and the non-delay sensitive packets are then transmitted over a remaining bandwidth in the unidirectional link and/or the bi-directional link.

17. An apparatus to receive data from a server using a multihoming transport protocol , said apparatus comprising: a memory; and at least one processor configured to: transmit, to said server, characteristics of a plurality of links with the server so as to establish a transport layer session with the server, the plurality of links comprising a receive only link and a bi-directional link, said characteristics comprising, for each link at least a flag indicating a nature of each link with the server, the nature being chosen amongst bidirectional and receive only; receive data from the server over the receive only link as long as a bandwidth is not fully used, said bandwidth being allocated by said server; and receive remaining data from the server over the bi-directional link if the allocated bandwidth has been fully used.

18. A non-transitory computer-readable medium with instructions stored therein which, when executed, instruct at least one processor to: transmit, to a client, characteristics of a plurality of links with the client to establish a transport layer session with the client, the plurality of links comprising a unidirectional link broadcasting at least one transport stream and a bi-directional link, said characteristics comprising, for each link, at least one of a flag indicating a nature of the link, said nature being chosen amongst bidirectional, send-only and receive-only; allocate a bandwidth over the unidirectional link used to transmit data to the client; transmit data to the client over the unidirectional link as long as said allocated bandwidth is not fully used; and transmit data to the client over the bi-directional link, if the allocated bandwidth has been fully used.

19. A method to receive data from a server, said method comprising: transmitting, to said server, characteristics of a plurality of links with the server so as to establish a transport layer session with the server, the plurality of links comprising a receive only link and a bi-directional link, said characteristics comprising, for each link at least a flag indicating a nature of each link with the server, the nature being chosen amongst bidirectional and receive only; receiving data from the server over the receive only link as long as a bandwidth is not fully used, said bandwidth being allocated by said server; and receiving remaining data from the server over the bi-directional link if the allocated bandwidth has been fully used.

20. A non-transitory computer readable medium with instructions stored therein which, when executed, instruct at least one processor to: transmit to a server characteristics of a plurality of links with the server so as to establish a transport layer session with the server, the plurality of links comprising a receive only link and a bi-directional link, said characteristics comprising, for each link at least a flag indicating a nature of each link with the server, the nature being chosen amongst bidirectional and receive only; receive data from the server over the receive only link as long as a bandwidth is not fully used, said bandwidth being allocated by said server; and receive remaining data from the server over the bi-directional link if the allocated bandwidth has been fully used.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The present invention is illustrated by way of examples, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

(2) FIG. 1, already described, is a schematic view of a broadcast network topology according to the prior art;

(3) FIG. 2 is a schematic view of an embodiment of a network architecture between a server and a client according to an embodiment of the present invention;

(4) FIG. 3 is a first example of a part of a SCTP control message according to the prior art;

(5) FIG. 4 is a second example of a part of a SCTP control message according to the prior art;

(6) FIG. 5 represents a modification of the first example of FIG. 3 according to an embodiment of the present invention;

(7) FIG. 6 represents a modification of the second example of FIG. 4 according to an embodiment of the present invention; and

(8) FIG. 7 is a flowchart illustrating the steps of an embodiment of the method of transmission of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

(9) Referring to FIG. 2, there is shown therein a schematic view of a network architecture between a server 20 and a client 22 according to a preferred embodiment of the invention.

(10) The considered network architecture is a hybrid architecture comprising a unidirectional link 24, which is here a broadcast link from the server 20 to the client 22, and a bidirectional link 26, which is here a broadband link.

(11) The server 20 comprises a content server 28 and a transport stream manager 30.

(12) Preferably, the content server 28 and the transport stream manager 30 are two separate equipments connected by a bidirectional management link 32.

(13) As well-known in the art, the broadcast link 24 is made up of several transport streams, each of them being delivered at a different frequency. A transport stream delivers several services. It encapsulates packetized data streams. Each piece of data in a transport stream is identified by a 13-bit packet identifier, named PID.

(14) The transport stream manager 30 is the equipment in charge of managing the organization and the generation of the various transport streams composing the unidirectional link 24.

(15) Preferably, the transport stream manager 30 is an IP Encapsulator.

(16) The client 22 is, for example, a home gateway located in a home network of a user.

(17) Besides, the server 20 comprises a link management module 34 able to set-up an SCTP association with the client 22 and able to leverage the unidirectional link 24.

(18) In order to allow the use of SCTP sessions with a path over the unidirectional link 24, the present invention proposes to modify existing SCTP control messages. The proposed modifications are described in the following with reference to FIGS. 3 to 6.

(19) In SCTP, when an association is setup between two endpoints as the server 20 and the client 22, the initiator of the session, for example the client 22 here, sends a list of addresses that it wishes to use for the association as part of a control message, known as a control chunk, called the INIT chunk. Then, any subsequent adding of an interface is made using a chunk, named ASCONF chunk which uses the same format to represent addresses.

(20) The peer, for example the server 20 here, receiving this indication responds with its own local addresses it wishes to be used for the association. The addresses are exchanged as a Type Length Value (TLV) data structure presented in RFC 4960 and shown on FIG. 3 for IPv4 and on FIG. 4 for IPv6. Thus, this data structure of the address comprises three fields: a type field 40, a length field 42 and a value field 44.

(21) As already known in the art, the type field 40 is an alphanumeric code indicating the kind of field that this part of the control message represents. For the IPv4 case, this code is equal to 5 whereas for the IPv6 case, it is equal to 6.

(22) The length field 42 indicates the size of the value field. For the IPv4 case, this size is equal to 8 whereas for the IPv6 case, it is equal to 20.

(23) The value field 44 contains the address of the sending endpoint. It is an unsigned integer binary encoded over 32 bits for the IPv4 case and over 128 bits for the IPv6 case.

(24) As shown on FIGS. 5 and 6, according to an embodiment of the present invention, three fields are added: a flag field 46, a bandwidth field 48 and a delay field 50.

(25) The flag field 46 indicates the nature of the interface between the considered endpoint and the considered link for the SCTP session. Advantageously, it is an unsigned integer encoded over 4 bits. As an example, the flag field 46 may take the following values: “0000” indicating that the interface is bidirectional; “1000” indicating that the interface is send-only, i.e. it cannot receive; “0100” indicating that the interface is receive-only, i.e. it cannot send.

(26) Other values of the flag field are advantageously reserved for a future use.

(27) The bandwidth field 48 contains a value of a guaranteed sustainable bandwidth over the interface. It is expressed, for instance, in kilobits per second. Advantageously, it is an unsigned integer encoded over 28 bits. A zero value of this field may preferably mean that the interface has no guaranteed bandwidth.

(28) The delay field 50 contains a delay for bits sent through the interface. It is expressed, for instance, in milliseconds. Advantageously, it is an unsigned integer encoded over 16 bits. A zero value of this field may preferably mean that the delay of the interface is unknown.

(29) As expected, due to the addition of the fields 46, 48, 50, the length field 42 is modified accordingly. Thus, in the case of IPv4, it takes the value 14 and in the case of IPv6, it takes the value 26.

(30) The flowchart of FIG. 7 details the steps of the method of the invention for transmitting data, in the form of an IP traffic, according to a preferred embodiment.

(31) At step 60, an SCTP association is set-up between the server 20 and the client 22. For this, the client 22 initiates the SCTP association with the server 20 by signaling the availability of its receive-only interface. The server 20, using its link management module 34, responds by indicating the IP address of its send-only interface, capable of transmitting, for example 3 Mbps, but unable to receive any uplink traffic from the client 22. Thus, both endpoints, i.e. the server 20 and the client 22, know the capabilities of their peer's addresses and associated unidirectional interfaces.

(32) At step 62, the transport stream manager allocates a bandwidth over the unidirectional link 24 to the transmission of data from the server 20 to the client 22. Three variants may be implemented for this allocation.

(33) According to a first variant, the step 62 is carried before the step 60. Indeed, in this case, the content server 28 is configured once for all in a static way and knows the IP address bound to the unidirectional link 24. The content server 28 transmits this information to the transport stream manager 30. This last allocates a given bandwidth for the client 22 and updates its signaling according to this allocation by associating a PID identifier and the IP address in a dedicated table. Thus, in this variant, the bandwidth is reserved even if not used. Then, the transport stream manager 30 informs the content server 28 about the allocated bandwidth for the client 22.

(34) When the client 22 initiates the SCTP session at step 60, all resources on the unidirectional link 24 have been already reserved. The client 22 knows the transport streams parameters, e.g. the PID and the frequency, to retrieve thanks to the information provided in the signaling present in the transport stream signaling and transmitted from the transport stream manager 30 through the unidirectional link 24.

(35) According to a second variant, the step 62 is carried after the step 60. In this case, no resource is allocated for the client 22 in advance on the unidirectional link 24. When the client 22 initiates a SCTP session at step 60, the content server 28 contacts the transport stream manager 30 and requests for a given bandwidth. The transport stream manager 30 allocates a bandwidth that may differ from the requested one, i.e. which may be narrower than the requested bandwidth if there is not enough available bandwidth, and then informs the content server 28 about the allocated bandwidth.

(36) The transport stream manager 30 also updates the broadcast signaling to allow the client 22 to retrieve the PID containing the IP traffic.

(37) The third variant is quite similar to the second variant except that the information about the transport stream parameters is not transmitted through a broadcast signaling but in a packet transmitted over the broadband link 26 by the content server 28. In this case, the transport stream manager 30 does not need to update the signaling since the signaling information concerning unicast IP traffic is delivered over the broadband link 26.

(38) The content server 28 forwards the transport stream parameters to the client 22 to allow it to retrieve the PID containing the IP traffic. These parameters are attached to an ASCONF message, as defined in RFC 5061, as an opaque binary parameter. The SCTP protocol stack of the client 22 must then pass these parameters to a non represented adapter connected to the unidirectional link 24. Once the adapter is properly configured and able to receive the data via the unidirectional link 24, the client 22 acknowledges the reception of the parameters with an ASCONF ACK message.

(39) In the three variants above, the allocated bandwidth may advantageously be dynamic. In this case, each time the bandwidth changes, the transport stream manager 30 informs the link management module 34 about the change, particularly by using ASCONF messages. For instance, an ASCONF-DELETE_JP_ADDRESS chunk followed by an ASCONF-ADD_IP_ADDRESS containing the new bandwidth may be transmitted.

(40) At step 64, data in the form of IP packets is transmitted from the server 20 to the client 22 according to the following description.

(41) This transmission comprises the implementation of a scheduling algorithm for scheduling the packets to be sent from the server 20 to the client 22 over the unidirectional link 24 and the bidirectional link 26.

(42) For this, a preferred embodiment of the invention modifies existing multipath scheduling algorithms specifically in the context of the Westwood SCTP protocol, generally noted W-SCTP.

(43) The first scheduling algorithm considered here is similar to a weighted round-robin scheme and is thus appropriate for large data transfers, whereas the second scheduling algorithm aims at minimizing the transmission delay and is appropriate for delay-sensitive traffic.

(44) In any case, an estimate R.sub.i for the reception time over a link i is computed for each data packet and the link having the lowest estimate R.sub.i is used to transmit said packet.

(45) In W-SCTP, the scheduler algorithm uses the formula (1):
R.sub.i=(O.sub.i+D)/B  (1)
in which: R.sub.i is the estimated reception time for the link i; O.sub.i is a current amount of outstanding, i.e. unacknowledged, data on the link i; D is an amount of data to be sent; B.sub.i is a current estimate of the link's capacity.

(46) This algorithm basically gives priority to the less busy link while attempting to balance the load, i.e. more data will be sent over the link having the greatest bandwidth as long as the amount of unacknowledged data remains small.

(47) In one embodiment of the present invention, this algorithm is modified so as to fill the capacity of the unidirectional link 24 first and then distribute the remainder of the traffic on the bidirectional link 26.

(48) Firstly, unidirectional links, here the link 24, are identified. By using the invention, this identification is easy as such unidirectional links have a send-only address connected to a receive-only address.

(49) Besides, the characteristics, namely the bandwidth and the delay, of the identified links are known as they were exchanged when the association is setup at step 60. The link management module 34 then associates a send queue with each identified link. This send queue has a maximum length S.sub.max that is implementation dependant. The current length of the send queue for a link i is noted S.sub.i.

(50) Each time there is a new packet of size D to send at step 66, the link management module 34 evaluates, at step 68, the possibility of adding the packet to the send queue for the unidirectional link 24. If there is sufficient space for the packet in the unidirectional link queue, the packet is enqueued to be sent over the unidirectional link 24, at step 70. If the unidirectional link is saturated, the packet is sent over the bidirectional link 26, at step 72.

(51) More particularly, at step 68, the following inequality (2) is evaluated:
S.sub.max≧S.sub.i+D  (2).
If this inequality holds, the packet is sent over the unidirectional link 24.

(52) For packets to be sent on the bidirectional link 26, in the case where there are more than one bidirectional link, the general Westwood SCTP scheduling algorithm can be used.

(53) For delay sensitive traffic, the scheduling needs to be done globally without separating the bidirectional link 26 and the unidirectional link 24.

(54) In a typical implementation such as Westwood SCTP with Partial Reliability, generally noted W-SCTP-PR, the scheduler algorithm uses the following formula (3):
R.sub.i=MinRTT.sub.i/2+(O.sub.i+S.sub.i+D)/B.sub.i  (3)
in which: R.sub.i is an estimated reception time for a link i; MinRTT.sub.i is the smallest round trip time seen on link i; O.sub.i is a current amount of outstanding, i.e. unacknowledged, data on the link i; S.sub.i is a current amount of buffered, i.e. not yet sent, data on the link i; D is an amount of data to be sent; B.sub.i is a current estimate of the link's capacity.

(55) This algorithm estimates the arrival time of each packet to be sent, i.e. taking into account the delay. Links that have low capacity, a long round trip time or large amounts of data already in their buffers will yield a later arrival time.

(56) The main drawback of most prior art techniques, such as the above W-SCTP-PR scheduling algorithm, is that they generally rely upon an uplink to accurately estimate the value of B.sub.i and min RTT.sub.i.

(57) In the present invention, these values, namely the bandwidth and the delay, are determined by an external means and communicated, at step 60, in the above control messages.

(58) Thus, here, the above scheduling formula for W-SCTP-PR can be rewritten according to the following formula (4), for the unidirectional link 24:
R.sub.i=delay.sub.i+(O.sub.i+S.sub.i+D)/G.sub.i  (4)
in which: delay.sub.i is the delay indicated for the link i in the control message; and G.sub.i is the guaranteed bit rate over the link i indicated in the control message.

(59) By comparing the scheduling values computed for the bidirectional link 26 and the unidirectional link 24, the SCTP transport stream manager 30 can efficiently dispatch the packets on both links while retaining the minimal delay property.

(60) More particularly, for each packet, the value of R.sub.i is computed according to the formula (3) for each bidirectional link and according to the formula (4) for each unidirectional link. Then, all the values R.sub.i for all the links are compared in order to choose the smallest R.sub.i. The packet will then be dispatched over the link i corresponding to this smallest R.sub.i.

(61) Finally, in the cases of the second and third variants of the bandwidth allocation, the content server 28 knows when the client 22 stops the SCTP session. Then, the content server 28 informs the transport stream manager 30 that frees the allocated bandwidth and updates the signaling.

(62) While there has been illustrated and described what are presently considered to be the preferred embodiments of the present invention, it will be understood by those skilled in the art that various other modifications may be made, and equivalents may be substituted, without departing from the true scope of the present invention. Additionally, many modifications may be made to adapt a particular situation to the teachings of the present invention without departing from the central inventive concept described herein. Furthermore, an embodiment of the present invention may not include all of the features described above. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the invention includes all embodiments falling within the scope of the appended claims.

(63) Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa.

(64) A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed and/or claimed may be combined without departing from the scope of the invention.

(65) Thus, even if the above description focused on one unidirectional and one bidirectional link, it can be advantageously applied to a hybrid network comprising a plurality of such links.

(66) Besides, the described scheduling algorithms are only illustrations of the possibilities offered to the SCTP transport protocol once it has knowledge of the characteristics of the unidirectional links, according to the preferred embodiment of the present invention.