WO2001041340A1 - Method and apparatus for transmission of source-routed data - Google Patents

Method and apparatus for transmission of source-routed data Download PDF

Info

Publication number
WO2001041340A1
WO2001041340A1 PCT/US2000/032557 US0032557W WO0141340A1 WO 2001041340 A1 WO2001041340 A1 WO 2001041340A1 US 0032557 W US0032557 W US 0032557W WO 0141340 A1 WO0141340 A1 WO 0141340A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
packet
port
switch
hamming
Prior art date
Application number
PCT/US2000/032557
Other languages
French (fr)
Other versions
WO2001041340A9 (en
Inventor
Julian Brown
Ricky Rand
Paul Clark
Original Assignee
Future Tv Technologies, Ltd.
Rzucidlo, Eugene, C.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Future Tv Technologies, Ltd., Rzucidlo, Eugene, C. filed Critical Future Tv Technologies, Ltd.
Priority to AU19345/01A priority Critical patent/AU1934501A/en
Publication of WO2001041340A1 publication Critical patent/WO2001041340A1/en
Publication of WO2001041340A9 publication Critical patent/WO2001041340A9/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing

Definitions

  • This invention is directed to a network protocol for a data stream over a network, in particular a method and apparatus by which a data stream containing a destination address is modified dynamically to include its return address .
  • a packet switched network comprises a group of interconnected clusters .
  • Each cluster includes at least one switch, one or more data servers, one or more user set-top-boxes (STBs), and a manager.
  • Each switch has ports by which it is connected to the various data servers and STBs, and to other cluster switches.
  • the manager in such a network can determine the addresses of each user STB, of each cluster switch to which it is connected, and what data files are stored in each of its servers.
  • a cluster's manager will typically not know, however, what users are connected to other cluster switches, or what data files are stored on servers connected to other clusters.
  • One exemplary application of such a network is to support a media-on-demand service, in which case the data servers could be media servers .
  • the switches communicate by exchanging data packets.
  • packets are comprised of two parts: a header containing routing and other control data, followed by the payload, which contains the message being transmitted.
  • the STB desires a data item, such as, for example, a movie
  • the STB places a request to the cluster manager, which then must determine which server in the network has the requested data. If the requested data item is not present on any server within the requesting user's cluster, the manager can send messages to other cluster managers requesting the data item. If more than one server has the requested data, the requester's cluster manager should determine which such server is closest to the requesting user. Once a server has been selected, that server needs to be informed as to where the data item should be sent.
  • the cluster manager will know the address of the STB that placed the request. If the server is on another cluster, however, that cluster' s manager will not know the full return address of the requesting STB. The server's cluster manager will know, at most the address of the first switch to which the data item should be sent. Thus, there is a need for a protocol for communicating addresses across a network.
  • the transmission protocol of the present invention utilizes a packet having a header comprising a Hamming encoded destination address followed by two invalid Hamming codes.
  • a packet sent from a first device to a second device passes through one or more switches.
  • the destination address is a sequence of port addresses in each of the succession of switches through which the packet will be transmitted.
  • each switch strips from the destination address the port address of the port through which the packet will be transmitted, and inserts after the first invalid Hamming code and before the second invalid Hamming code the address of the port from which the packet was received. If the transmission port address stripped from the destination address is a Hamming violation, an error has occurred and the transmission is terminated. Otherwise, the switch transmits the packet according to the transmission port address .
  • FIG. 1 is a block diagram of a cluster in one preferred embodiment of the invention.
  • FIG. 2 is a block diagram of a network of clusters in one preferred embodiment of the invention.
  • FIG. 3a illustrates a schematic diagram of a typical data packet.
  • FIG. 3b illustrates a packet header according to one embodiment of the present invention.
  • FIG. 3c illustrates packets addressing a switch manager according to the protocol of the present invention .
  • FIG. 3d illustrates the header of a packet sent from a STB to a server according to the protocol of the present invention.
  • FIG. 3e illustrates the header of a packet sent from the server back to the STB according to the protocol of the present invention.
  • FIG. 4 is a flow chart of the process of the present invention .
  • FIG. 1 An illustrative block diagram of a cluster 100 connected in a network implementing a preferred embodiment of the invention is shown in FIG. 1. For the purposes of clarity, only one switch is depicted in FIG. 1, although a cluster can include more than one switch, and the protocol of the present invention is in no way limited to clusters including only one switch.
  • each switch 110 has 16 ports.
  • Four ports 130 are allocated to data servers 135. For illustrative purposes, these servers will be assumed to be video servers.
  • Another four ports 115 are allocated to connect to user STBs 125 via a multiplexer 120, one port 145 is allocated to the manager 140, four ports 150 connect the cluster to the switches of other clusters, and the remaining ports are unused.
  • These port assignments are illustrative, and other combinations of port assignments will be readily apparent to those skilled in the art.
  • the switch illustrated has 16 ports, in other embodiments the switches could have more ports or fewer ports.
  • port address zero on each switch is reserved for the manager, while the assignments of the other port addresses is arbitrary.
  • different embodiments of the invention can reserve a different port number for the switch manager, the discussion below assumes that the manager is addressed by means of port number zero on each switch. Note that the manager need not be a device external to the switch, but can be a part of the switch itself.
  • Each of the servers 135 connected to switch 110 includes a microprocessor 136 that is capable of assembling a data packet and transmitting that data packet to the switch 110.
  • each of the STBs each of the STBs
  • 125 connected to switch 110 includes a micro-controller
  • the manager 140 can also assemble and transmit a data packet, either to the switch 110 or to a manager of another switch in the network via connection 146.
  • FIG. 2 is an illustrative diagram of a network of clusters such as that depicted in FIG. 1 in which a preferred embodiment of the present invention is implemented.
  • a 2 dimensional grid network is depicted.
  • Nine cluster switches 210, 220, 230, 240, 250, 260, 270, 280, 290 are shown, although such a network need not be limited to this number of switches.
  • Each cluster switch has four ports, shown schematically within each switch by reference numbers 1, 2, 3, and 4, each such port being adapted for interconnection to one of the other cluster switches.
  • Cluster switches may be further provided with additional ports for connection to servers, STBs, and the switch manager.
  • FIG. 1 is an illustrative diagram of a network of clusters such as that depicted in FIG. 1 in which a preferred embodiment of the present invention is implemented.
  • FIG. 2 is an illustrative diagram of a network of clusters such as that depicted in FIG. 1 in which a preferred embodiment of the present invention is implemented.
  • FIG. 2 depicts a 2 dimensional grid
  • the protocol of the present invention is not limited to such networks.
  • the network can be a 3 dimensional grid.
  • Many of the possible network architectures in which the present invention can be implemented are discussed in "Decentralized Network Architecture System", provisional patent application number 60/170,382, filed December 13, 1999, by Rand, et . al . , incorporated by reference herein.
  • the protocol of the present invention is not limited to those network architectures, however, and it will be readily apparent to those skilled in the art how to the protocol of the present invention in other types of networks.
  • a cluster network such as that pictured is referred to a region.
  • one of the unused ports of a switch can be used to connect a region of clusters to another region of clusters.
  • the concept of cluster regions is discussed in "A System And Method For Large-Scale, Distributed, Personalized Media On Demand", patent application number 60/155,388, filed September 22, 1999, by Rand, et al . , incorporated by reference herein.
  • STB 211 placed a content request to the manager of switch 210.
  • the problem of finding a server with the requested content, where the server can be in different cluster or region of clusters than the requesting device, is handled by a capability advertisement protocol, discussed in "A System And Method For Large-Scale, Distributed, Personalized Media On Demand” and in the “FutureTV ASH Routing Overview" documentation filed as part of the provisional application for "Method and Apparatus for Transmission of Source Routed data".
  • the capability advertisement protocol enables clusters and regions of clusters to advertise to other clusters and regions of clusters both their addresses and routing information within the network as well as information about content and services provided by other clusters and regions of clusters.
  • a manager in the cluster of the requesting device can determine the shortest route to the requested data. To simplify the following discussion, however, it will be assumed that the nearest server with the desired data has been determined to be server 281, connected to switch 280.
  • FIGS. 3a - 3e Schematic diagrams of the data packets utilized by the present invention are shown in FIGS. 3a - 3e .
  • FIG. 3(a) illustrates the general structure of a typical packet.
  • Each packet 300 consists of a header 310 followed by a payload 320.
  • CRC cyclic redundancy check
  • Packets are usually CRC coded to protect their integrity during transmission.
  • a CRC code for a packet can be calculated prior to transmission, and this code can be represented by one or more bytes appended to the packet.
  • the destination performs the same coding calculation on the received packet and compares the result to the appended code.
  • Another method involves the use of Hamming codes. Hamming codes involve the appending of one or more bits to each byte wherein the additional bits characterize a property of the byte.
  • Hamming encoding and CRC coding is performed by the device that assembles a data packet, such as a server, an STB, or a switch manager.
  • the use of both CRC coding and Hamming codes are well known in the art and thus need not be described here.
  • the header portion of a packet in a preferred embodiment of the present invention includes a destination address followed by two invalid Hamming codes, which are referred to in the art as Hamming violations .
  • Several Hamming codes that are invalid in the system of the present invention are referred to herein as Channel Violation 1 ("CV1") , Channel Violation 2 (“CV2”), and Final Violation (“FV").
  • CV1 Channel Violation 1
  • CV2 Channel Violation 2
  • FV Final Violation
  • each byte in the header is Hamming encoded to preserve the integrity of the data.
  • each byte in the return address that is built during transmission is Hamming encoded.
  • the header is not, however, CRC coded, since it is altered dynamically while in transmission, although the payload portion of the packet is CRC coded. In addition, not performing a CRC calculation ij the switch saves both time and cost.
  • FIG. 3(b) A schematic diagram of a preferred embodiment of a packet of the present invention is shown in FIG. 3(b) .
  • the packet header 330 includes the destination address 331, followed by the first invalid Hamming code 332 and the second invalid Hamming code 333. Payload 334 follows the header 330.
  • the destination address consists of a sequence of words of at least one byte each that identify the output port in each switch through which the packet is routed en route to the destination. Identifying the output port through which a packet is transmitted is equivalent to identifying the switch to which it is sent. Similarly, the address of a first switch from which a second switch received a data packet is the port address on the second switch from which the packet was received.
  • the first invalid code can be either CV1 or CV2.
  • One code can indicate that the receiving server will set up a realtime data channel, and that the server should act on the data request right away. This would be the case in which a user STB is requesting the delivery of a particular video data item.
  • the other code can indicate that the receiving server will open a control channel, in which case the requested data will be placed in a queue to be acted upon later. This would be the case in which a manager is requesting information as to what data items are available on a server.
  • the second invalid code in a preferred embodiment is FV.
  • the lengths of a packet can vary, in a preferred embodiment, the length of each packet will be fixed. Thus, a packet with a long address will have a correspondingly shorter payload. In an especially preferred embodiment, the packets have a length of 1024, or IK bytes. In this embodiment, the length of the header and the length of the payload are multiples of four bytes. Thus, the Hamming violation FV in the header is repeated to a four byte alignment, after which it is followed by four bytes specifying the payload length. The payload is followed by a two byte CRC code, and sufficient padding bytes so that the packet is IK bytes in length.
  • the protocol of the invention strips the port addresses of the destination address during transmission while building the return address following the first Hamming violation, if the first byte in a packet header received by a destination device is not a Hamming violation, the packet is invalid and will be dropped.
  • destinations devices include servers, STBs, and cluster managers. Cluster managers differ from other destination devices in that a packet header with one or more zeros preceding the first Hamming violation constitute a valid address when received by the manager. Conversely, if the first byte in a packet header received by a switch is a Hamming violation such as CVl or CV2, the packet is invalid and further transmission will be halted.
  • FIG. 3(c) shows the header of a packet sent to a manager.
  • An address comprising at least one zero will rout the packet to the manager of a cluster.
  • port zero of a switch not connected to a manager can be connected to a switch that is connected to a manager.
  • a means for a sending device to insure that a packet reaches a manager is to include a long string of zeros in the destination address.
  • header 340 illustrates how STB 211 would address a media request message to the manager 212 of switch 210.
  • Switch 210 in routing that message, strips the leading ⁇ 0' and insert the port address of STB 211, x 5' , after the first Hamming violation.
  • Header 341 illustrates the header as received by the manager 212.
  • Header 342 illustrates how manager 212 of switch 210 addresses a message to manager 222 of switch 220.
  • the leading ⁇ 3' is the port to which switch is attached.
  • Switch 210 upon receiving the packet from manager 212 strips the leading ⁇ 3' and inserts a ⁇ 0' following the first Hamming violation.
  • Header 343 illustrates the packet header as received by switch 220.
  • the leading ⁇ 0' causes the switch 220 to rout the packet to the manager 222 after first stripping the leading ⁇ 0' and inserting a ⁇ l' , the incoming port address, after the first Hamming violation.
  • Header 344 illustrates the packet header as received by manager 222.
  • Fig. 3(d) shows a sequence of packet headers for a data request originating from STB 211 in Fig. 2 attached to port 5 of switch 210 in Fig. 2.
  • the manager 212 of switch 210 has determined that the data requested is located on server 281 attached to port 9 of switch 280 in Fig. 2. If, however, the data item can also be found on a server connected to switch 210, for example, a server (not pictured) connected to port 9, the manager can determine the shortest path from the server to the STB by comparing destination addresses.
  • One possible address of server 281 with respect to STB 211 is 3449'
  • the address of the server attached to port 9 of switch 210 is ⁇ 9' .
  • a shorter address string indicates a shorter path.
  • STB 211 there are other possible paths from STB 211 to server 281.
  • the data item is located on server 281 connected to switch 280, and that the path from STB 211 to switch 281 is 3449' .
  • Packet header 350 shows the request as it is received by switch 210.
  • Header 350 can be received from STB 211, or it can be received from the manager (not pictured) .
  • Header 350 starts with the destination address 351 followed by invalid codes 352 and 359.
  • This destination address is a sequence of port addresses on successive switches through which the packet is routed. In particular, the address consists of port 3 of switch 210, port 4 of switch 220, port 4 of switch 250, and port 9 of switch 280.
  • Packet header 360 shows the packet as it is transmitted from switch 210 to switch 220, with destination address 361 followed by Hamming codes CV1 362, return address 363, which is the port connected to the originating STB, and Hamming code FV 369. Note that address 361 had its leading byte, the address of the output port through which it is transmitted, removed.
  • Header 370 shows the packet as it is routed from switch 220 to switch 250. It consists of destination address 371, Hamming code 372, return address 373, followed by Hamming code 379. Once again, the output port in switch 370 through which the packet is transmitted is removed from destination address 371, while the address of the incoming port was added to return address 373.
  • Header 380 shows the packet as it is routed from switch 250 to switch 280, and consists of destination address 381, Hamming code 382, return address 383, followed by Hamming code 389. Note that the destination address 381 is that of server 281 on switch 280.
  • Header 390 shows the header after switch 280 has routed the packet to server 281. Now, the Hamming code
  • server 281 Upon receipt, server 281 knows from the invalid Hamming code that this is a data request, and consults the payload to determine the nature of the request. If the first byte of a header received by a destination (other than a manager) is not an invalid Hamming code, the packet is invalid. If the packet is valid, server 281 will assemble a new packet in which the payload contains the data originally requested by STB 211 and the header contains a destination address extracted from return address 393 of header 390.
  • Header 400 shown in Fig. 3(e), shows the header of the packet as received by switch 280 from server 281, prior to being returned to switch 210. It consists of the destination address 401, followed by Hamming codes 402 and 409. Note that destination address 401 is derived from return address 393 in header 390.
  • a flow chart of the protocol of a preferred embodiment of the present invention is depicted in Fig. 4.
  • a switch gets the first byte of an incoming packet. The switch checks whether the first byte is a valid Hamming code at step 430. If is not, an error has occurred and the packet is invalid.
  • the switch If the first byte is a valid Hamming code, the byte is removed from the incoming stream at step 440, and the Hamming encoding is removed to obtain the port address through which the packet should be transmitted. The validity of the port address is checked at step 450. If that port address is invalid, an error has occurred and the packet is invalid. If the port address is valid, the switch obtains the next byte at step 460, and transmits it out the specified port at step 470. The switch then checks whether the byte is the first Hamming violation, either CV1 or CV2, at step 480. If the byte just transmitted was not a first Hamming violation, the switch returns to step 460 to retrieve the next byte from the incoming stream.
  • the switch transmits, at step 490, the Hamming encoded address of the port on which the packet was received.
  • the switch will simply retrieve the incoming byte at step 500 and transmit it at step 520 until the end of the packet is reached, at step 510.
  • the protocol of the invention can be readily implemented in either software or hardware, although in a preferred embodiment, it will be implemented in hardware of the switch. In that embodiment, the switch hardware itself performs the routing and deletion/insertion operations and raises an error condition if an incoming port address is invalid. In addition, the return address need not follow the destination address, and the separators need not be invalid Hamming codes, as any code that is an invalid port address can serve the same function.
  • the header is error protected, this is not necessary to the protocol of the invention.
  • the transmission protocol of the present invention has been described in conjunction with preferred embodiments, it is evident that numerous alternative modifications, variations, and uses will be apparent to those skilled in the art in light of the foregoing disclosure.
  • the invention has been described in conjunction with a two-dimensional grid network, the invention is not limited to such networks. It will be readily apparent to the skilled artisan how to adapt the invention' s transmission protocol to other network architectures .

Abstract

A method for constructing a return address for a data request transmitted across a network such as media-on-demand system is disclosed. Each switch through which a data packet is transmitted removes its identifier (361) from a destination address (351) and adds its identifier (363) to the return address. The method has the further feature of easily identifying a shortest path (379) from a plurality of paths that connect a plurality of data sources to a data requester.

Description

METHOD AND APPARATUS FOR TRANSMISSION OF SOURCE-ROUTED
DATA
RELATED APPLICATIONS
This application claims priority under 35 U.S.C. §
119(e) from U.S. Provisional Application No. 60/168089 of
Rand, et al . filed November 30, 1999 which is herein incorporated by reference in its entirety.
FIELD OF THE INVENTION
This invention is directed to a network protocol for a data stream over a network, in particular a method and apparatus by which a data stream containing a destination address is modified dynamically to include its return address . BACKGROUND OF THE INVENTION
A packet switched network comprises a group of interconnected clusters . Each cluster includes at least one switch, one or more data servers, one or more user set-top-boxes (STBs), and a manager. Each switch has ports by which it is connected to the various data servers and STBs, and to other cluster switches. The manager in such a network can determine the addresses of each user STB, of each cluster switch to which it is connected, and what data files are stored in each of its servers. A cluster's manager will typically not know, however, what users are connected to other cluster switches, or what data files are stored on servers connected to other clusters. One exemplary application of such a network is to support a media-on-demand service, in which case the data servers could be media servers .
The switches communicate by exchanging data packets. Typically, such packets are comprised of two parts: a header containing routing and other control data, followed by the payload, which contains the message being transmitted. When a user STB desires a data item, such as, for example, a movie, the STB places a request to the cluster manager, which then must determine which server in the network has the requested data. If the requested data item is not present on any server within the requesting user's cluster, the manager can send messages to other cluster managers requesting the data item. If more than one server has the requested data, the requester's cluster manager should determine which such server is closest to the requesting user. Once a server has been selected, that server needs to be informed as to where the data item should be sent. If the requester is within the same cluster as the server, the cluster manager will know the address of the STB that placed the request. If the server is on another cluster, however, that cluster' s manager will not know the full return address of the requesting STB. The server's cluster manager will know, at most the address of the first switch to which the data item should be sent. Thus, there is a need for a protocol for communicating addresses across a network. SUMMARY OF THE INVENTION
It is an object of the present invention to provide a mechanism for communicating the address of a device or a path connecting two devices across a network. It is a further object of the invention to provide a mechanism for selecting a shortest path between two devices from a plurality of paths.
The transmission protocol of the present invention utilizes a packet having a header comprising a Hamming encoded destination address followed by two invalid Hamming codes. A packet sent from a first device to a second device passes through one or more switches. Initially, the destination address is a sequence of port addresses in each of the succession of switches through which the packet will be transmitted. As the packet passes through a switch, each switch strips from the destination address the port address of the port through which the packet will be transmitted, and inserts after the first invalid Hamming code and before the second invalid Hamming code the address of the port from which the packet was received. If the transmission port address stripped from the destination address is a Hamming violation, an error has occurred and the transmission is terminated. Otherwise, the switch transmits the packet according to the transmission port address .
Thus, by the time the data packet reaches its destination, all data identifying the switches through which the packet was routed will be stripped, while a return address following the first invalid Hamming code will have been built by each intervening switch. The first byte in the header of a packet received by a destination device such as a server should be an invalid Hamming code. If it is not, an error has occurred and the packet received is invalid. If the packet is valid, the destination device will assemble a reply packet and return it according to the path specified by the return address. Each switch has a manager. A packet with a destination address comprising one or more zeros preceding the first invalid Hamming code will address the switch manager. The zeros may be preceded by other valid, non-zero address codes. If more than one server in the network contains the requested data, the cluster manager can determine which server is closest to the user by comparing the lengths of the paths' addresses. BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a cluster in one preferred embodiment of the invention. FIG. 2 is a block diagram of a network of clusters in one preferred embodiment of the invention.
FIG. 3a illustrates a schematic diagram of a typical data packet.
FIG. 3b illustrates a packet header according to one embodiment of the present invention.
FIG. 3c illustrates packets addressing a switch manager according to the protocol of the present invention .
FIG. 3d illustrates the header of a packet sent from a STB to a server according to the protocol of the present invention.
FIG. 3e illustrates the header of a packet sent from the server back to the STB according to the protocol of the present invention.
FIG. 4 is a flow chart of the process of the present invention . DETAILED DESCRIPTION OF THE INVENTION
Since the network protocol of the present invention functions within the environment of a packet switched network, an exemplary network in which the invention is implemented and an exemplary cluster in that network will be described first. An illustrative block diagram of a cluster 100 connected in a network implementing a preferred embodiment of the invention is shown in FIG. 1. For the purposes of clarity, only one switch is depicted in FIG. 1, although a cluster can include more than one switch, and the protocol of the present invention is in no way limited to clusters including only one switch. In this example, each switch 110 has 16 ports. Four ports 130 are allocated to data servers 135. For illustrative purposes, these servers will be assumed to be video servers. Another four ports 115 are allocated to connect to user STBs 125 via a multiplexer 120, one port 145 is allocated to the manager 140, four ports 150 connect the cluster to the switches of other clusters, and the remaining ports are unused. These port assignments are illustrative, and other combinations of port assignments will be readily apparent to those skilled in the art. Although the switch illustrated has 16 ports, in other embodiments the switches could have more ports or fewer ports. In the embodiment illustrated, port address zero on each switch is reserved for the manager, while the assignments of the other port addresses is arbitrary. Although different embodiments of the invention can reserve a different port number for the switch manager, the discussion below assumes that the manager is addressed by means of port number zero on each switch. Note that the manager need not be a device external to the switch, but can be a part of the switch itself.
Each of the servers 135 connected to switch 110 includes a microprocessor 136 that is capable of assembling a data packet and transmitting that data packet to the switch 110. In addition, each of the STBs
125 connected to switch 110 includes a micro-controller
126 that also is capable of assembling a data packet and transmitting that packet to the switch. The manager 140 can also assemble and transmit a data packet, either to the switch 110 or to a manager of another switch in the network via connection 146.
FIG. 2 is an illustrative diagram of a network of clusters such as that depicted in FIG. 1 in which a preferred embodiment of the present invention is implemented. For the purposes of simplicity, a 2 dimensional grid network is depicted. Nine cluster switches 210, 220, 230, 240, 250, 260, 270, 280, 290 are shown, although such a network need not be limited to this number of switches. Each cluster switch has four ports, shown schematically within each switch by reference numbers 1, 2, 3, and 4, each such port being adapted for interconnection to one of the other cluster switches. Cluster switches may be further provided with additional ports for connection to servers, STBs, and the switch manager. FIG. 2, for example, shows STB 211 connected to cluster switch 210 at port 5, and server 281 connected to port 9 of cluster switch 280. Although FIG. 2 depicts a 2 dimensional grid, the protocol of the present invention is not limited to such networks. Alternatively, for example, the network can be a 3 dimensional grid. Many of the possible network architectures in which the present invention can be implemented are discussed in "Decentralized Network Architecture System", provisional patent application number 60/170,382, filed December 13, 1999, by Rand, et . al . , incorporated by reference herein. The protocol of the present invention is not limited to those network architectures, however, and it will be readily apparent to those skilled in the art how to the protocol of the present invention in other types of networks.
A cluster network such as that pictured is referred to a region. In another preferred embodiment of the invention, one of the unused ports of a switch can be used to connect a region of clusters to another region of clusters. The concept of cluster regions is discussed in "A System And Method For Large-Scale, Distributed, Personalized Media On Demand", patent application number 60/155,388, filed September 22, 1999, by Rand, et al . , incorporated by reference herein.
For purpose of illustrating the discussion that follows, it will be assumed that, in FIG. 2, STB 211 placed a content request to the manager of switch 210. The problem of finding a server with the requested content, where the server can be in different cluster or region of clusters than the requesting device, is handled by a capability advertisement protocol, discussed in "A System And Method For Large-Scale, Distributed, Personalized Media On Demand" and in the "FutureTV ASH Routing Overview" documentation filed as part of the provisional application for "Method and Apparatus for Transmission of Source Routed data". The capability advertisement protocol enables clusters and regions of clusters to advertise to other clusters and regions of clusters both their addresses and routing information within the network as well as information about content and services provided by other clusters and regions of clusters. By means of this protocol, a manager in the cluster of the requesting device can determine the shortest route to the requested data. To simplify the following discussion, however, it will be assumed that the nearest server with the desired data has been determined to be server 281, connected to switch 280.
Schematic diagrams of the data packets utilized by the present invention are shown in FIGS. 3a - 3e . FIG. 3(a) illustrates the general structure of a typical packet. Each packet 300 consists of a header 310 followed by a payload 320.
Because noise and interference can impair the integrity of data being transmitted, methods have been developed to protect against errors. One of these methods is referred to as a cyclic redundancy check ("CRC") code. Packets are usually CRC coded to protect their integrity during transmission. A CRC code for a packet can be calculated prior to transmission, and this code can be represented by one or more bytes appended to the packet. The destination performs the same coding calculation on the received packet and compares the result to the appended code. Another method involves the use of Hamming codes. Hamming codes involve the appending of one or more bits to each byte wherein the additional bits characterize a property of the byte. Hamming encoding and CRC coding is performed by the device that assembles a data packet, such as a server, an STB, or a switch manager. The use of both CRC coding and Hamming codes are well known in the art and thus need not be described here.
As shown in FIG. 3(b) discussed below, the header portion of a packet in a preferred embodiment of the present invention includes a destination address followed by two invalid Hamming codes, which are referred to in the art as Hamming violations . Several Hamming codes that are invalid in the system of the present invention are referred to herein as Channel Violation 1 ("CV1") , Channel Violation 2 ("CV2"), and Final Violation ("FV"). Except for the two invalid codes, each byte in the header is Hamming encoded to preserve the integrity of the data. In addition, each byte in the return address that is built during transmission is Hamming encoded. The header is not, however, CRC coded, since it is altered dynamically while in transmission, although the payload portion of the packet is CRC coded. In addition, not performing a CRC calculation ij the switch saves both time and cost.
A schematic diagram of a preferred embodiment of a packet of the present invention is shown in FIG. 3(b) . The packet header 330 includes the destination address 331, followed by the first invalid Hamming code 332 and the second invalid Hamming code 333. Payload 334 follows the header 330.
In a preferred embodiment, the destination address consists of a sequence of words of at least one byte each that identify the output port in each switch through which the packet is routed en route to the destination. Identifying the output port through which a packet is transmitted is equivalent to identifying the switch to which it is sent. Similarly, the address of a first switch from which a second switch received a data packet is the port address on the second switch from which the packet was received.
In addition, in a preferred embodiment, the first invalid code can be either CV1 or CV2. One code can indicate that the receiving server will set up a realtime data channel, and that the server should act on the data request right away. This would be the case in which a user STB is requesting the delivery of a particular video data item. The other code can indicate that the receiving server will open a control channel, in which case the requested data will be placed in a queue to be acted upon later. This would be the case in which a manager is requesting information as to what data items are available on a server. The second invalid code in a preferred embodiment is FV.
Although the lengths of a packet can vary, in a preferred embodiment, the length of each packet will be fixed. Thus, a packet with a long address will have a correspondingly shorter payload. In an especially preferred embodiment, the packets have a length of 1024, or IK bytes. In this embodiment, the length of the header and the length of the payload are multiples of four bytes. Thus, the Hamming violation FV in the header is repeated to a four byte alignment, after which it is followed by four bytes specifying the payload length. The payload is followed by a two byte CRC code, and sufficient padding bytes so that the packet is IK bytes in length.
Since the protocol of the invention strips the port addresses of the destination address during transmission while building the return address following the first Hamming violation, if the first byte in a packet header received by a destination device is not a Hamming violation, the packet is invalid and will be dropped. Examples of destinations devices include servers, STBs, and cluster managers. Cluster managers differ from other destination devices in that a packet header with one or more zeros preceding the first Hamming violation constitute a valid address when received by the manager. Conversely, if the first byte in a packet header received by a switch is a Hamming violation such as CVl or CV2, the packet is invalid and further transmission will be halted.
FIG. 3(c) shows the header of a packet sent to a manager. An address comprising at least one zero will rout the packet to the manager of a cluster. In a cluster comprising more than one switch, port zero of a switch not connected to a manager can be connected to a switch that is connected to a manager. Thus, a means for a sending device to insure that a packet reaches a manager is to include a long string of zeros in the destination address. For example, header 340 illustrates how STB 211 would address a media request message to the manager 212 of switch 210. Switch 210, in routing that message, strips the leading Λ0' and insert the port address of STB 211, x5' , after the first Hamming violation. Header 341 illustrates the header as received by the manager 212. Header 342 illustrates how manager 212 of switch 210 addresses a message to manager 222 of switch 220. The leading λ3' is the port to which switch is attached. Switch 210, upon receiving the packet from manager 212 strips the leading Λ3' and inserts a Λ0' following the first Hamming violation. Header 343 illustrates the packet header as received by switch 220. The leading Λ0' causes the switch 220 to rout the packet to the manager 222 after first stripping the leading λ0' and inserting a Λl' , the incoming port address, after the first Hamming violation. Header 344 illustrates the packet header as received by manager 222.
Fig. 3(d) shows a sequence of packet headers for a data request originating from STB 211 in Fig. 2 attached to port 5 of switch 210 in Fig. 2. In this example, the manager 212 of switch 210 has determined that the data requested is located on server 281 attached to port 9 of switch 280 in Fig. 2. If, however, the data item can also be found on a server connected to switch 210, for example, a server (not pictured) connected to port 9, the manager can determine the shortest path from the server to the STB by comparing destination addresses. One possible address of server 281 with respect to STB 211 is 3449' , while the address of the server attached to port 9 of switch 210 is Λ9' . A shorter address string indicates a shorter path. Note that there are other possible paths from STB 211 to server 281. For illustrative purposes in the discussion that follows, it will be assumed that the data item is located on server 281 connected to switch 280, and that the path from STB 211 to switch 281 is 3449' .
Packet header 350 shows the request as it is received by switch 210. Header 350 can be received from STB 211, or it can be received from the manager (not pictured) . Header 350 starts with the destination address 351 followed by invalid codes 352 and 359. This destination address is a sequence of port addresses on successive switches through which the packet is routed. In particular, the address consists of port 3 of switch 210, port 4 of switch 220, port 4 of switch 250, and port 9 of switch 280.
Packet header 360 shows the packet as it is transmitted from switch 210 to switch 220, with destination address 361 followed by Hamming codes CV1 362, return address 363, which is the port connected to the originating STB, and Hamming code FV 369. Note that address 361 had its leading byte, the address of the output port through which it is transmitted, removed. Header 370 shows the packet as it is routed from switch 220 to switch 250. It consists of destination address 371, Hamming code 372, return address 373, followed by Hamming code 379. Once again, the output port in switch 370 through which the packet is transmitted is removed from destination address 371, while the address of the incoming port was added to return address 373.
Header 380 shows the packet as it is routed from switch 250 to switch 280, and consists of destination address 381, Hamming code 382, return address 383, followed by Hamming code 389. Note that the destination address 381 is that of server 281 on switch 280.
Header 390 shows the header after switch 280 has routed the packet to server 281. Now, the Hamming code
392 is the leading byte, followed by the return address
393 and the second Hamming code 399. Upon receipt, server 281 knows from the invalid Hamming code that this is a data request, and consults the payload to determine the nature of the request. If the first byte of a header received by a destination (other than a manager) is not an invalid Hamming code, the packet is invalid. If the packet is valid, server 281 will assemble a new packet in which the payload contains the data originally requested by STB 211 and the header contains a destination address extracted from return address 393 of header 390.
Header 400, shown in Fig. 3(e), shows the header of the packet as received by switch 280 from server 281, prior to being returned to switch 210. It consists of the destination address 401, followed by Hamming codes 402 and 409. Note that destination address 401 is derived from return address 393 in header 390. A flow chart of the protocol of a preferred embodiment of the present invention is depicted in Fig. 4. At step 420, a switch gets the first byte of an incoming packet. The switch checks whether the first byte is a valid Hamming code at step 430. If is not, an error has occurred and the packet is invalid. If the first byte is a valid Hamming code, the byte is removed from the incoming stream at step 440, and the Hamming encoding is removed to obtain the port address through which the packet should be transmitted. The validity of the port address is checked at step 450. If that port address is invalid, an error has occurred and the packet is invalid. If the port address is valid, the switch obtains the next byte at step 460, and transmits it out the specified port at step 470. The switch then checks whether the byte is the first Hamming violation, either CV1 or CV2, at step 480. If the byte just transmitted was not a first Hamming violation, the switch returns to step 460 to retrieve the next byte from the incoming stream. Otherwise, the switch transmits, at step 490, the Hamming encoded address of the port on which the packet was received. Once the incoming port has been transmitted, the switch will simply retrieve the incoming byte at step 500 and transmit it at step 520 until the end of the packet is reached, at step 510. The protocol of the invention can be readily implemented in either software or hardware, although in a preferred embodiment, it will be implemented in hardware of the switch. In that embodiment, the switch hardware itself performs the routing and deletion/insertion operations and raises an error condition if an incoming port address is invalid. In addition, the return address need not follow the destination address, and the separators need not be invalid Hamming codes, as any code that is an invalid port address can serve the same function. Although in a preferred embodiment the header is error protected, this is not necessary to the protocol of the invention. While the transmission protocol of the present invention has been described in conjunction with preferred embodiments, it is evident that numerous alternative modifications, variations, and uses will be apparent to those skilled in the art in light of the foregoing disclosure. In particular, while the invention has been described in conjunction with a two-dimensional grid network, the invention is not limited to such networks. It will be readily apparent to the skilled artisan how to adapt the invention' s transmission protocol to other network architectures .
The system of the invention is not limited to the embodiments disclosed herein. It will be immediately apparent to those skilled in the art that variations and modifications to the disclosed embodiment are possible without departing from the spirit and scope of the present invention. The invention is defined by the appended claims .

Claims

CLAIMSWHAT IS CLAIMED IS:
1. A method of return routing source-routed data in a network of interconnected switches, the switches comprising a plurality of ports for network interconnection, the method comprising the steps of: assembling a data packet having a header and a payload, the header comprising a destination address that includes a sequence of port addresses in successive switches through which the packet is to be transmitted; transmitting the packet to a first switch; deleting from the destination address a transmission port address of the port in said first switch through which the packet will be transmitted; appending to a return address in the header a receiving port address of the port from which the packet was received; and routing the packet according to the destination address; wherein the steps of deleting, appending and routing are repeated for every switch through which the packet is routed, and wherein the succession of switches through which the packet is transmitted build the return address of the packet.
2. The method of claim 1, wherein the header further comprises a first invalid port address that follows the destination address and is followed by a second invalid port address, wherein the return address is inserted following the first Hamming violation and preceding the second Hamming violation.
3. The method of claim 1, wherein the destination address is Hamming encoded.
4. The method of claim 1, wherein the return address is Hamming encoded.
5. The method of claim 3, further comprising the step of raising an error if the transmission port address in a packet received by a switch is a Hamming violation.
6. The method of claim 3, further comprising the step of raising an error if the transmission port address in a packet received by a destination is not a Hamming violation.
7. The method of claim 2, wherein the first and second invalid port addresses are, respectively, a first and second Hamming violation.
8. The method of claim 1, wherein a destination address comprising at least one zero addresses a switch manager .
9. An apparatus for return routing source-routed data in a network of interconnected switches, the switches comprising a plurality of ports for network interconnection, the apparatus comprising: means for assembling a data packet having a header and a payload, the header comprising a destination address that includes a sequence of port addresses in successive switches through which the packet is to be transmitted and a place for the insertion of a return address; means for transmitting the packet to a first switch; means for deleting the address of the port through which the packet will be transmitted from the destination address; and means for inserting into the header the address of the port from which a packet was received to form the return address; whereby a switch receiving a packet appends the address of the port from which the packet was received to the return address, deletes the address of the port through which the packet will be transmitted from the destination address, and transmits the packet according to the destination address.
10. The apparatus of claim 9, wherein the header further comprises a first invalid port address and a second invalid port address, wherein the first invalid port address follows the destination address and precedes the second invalid port address, and wherein the return address is inserted between the first invalid port address and the second invalid port address.
11. The apparatus of claim 9, further comprising means for Hamming encoding the destination address.
12. The apparatus of claim 9, further comprising means for Hamming encoding the return address.
13. The apparatus of claim 11, further comprising means for raising an error if the transmission port address in a packet received by a switch is a Hamming violation.
14. The apparatus of claim 11, further comprising means for raising an error if the transmission port address in a packet received by a destination is not a Hamming violation.
15. The apparatus of claim 10, wherein the first and second invalid port addresses are, respectively, a first and second Hamming violation.
16. The apparatus of claim 9, further comprising means for addressing a switch manager with a destination address comprised of at least one zero.
17. A method for determining a shortest path from a plurality of paths in a network, wherein the network includes a plurality of interconnected switches connecting a plurality of data servers to at least one data receiver, and the plurality of paths connect the plurality of data servers containing a particular data item to the at least one data receiver, said method comprising the steps of: constructing, for each path, a destination address of each associated data server relative to the data receiver, in which each destination address consists of a sequence of ports in successive switches through which data can be transmitted; comparing the number of switches specified by each path; and selecting a path containing a least number of switch addresses .
PCT/US2000/032557 1999-11-30 2000-11-30 Method and apparatus for transmission of source-routed data WO2001041340A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU19345/01A AU1934501A (en) 1999-11-30 2000-11-30 Method and apparatus for transmission of source-routed data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16808999P 1999-11-30 1999-11-30
US60/168,089 1999-11-30

Publications (2)

Publication Number Publication Date
WO2001041340A1 true WO2001041340A1 (en) 2001-06-07
WO2001041340A9 WO2001041340A9 (en) 2002-05-23

Family

ID=22610077

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/032557 WO2001041340A1 (en) 1999-11-30 2000-11-30 Method and apparatus for transmission of source-routed data

Country Status (2)

Country Link
AU (1) AU1934501A (en)
WO (1) WO2001041340A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2852176A1 (en) * 2003-03-04 2004-09-10 Alterlane Data processing stations interconnecting system, has station groups interconnecting device with repeater unit receiving blocks from transmitting station and re-transmitting blocks towards destination station
EP2365667A1 (en) * 2003-02-03 2011-09-14 Nippon Telegraph And Telephone Corporation Data transfer apparatus and data transfer system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4742511A (en) * 1985-06-13 1988-05-03 Texas Instruments Incorporated Method and apparatus for routing packets in a multinode computer interconnect network
US4811361A (en) * 1986-10-30 1989-03-07 Bull, S.A. Method and apparatus for transmission of digital data
US5105424A (en) * 1988-06-02 1992-04-14 California Institute Of Technology Inter-computer message routing system with each computer having separate routinng automata for each dimension of the network
US5928332A (en) * 1996-12-06 1999-07-27 Intel Corporation Communication network with reversible source routing that includes reduced header information being calculated in accordance with an equation

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4742511A (en) * 1985-06-13 1988-05-03 Texas Instruments Incorporated Method and apparatus for routing packets in a multinode computer interconnect network
US4811361A (en) * 1986-10-30 1989-03-07 Bull, S.A. Method and apparatus for transmission of digital data
US5105424A (en) * 1988-06-02 1992-04-14 California Institute Of Technology Inter-computer message routing system with each computer having separate routinng automata for each dimension of the network
US5928332A (en) * 1996-12-06 1999-07-27 Intel Corporation Communication network with reversible source routing that includes reduced header information being calculated in accordance with an equation

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2365667A1 (en) * 2003-02-03 2011-09-14 Nippon Telegraph And Telephone Corporation Data transfer apparatus and data transfer system
FR2852176A1 (en) * 2003-03-04 2004-09-10 Alterlane Data processing stations interconnecting system, has station groups interconnecting device with repeater unit receiving blocks from transmitting station and re-transmitting blocks towards destination station

Also Published As

Publication number Publication date
WO2001041340A9 (en) 2002-05-23
AU1934501A (en) 2001-06-12

Similar Documents

Publication Publication Date Title
EP0836780B1 (en) Network addressing arrangement for backward compatible routing of an expanded address space
USRE39454E1 (en) Transfer of messages in a multiplexed system
CN1514622B (en) Method for translation protocol of module system
CA2095053C (en) Network addressing
JP3279319B2 (en) Method and apparatus for synchronizing data transmission over an on-demand link in a network
US7180904B2 (en) Interface link layer device to build a distributed network
JP3805333B2 (en) Method for confirming multicast transmission method in Ethernet (registered trademark) passive optical network
US6105068A (en) Method and apparatus for determining a protocol type on a network connection using error detection values stored within internetworking devices
US20050128949A1 (en) Network system having a plurality of switches capable of improving transmission efficiency and method thereof
EP0331190A2 (en) Method for controlling address parameters for interconnecting LAN and ISDN
US7260650B1 (en) Method and apparatus for tunneling information
US7023849B2 (en) Packet switching apparatus, method of transmitting multicast packet at packet switching apparatus, and setup method of packet switching apparatus
US8391304B2 (en) Ethernet-MOST gateway apparatus
WO1998039696A2 (en) Unitary virtual circuit in digital network having communication
US20010024457A1 (en) Encoding signaling information at a physical layer of a network protocol
US20030142626A1 (en) Communication system, communication terminal, server and data transfer control program
CN113259268A (en) Network port and serial port data forwarding gateway and method supporting redundancy architecture
US20080137638A1 (en) Communication Network System Of Bus Network Structure And Message Routing Method Using The System
KR20010070055A (en) Communication control apparatus and method, communication system, and program storage medium
US20030026252A1 (en) Data packet structure for directly addressed multicast protocol
US6167045A (en) Method and system for receiving data packets in a unidirectional broadcasting system
US7801172B2 (en) Data packet structure for digital information distribution
US20010006520A1 (en) Data Communications
WO2001041340A1 (en) Method and apparatus for transmission of source-routed data
CN100359504C (en) Backplane architecture for a media server

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/5-5/5, DRAWINGS, REPLACED BY NEW PAGES 1/5-5/5; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP