Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/06—Management of faults, events, alarms or notifications
  • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
  • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

• the present invention relates generally to computer systems and computer networks, and relates more particularly to content delivery over computer networks. Specifically, the present invention relates to a method and apparatus for adaptive forwarding of data over a computer network.
• FIG. 1 is a schematic illustration of one embodiment of a system 100 for forwarding data over a network.
• a wide range of end-to-end computing applications (including overlay networks, end-system multicast, proxy servers, network address translation and protocol tunneling, among others) use intermediaries, or forwarding nodes 106 ⁇ - 106 n (e.g., computing devices or routers), to route a stream 112 of data from a sender 102 (e.g., a server) to one or more receivers 104.
• Receivers 104 may in turn deliver the data to one or more computing applications 108.
• a typical problem with a system such as the system 100 is that a failure or disruption at any forwarding node disrupts the end-to-end chain, resulting in incomplete data delivery to the receiver(s). This is especially troublesome for large networks, as the probability of node failure increases with the number of forwarding nodes implemented.
• Conventional solutions for addressing node failure in a forwarding network include source-based repair such as a Transmission Control Protocol/Internet Protocol (TCP/IP) session between the data source and the receiver, packet number-based retransmission requests, and various application- and content- specific resiliency schemes (e.g., resuming File Transport Protocol at a specific byte offset from the start of a file, or resuming a video transmission at a specific frame number).
• TCP/IP Transmission Control Protocol/Internet Protocol
• application- and content- specific resiliency schemes e.g., resuming File Transport Protocol at a specific byte offset from the start of a file, or resuming a video transmission at a specific
• the present invention is a method and an apparatus for failure-resilient forwarding of data over a computer network.
• a marker is introduced into the data stream, e.g., at the sending node and, in turn, allows forwarding nodes and/or receivers to efficiently track data stream reception.
• the marker functions as a checkpoint for the data transport process, and is identified and indexed at each forwarding node and receiver.
• Each receiver saves the marker prior to delivering data to an application, thereby designating a point in the data stream at which all preceding data is confirmed to have been delivered to the application.
• the receiver may request stream data from an alternate forwarding node by specifying to the alternate forwarding node to provide data starting from the marker.
• Figure 1 is a schematic illustration of one embodiment of an end-to- end computing network
• Figure 2 is a flow diagram illustrating one embodiment of a method for enabling failure-resilient forwarding of data from a sender to one or more receivers according to the present invention
• Figure 3 is a table illustrating one method of distributing content using the system illustrated in Figure 2;
• Figure 4 is a flow diagram illustrating one embodiment of a method for recovering lost data in a data stream;
• Figure 5 is a high level block diagram of the present failure-resilient forwarding system that is implemented using a general purpose computing device.
• identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
• the present invention is a method and an apparatus for failure-resilient forwarding of data over a computer network.
• a trigger condition such as forwarding node failure, performance degradation, query, resource use imbalance and the like, initiates a network adaptation to correctly resume transmission reception of a data stream.
• FIG. 2 is a flow diagram illustrating the flow of data through one embodiment of a method 200 for enabling failure-resilient forwarding of data from a sender to one or more receivers according to the present invention.
• the method 200 is initialized at step 202 and proceeds to step 204, where a sending node or a forwarding node (e.g., sender 102 or any one of the forwarding nodes 106 of FIG. 1) obtains (in the case of the sender) or receives (in the case of the forwarding node) at least a portion of a data stream.
• the data stream may simply be a portion or an arbitrarily sized data segment of a much larger data stream.
• a sequence of "chunks" or "portions" of the larger data stream is being sent from the sending node to a receiving node.
• the sender or a forwarding node injects a marker into the portion of the data stream, and forwards the "marked" data stream, with or without further modification, to one or more next recipient nodes in the network (e.g., one or more subsequent forwarding nodes or receiving nodes) via a point-to-point reliable transport protocol (e.g., a protocol that is packet loss resilient, such as TCP/IP and the like).
• the marker designates a reference point in the generic data stream and in one embodiment is a recognizable bit field with a unique identifier.
• the marker may be recognized by reserved bit sequences, fixed inter-marker offsets, or an offset specified by a prior marker.
• markers may be periodically injected into the data stream, so that a plurality of marked data streams is transported through the network.
• the method 200 branches off into at least one of two possible subsequent processes.
• steps 208 - 210 the method executes steps in accordance with the function of a forwarding node; in steps 209-214, the method 200 executes steps in accordance with the function of a receiving node.
• the method 200 inquires if the recipient of the marked data stream is a forwarding node. If the method 200 determines that the recipient is forwarding node, the method 200 proceeds to step 210, where the method 200 inspects the received data stream, stores the data in a local buffer of the forwarding node, and creates or updates a marker index at the forwarding node.
• the marker index that the method 200 updates comprises two key components: (1) a record of the most recently received marker; and (2) a record of each marker previously received and stored by the forwarding node.
• the method 200 forwards the marked data stream to the next recipient(s) (e.g., one or more other forwarding nodes or receivers) in the network.
• the marked data stream is processed by the next recipient node(s) starting at the point in the method 200 just following step 206, as indicated by the loop from step 210.
• all forwarding nodes receive the marked data stream, relay the marked data stream to the next forwarding nodes or receivers, and index the markers.
• FIG 3 is a schematic illustration of one embodiment of a marker index 300 according to the present invention, such as the marker index updated by the method 200 in step 210 of Figure 2.
• the marker index 300 is a table.
• the marker index 300 stores, for each marker (e.g., markers Mi - M 3 ), the marker's unique identifier and its position in the local buffer. As will be further described below with reference to Figure 4, this stored information may be used to recover data lost, for example, due to a forwarding node failure.
• the method 200 concludes at step 208 that the recipient of the marked data stream is not a forwarding node, the method 200 terminates.
• the method 200 inquires in step 209 if the recipient is a receiving node. If the method 200 concludes that the recipient is a receiving node, the method 200 proceeds to step 212 and queues the stream data received by the receiver until the marker is encountered. In step 214, the method 200 saves the marker and delivers the queued data (i.e., all undelivered, non- marked data preceding the marker in the data stream) to a process desiring the original data stream (e.g., an application or a storage process). Alternatively, if the method 200 concludes in step 208 that the recipient is not a receiving node, the method 200 terminates.
• the queued data i.e., all undelivered, non- marked data preceding the marker in the data stream
• one or more nodes are both forwarding and receiving nodes. That is, a node may be adapted to both receive data for delivery to an application, and also to forward the received data on to another node. Thus, the node is capable of executing both the forwarding and the receiving methods contained within the method 200.
• the forwarding and receiving processes e.g., steps 208-210 and 209-214, respectively
• the reference numerals do not connote an order in which the processes occur. Therefore, those skilled in the art will appreciate that the forwarding and receiving methods are executed independently, and that the methods may actually occur simultaneously, or may occur one after the other in any order.
• the sequence of the reference numerals as they apply to steps 208-216 is not intended to be limiting in any sense.
• the markers injected into the data stream represent checkpoints for the data transport process.
• the method 200 designates points in the data stream where all preceding data has been delivered, reliably and in order, to the waiting application.
• the method 200 also serves the function of designating points in the data stream where any succeeding data has yet to be delivered. This saved marker information may be used to recover data lost, for example, due to a forwarding node failure.
• Figure 4 is a flow diagram illustrating one embodiment of a method
• the method 400 may be executed in the event that a forwarding node (e.g., a forwarding node 106 of Figure 1) fails (e.g., due to disconnection from the network or power failure) and thus ceases to forward data to subsequent recipients.
• the method 400 is initialized at step 402 and proceeds to step 404, where the method 400 identifies a forwarding node failure and connects a receiver (or subsequent forwarding node) to an alternate forwarding node, or a "backup node" (e.g., a node that preceded the failed node in the routing path).
• the method 400 may connect the receiver to any "sister" node of the failed forwarding node that is still receiving the data stream.
• the backup node is selected for efficiency. For example, if the failed node is node X n in Figure 1, then the backup node can be selected to be node Xi or node X n+ ⁇ . The selection of the proper node can be based on distance, delay, computational cost and the like.
• step 406 the method 400 requests, from the backup node, the stream data starting from the last marker, M, saved by the receiver, h an alternative embodiment, the method 400 may request the stream data starting from a specified position after the last marker M (e.g., three bits after the marker M). The request includes the unique identifier for the marker M.
• step 407 the method 400 inquires if the backup node will accept the request presented in step 406. If the backup node rejects the request, the method 400 returns to step 404 and connects to another backup node. Alternatively, if the backup node accepts the request in step 407, the method 400 enables the backup node to look up the marker M in the backup node's marker index. If the marker M is present, the backup node begins sending the marked data stream, using the location of the marker M in its local buffer as the starting point, hi one embodiment, any data residing in the local buffer past the point of the marker Mis discarded.
• step 408 the method 400 resets a queue "write pointer" for the receiver to a position immediately following the marker M.
• the method 400 also erases data following the write pointer in the local buffer, and the receiver will now start queuing data over the new connection from the new forwarding node.
• the arriving data stream overwrites any data following the marker M in the receiver's local buffer.
• the method 400 may request discrete portions of the marked data stream from multiple backup nodes.
• the method 400 inquires if the next marker, M+l, has arrived at the receiver.
• the method 400 delivers data queued by the receiver (minus the marker M) to an application requesting the data at step 412. If the next marker M+l has not arrived, the method 400 continues to queue data over the new connection from the backup node.
• steps 408-412 of the method 400 are steps typically executed by a receiver node; they have been discussed here, in the context of the method 400, to illustrate the method by which the receiver mode may implement such steps in conjunction with the recovery of lost data.
• the method 400 is therefore able to repair failures accurately and efficiently by resuming data transmission at the point of interruption. Moreover, as the repair only requires communication with a nearby forwarding/backup node, repair paths are short and network load is fairly distributed.
• the method 400 also works at the application layer with any reliable point-to-point transport protocol, can leverage existing point-to-point protocols, and may allow reframing and multi-protocol forwarding. Thus, the method 400 works independently of transport protocols, as well as independently of data stream content.
• FIG. 5 is a high level block diagram of the present failure-resilient forwarding system that is implemented using a general purpose computing device 500.
• a general purpose computing device 500 comprises a processor 502, a memory 504, a failure-resilient forwarding mechanism or module 505 and various input/output (I/O) devices 506 such as a display, a keyboard, a mouse, a modem, and the like.
• I/O devices 506 such as a display, a keyboard, a mouse, a modem, and the like.
• at least one I/O device is a storage device (e.g., a disk drive, an optical disk drive, a floppy disk drive).
• the failure-resilient forwarding mechanism 505 can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel.
• the failure-resilient forwarding mechanism 505 can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices 506) and operated by the processor 502 in the memory 504 of the general purpose computing device 500.
• ASIC Application Specific Integrated Circuits
• the failure-resilient forwarding mechanism 505 and the associated methods described herein with reference to the preceding Figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like).
• the present invention may have other applications in the field of content delivery.
• the present invention may be implemented to assure reliable data delivery with any network reconfiguration, and for any reason.
• Other reconfiguration techniques may include finding a backup node using a centralized or distributed registry of nodes (e.g., a known server or a Domain Name Service (DNS) lookup), a distributed hash table lookup, or a broadcast search, among others.
• DNS Domain Name Service
• Other reasons for network reconfiguration may include responding to performance degradation, optimization of network resource utilization and load balancing, among others.
• the present invention represents a significant advancement in the field of content delivery.
• a method and apparatus are provided that enable efficient, failure-resilient forwarding of data over a network.
• the network is able to accurately and efficiently resume data transmission at the point of interruption, without transmitting redundant or out-of-order data to a receiver.
• the failure and recovery of the system are substantially transparent.
• the methods of the present invention are not application specific, but may be adapted for use with any type of data stream, regardless of content, and with any type of reliable transport protocol.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Mathematical Physics (AREA)
• Databases & Information Systems (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Data Mining & Analysis (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Computer And Data Communications (AREA)
• Information Transfer Between Computers (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (2)

Family

ID=35137767

Family Applications (1)

Country Status (6)

Cited By (1)

Families Citing this family (26)

Family Cites Families (34)

• 2004
  • 2004-04-23 US US10/830,779 patent/US7392319B2/en not_active Expired - Fee Related
• 2005
  • 2005-04-22 EP EP05761757A patent/EP1743353A4/en not_active Withdrawn
  • 2005-04-22 JP JP2007509655A patent/JP4857261B2/ja not_active Expired - Fee Related
  • 2005-04-22 WO PCT/US2005/013716 patent/WO2005104176A2/en not_active Ceased
  • 2005-04-22 CN CNA2005800124431A patent/CN101164056A/zh active Pending
  • 2005-04-22 KR KR1020067020197A patent/KR20070014139A/ko not_active Abandoned
• 2008
  • 2008-06-09 US US12/135,764 patent/US7969869B2/en not_active Expired - Fee Related
  • 2008-06-09 US US12/135,768 patent/US7865609B2/en not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events