Browse Prior Art Database

Timers for Reliable Linear Multicast

IP.com Disclosure Number: IPCOM000110537D
Original Publication Date: 1992-Dec-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 7 page(s) / 303K

Publishing Venue

IBM

Related People

Dudley, JG: AUTHOR [+3]

Abstract

This article presents a method for calculating timeout values and retry counts for a reliable linear multicast facility, based on the characteristics of the path through the network. It also discusses methods to allow a user of the function to specify its service requirements, and to allow a recipient to delay its response while still acknowledging receipt of the request packet.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 20% of the total text.

Timers for Reliable Linear Multicast

       This article presents a method for calculating timeout
values and retry counts for a reliable linear multicast facility,
based on the characteristics of the path through the network.  It
also discusses methods to allow a user of the function to specify its
service requirements, and to allow a recipient to delay its response
while still acknowledging receipt of the request packet.

      This invention assumes that a linear multicast facility is
available wherein a linear multicast request is sent from an origin
node to a destination node via Automatic Network Routing, as
described in [1].  The request is copied selectively to nodes along
the path.  Whether a node receives a copy of the request is indicated
in the packet's routing field.  The function that allows the origin
to specify which nodes receive a copy of the request is the selective
copy function described in [2].

      The invention further assumes that each node receiving the
request will respond with one of three reply types: positive,
negative, and function pending.  The first two reply types are called
definite; no further replies are required from a node once its
definite reply has been received by the origin.  The third reply type
is called indefinite; a later definite reply is expected from a
recipient sending an indefinite reply.  A node sends a
function-pending reply because further processing is required before
a definite reply can be sent.

      Until a definite reply is received from all intended
recipients, the origin must periodically retransmit the request.
Each retransmission requires a response from each recipient.  If a
recipient has already sent a definite reply, then that reply is to be
resent.  If the recipient previously has sent an indefinite reply,
than that reply is repeated until the processing is complete and it
can become a definite reply.  However, the recipient should send the
first definite reply as soon as its processing is complete.

      Description of the Timers: There are three timer values
required for the operation of the reliable linear multicast function.
First, there is the service requirement timer; this timer value is
specific to each application that uses the reliable linear multicast
function.  It defines the deadline by which the reliable linear
multicast must be complete.  We denote the service requirement timer
value by Ts.

      Second, there is a basic retransmission timer.  A reliable
linear multicast facility requires that each request reach its
intended destinations.  A request must be retransmitted if the basic
retransmission period expires before the originator receives replies
from all the intended recipients.  The origin retransmits to only
those nodes from which a reply is expected but not received.  When
replies of any type have been received from all intended recipients,
the basic retransmission timer is cancelled.

      The basic...