 |
Description  |
|
|
TECHNICAL FIELD
The invention relates to multicast protocols for networks.
BACKGROUND OF THE INVENTION
A computer network is a means of exchanging or transferring information
(e.g. data, voice, text, video, etc.) between host machines in the
network. The network comprises host machines connected by a communication
subnet. The subnet comprises nodes (also called switching elements)
connected, to each other and to the hosts, by links. The information,
often conveniently formatted into packets or cells, is transferred between
a source host (also called a "source") and one or more receiving hosts
(also called "destinations" or "endpoints ") on a path by selecting a set
of links and nodes in the communication subnet to form the path. See,
Andrew S. Tanenbaum, Computer Networks, Prentice-Hall, Inc., Englewood
Cliffs, N.J., 1981.
There are three types of designs for the communication subnet: 1)
point-to-point subnets, 2) broadcast subnets and 3) multicast subnets. In
a point-to-point subnet, if two hosts wish to communicate, but do not have
a single link directly connecting them, then the hosts must communicate
indirectly, i.e. via intermediate nodes. Typically, a communication is
received in its entirety at each intermediate node, stored in buffers in
the node until the next required link in the path is free, and then
forwarded. In a broadcast subnet, information sent by any host is received
by all other hosts. The information typically contains an address
specifying the host for which the information is intended. Upon receiving
the information, each host checks the address, and if the information is
intended for that host, it is processed; otherwise the information is
ignored. In a multicast subnet, a communication is received by a subset of
hosts in the network. Multicasting may be point-to-multipoint (where a
single host transmits to a plurality of hosts, e.g. electronic
distribution of books from a publisher to bookstores across the nation) or
multipoint-to-multipoint (where a subset of hosts in a network transmits
information among the hosts in the subset, e.g. nationwide video
conferencing).
A multicast protocol is a set of rules for conveying information from a
single host to multiple hosts in a network or for conveying information
among a subset of hosts. Although multicast protocols have been designed
for unreliable broadcast network and satellite broadcast channels, (see,
J. M. Chang and N. F. Maxemchuk, "Reliable Broadcast Protocols," ACM
Trans. Comp. Sys., Vol. 2, No. 3, 251-273, August 1984; K. Sabnani and M.
Schwartz, "Multidestination Protocols for Satellite Broadcast Channels,"
IEEE Trans. Comm., Vol. COM-33, No. 3, March 1985) the design of multicast
protocols in general, and of multicast protocols for wide area, broadband,
high speed networks in particular, presents special challenges. First,
since each host must acknowledge information received, the protocol must
overcome the acknowledgement implosion problem (i.e. the receipt at the
source host of multiple acknowledgment signals) inherent in any
multicasting scheme. Second, propagation delays (due to the physical area
served by the network and the finite speed of signals transmitted over the
network) combined with high transmission rates (due to a desire to
transmit as much information as possible in the shortest time possible)
produce large delay-bandwidth products.
Large delay-bandwidth products tend to increase the need to retransmit
(i.e. remulticast) information. This is because: 1) at any given time a
large amount of information is on the network (due to the large network
bandwidth), and this large amount of information must be remulticast when
information is lost--e.g. due to overflowing buffers in nodes in the
network, and 2) feedback or acknowledgment signals from receiving hosts
take a non-zero amount of time to reach the source host (due to
propagation delays) thereby causing the source host to retransmit due to
an absence of, or delay in, acknowledgments.
It is desirable that a multicasting source avoid unnecessary remulticasts
since this will further increase the end-to-end delay of the protocol and
increase traffic on the network. Hence, there is a need for a multicast
protocol for broadband networks that can avoid unnecessary retransmissions
of information and avoid the acknowledgment implosion problem while
advantageously providing high throughput and low delay in information
transmission.
SUMMARY OF THE INVENTION
The aforementioned problems are solved, in accordance with the invention,
by a method of network multicasting in which a multicast tree from a
source host to a set of destination hosts is utilized. The inventive
method delivers information from the source host to the destination hosts
in sequence along the multicast tree, independent of how the tree is
created and of how resources are allocated.
In particular, the present invention is a method of transmitting blocks of
information from a source to a set of destinations, where each destination
is assigned to a local exchange in a set of local exchanges, receiving at
the source a respective first status signal from each local exchange which
indicates a reception status for that local exchange relative to the
transmitted blocks, and transmitting in response to the first status
signals, those blocks not received by any one of the local exchanges.
The inventive method reduces the acknowledgement implosion problem by
limiting or consolidating status and acknowledgment information from the
destinations. The inventive method also reduces unnecessary transmissions
of information throughout the network by retransmitting information along
local multicast trees. The protocol may be implemented in various types of
networks. For example, the protocols may take advantage of improved
resource allocation techniques in datagram networks or may take advantage
of any efficient technique for setting up virtual circuits in
connection-oriented networks.
BRIEF DESCRIPTION OF THE DRAWINGS
Advantages of the invention will become apparent from the following
detailed description taken together with the drawings in which:
FIG. 1 illustrate s the structure of a computer network in which the
inventive method is illustratively practiced.
FIG. 2 is a block diagram of a network architecture based on the ISO model.
FIG. 3 illustrates the structure of a computer network in which the
inventive method may be practiced.
FIG. 4 illustrates a global multicast tree rooted at S and local multicast
trees root at E.sub.i,1.
FIG. 5 is a diagram of steps in a first embodiment of the inventive method.
FIG. 6 illustrates packet formats for the first embodiment of the inventive
method.
FIG. 7 is a diagram of steps in a second embodiment of the inventive
method.
FIG. 8 is a diagram of steps in a third embodiment of the inventive method.
DETAILED DESCRIPTION
A. Overview of Multicast Protocols
FIG. 1 illustrates the structure of a typical computer network in which the
inventive method may be practiced. Computer networks, i.e. interconnected
collections of autonomous computers, provide a variety of services such as
electronic mail and file transfer services. The first part of the network
typically comprises a collection of machines 102, called hosts, intended
for running application programs, and communications subnet 104 linking
the hosts. The subnet's job is to transfer information from host to host.
The subnet typically comprises two basic components: switching elements
(also called nodes or interface message processors, IMPs) 106 and links
(also called transmission lines) 108. Each host is connected to one, or
occasionally several, IMPs.
Computer networks are typically designed in a highly structured way. To
reduce design complexity, most computer networks are organized as a series
of layers. For example, the Reference Model of Open Systems
Interconnection developed by the International Standards Organization
(ISO) is a seven layer model. A network architecture based on this model
is illustrated in FIG. 2. See, Tanenbaum, supra. The purpose of each layer
is to offer services to higher layers, shielding those higher layers from
the details of how the offered services are actually implemented. A
service is formally specified by a set of primitives defining the
operations that a layer provides to the layer above it. Adjacent layers
communicate through an interface which defines the services the lower
layer offers the higher layer.
The active elements in each layer are called entities. An entity may be a
software entity (e.g. a process) or a hardware entity (e.g. an integrated
circuit) or a combination of both. Entities in the same layer on different
machines are called peer entities.
Each computer network has associated with it a well-defined "protocol" or
set of rules to govern communication between peer entities. In particular,
protocols are used to physically establish, execute and terminate
communications between like or peer layers on the network so that offered
services may advantageously be used. See, generally, Tanenbaum, supra;
Engineering and Operations in the Bell System, Bell Laboratories, Inc.,
1983. Communication between corresponding layers in different hosts is
virtual in that only at the lowest layer is there a physical connection.
As noted above, communication subnet 104 (which, in the ISO model,
comprises the three lowest layers) may be designed for point-to-point
communications (i.e. communications between two hosts) or for broadcast
communications. Recently however, multicast transmission (or simply
"multicasting") among a subset of hosts in network has become increasingly
important.
The following detailed description presents several embodiments of a
multicast transport protocols, i.e. multicast protocols for the transport
layer of the ISO model. The protocols are general in that they can be
built on top of either virtual circuit networks or datagram networks. The
protocols may advantageously be used in high speed, broadband networks
such as asynchronous transfer mode (ATM) networks.
The function of the inventive protocols is to deliver packets of
information from a source to destinations in sequence along a multicast
tree, independent of how the tree is created and of how resources (e.g.
bandwidth in the links) are allocated. Thus, the protocols are deployable
in various networks and may advantageously use any resource allocation
techniques in datagram networks or any techniques for setting up virtual
circuits in connection-oriented networks.
The only service expected by the inventive method is the establishment of a
multicast tree from the source to the destinations. A tree is
characterized by a root and a set of intermediate nodes and links which
end in a set of leaves. For example, in the network of FIG. 1, a
point-to-multipoint multicast tree will have as its source one of the
hosts, as its leaves a set of destination hosts, and as its intermediate
nodes and links the IMPS and transmission lines connecting the root to the
leaves. A multicast tree is not just a set of connecting nodes and links,
but it also includes the computing and communication resources, such as
bandwidth needed to guarantee a given quality of service, reserved along
the intermediate nodes and links. The protocols described herein are
independent of how the multicast tree is established, e.g. by using ST-2,
RSVP or any connection-oriented protocol. See, C. Patridge and S. Pink,
"An Implementation of the Revised Internet Stream Protocol (ST-2)",
Journal of Internetworking: Research and Experience, Vol. 4, No. 1, March
1992; L. Zhang et al., "RSVP: A New Resource ReSerVation Protocol," IEEE
Network Magazine, September 1993. As long as the multicast tree is
provided, the protocols will operate.
The multicast protocols are advantageously illustrated in the context of
network 300 of FIG. 3. Hosts 302 (also referred to as endpoints) are
connected to local exchange (LE) 304 either directly or through access
nodes 306. Note that the term local exchange is not limited to
connection-oriented networks (e.g. the inventive method applies in the
case where the local exchange is considered to be a router in a datagram
network). The local exchanges are interconnected using backbone network
310, illustratively shown here as an ATM network. A hierarchical
addressing scheme such as E.164, which is very similar to the current
telephone numbering system, is assumed. That is, given the address of an
endpoint, it is possible to infer the area to which the endpoint belongs.
For example, if the address of an endpoint is 908-555-4567, it can be
inferred that the endpoint is served by area code 908 and that the
endpoint is located in New Jersey. All that is necessary is that the
protocol have sufficient information to define destinations in a localized
region as a group for purposes of retransmitting packets.
As noted above, the protocols require a multicast tree. Assume that a
multicast tree is set up with the allocation of resources at the network
level in the ISO model (e.g. the ATM layer), rooted at a source host S and
spanning all the destinations (i.e., the other hosts or endpoints). This
is typically referred to as the global multicast tree to distinguish it
from the local multicast tree. FIG. 4 illustrates the global multicast
tree. The global multicast tree identifies multicast virtual circuit (MVC)
405 shown by bold lines. The endpoints in the local exchange L.sub.i are
denoted by E.sub.i,j. L.sub.i is not an endpoint. It is assumed that some
estimate of round trip delay is available between S and each E.sub.i,1
after the multicast tree is set up. The round trip delay corresponding to
E.sub.i,1 is referred to as RTD.sub.i. The peak bandwidth, packet size,
block size and re-ordering buffer size required at each destination are
also set at the connection establishment time (i.e. the time at which
network resources, such as bandwidth are reserved before transmission of
data).
Note that several local multicast trees are formed based on the global
multicast tree. A local multicast tree rooted at E.sub.i,1 is the portion
of the global multicast tree spanning the E.sub.i,j 's in the L.sub.i.
Local multicast trees 410-i are shown by dashed lines in FIG. 4. Such a
local multicast tree will be identified by a local multicast virtual
circuit identifier, called an LMVCI. For illustrative purposes, only
point-to-multipoint multicasting will be considered so that initially,
there is a fixed source and a fixed set of endpoints. That is, there is a
fixed single source and fixed multiple destinations case. It is shown
later how to accommodate changing source and changing destinations as well
as the multipoint-to-multipoint multicasting situation.
B. A First Embodiment--Designated Status Protocol (DSP)
In this section, a first embodiment of a multicast protocol, called the
Designated Status Protocol (DSP), is described. In this protocol, the
multicast tree is further characterized. The source picks an endpoint
E.sub.i,1, which can be thought of as the representative of the group of
E.sub.i,j 'S, in each local exchange L.sub.i. This E.sub.i,1 is
responsible for sending its own status to the source. Thus, if there are m
LE's with final destinations (or endpoints), there will be m designated
endpoints which are supposed to send their status to the source. In fact,
the status sent by E.sub.i,1 will show which blocks have been received by
E.sub.i,1, i.e. a status signal will be sent to the source indicating a
reception status relative to the transmitted blocks. A block is a
collection of packets, and it is the unit chosen for selective repeat
retransmission as described below. However, the status typically will not
indicate which blocks have been received by the E.sub.i,j 's for
j.noteq.1. Each E.sub.i,1 will be referred to as a local source (in
contrast to the global source S).
FIG. 5 is a diagram of the main steps in the DSP protocol. The protocol
works as follows:
1. S multicasts data packets to all the destinations (E.sub.i,j 's
.A-inverted.i,j) using the global multicast tree in step 510. This
multicast will be called a global multicast.
2. Each E.sub.i,1 sends its own status to S in the form of control (status)
packets at regular intervals in step 520. The status packet contains the
information about which blocks have been received by E.sub.i,1. S globally
re-multicasts a block again in step 530 if there exists an E.sub.i,1 which
has not received the block within the expected time. This time duration
is, in general, a multiple of the round-trip-delay between S and the
E.sub.i,1 in question.
3. Each E.sub.i,j (j.noteq.1) sends its status to the corresponding
E.sub.i,1 at regular intervals in step 540. E.sub.i,1 locally multicasts a
block in step 550 if there exists an E.sub.i,j (j.noteq.1) which has not
received the block during global multicast. Note that an E.sub.i,j
(j.noteq.1) depends on the corresponding E.sub.i,1 for the retransmission
of a block if it did not receive the block either during the global
multicast or during local multicasts.
4. S will multicast new blocks provided each E.sub.i,1 has available buffer
space for the new blocks. Note that an E.sub.i,1 advantageously has two
buffers: (1) a reassembly buffer which is used to assemble the packets it
receives from S and (2) a retransmission buffer which is used to retain
the packets (blocks) that have not been received by all the E.sub.i,j 's
in its jurisdiction (Note: E.sub.i,j 's served by an L.sub.i are said to
be in the same jurisdiction.) A block is transferred from the reassembly
buffer to the retransmission buffer when there is space in the
retransmission buffer. This transfer creates space in the reassembly
buffer of E.sub.i,1. If, however, both buffers are full, there is no space
for new blocks. The status of space available in the reassembly buffer is
sent to S as a part of the status message from E.sub.i,1 to S so that S
knows if it can multicast a new block.
A slightly modified version of the protocol can also be considered in which
the source multicasts to all the representatives E.sub.i,1 's (instead of
to all the E.sub.i,j 's for all i,j) and the E.sub.i,1 's multicast to the
E.sub.i,j 's (j.noteq.1), thereby dividing the connection along each
source/destination pair into two segments: one from the source to
E.sub.i,1 and the other from the E.sub.i,1 to E.sub.i,j (j.noteq.1).
The following paragraphs describe the DSP protocol in greater detail by
describing the format of control and data packets and by describing the
data structure used by the entities of the DSP.
The following packet structures are advantageously used in the protocol and
are illustrated in FIG. 6: control (status) packet 610 from an E.sub.i,1
to the source; control (status) packet 620 from an E.sub.i,j (j.noteq.1)
to E.sub.i,1 ; multicast data packet 630 from source S to E.sub.i,j 's
.A-inverted.i, j; and multicast data packet 640 from an E.sub.i,1 to
E.sub.i,j .A-inverted.j (j.noteq.1).
The notation given below is used to represent the fields of the control and
data packets illustrated in FIG. 6. Note that MVCI (Multicast Virtual
Circuit Identifier) is reminiscent of the VCI (Virtual Circuit Identifier)
used in connection-oriented networks. However, MVCI, as used herein, is
more general and simply identifies a specific multicast connection which
may use a static allocation of resources at the connection establishment
time or a dynamic allocation of resources as done by the RSVP protocol.
See Zhang, supra.
TABLE 1
______________________________________
Explanation of Notation Used in Packet Formats
Notation Explanation
______________________________________
MVCI a multicast virtual circuit identifier.
LMVCI a local multicast virtual circuit identifier.
Type Type of a packet.
Type = 0 indicates a status packet from
E.sub.i,1 to the source.
Type = 1 indicates a status packet from
E.sub.i,j (j.noteq.1) to E.sub.i,1.
Type = 2 indicates a data packet from
E.sub.i,1 to E.sub.i,j (j.noteq.1).
Type = 3 indicates a data packet from
S to E.sub.i,j .A-inverted. i,j.
Seq# sequence number of a packet. It is incremen-
ted by sender each time a new packet is trans-
mitted.
k interval between two successive status packets
in units of
T.sub.IN, where
T.sub.IN = max(RTD/kou,ipt),
kou is a constant between 2 and 32, and
ipt is the interval between two successive
packet transmissions.
LW.sub.r lower end of window in receiver, that is,
the maximum sequence number of the block
below which every packet in every block has
been correctly received as known at the re-
ceiver. In the context of the global
multicast tree, E.sub.i,1 's are treated as receivers.
For local multicast trees, E.sub.i,j 's (j.noteq.1) are
treated as receivers.
L the largest allowed number of outstanding
blocks chosen at the connection establishment
time. An outstanding block is a block that
has been multicast at least once but not yet
been acknowledged by all the E.sub.i,1 's.
LOB list of outstanding blocks. A bit map represen-
ting the outstanding blocks between LW.sub.r and
(LW.sub.r + L - 1
Buffer.sub.-- available
an integer representing the space available
in the reassembly buffer of an E.sub.i,1
in terms of the number of blocks.
EPI an endpoint identifier which is used to identify
an E.sub.i,1.
LEPI a local endpoint identifier which is used to
identify an E.sub.i,j (j.noteq.1).
______________________________________
Table 1: Explanation of Notation Used in Packet Formats
The source S maintains a table T to keep track of the status of each
multicast block. That is, T records which of the E.sub.i,1 's have
received and acknowledged a given block and if there is an E.sub.i,1 which
has not received a block within the expected time. An entry in T
corresponds to a block which has been multicast. Each entry has an array
of retransmission counts count[i] and an array of acknowledgements ack[i],
where count[i] and ack[i] correspond to the retransmission count and
acknowledgement status of E.sub.i,1 respectively. An ack[i] is 1(0) if the
corresponding block has (not) been received and acknowledged by E.sub.i,1
to S. The retransmission count is advantageously set equal to RTD.sub.i
.vertline.T.sub.IN,i +constant where T.sub.IN,i =max(RTD.sub.i
.vertline.kou,ipt) where kou is a constant between 2 and 32 and ipt is the
interval between two successive packet transmissions. RTD.sub.i is the
estimated round trip delay between S and E.sub.i,1. Each time a status
packet arrives from E.sub.i,1, the count[i]'s and ack[i]'s are updated by
S in the table T. In fact, count[i] is decremented by k.sub.i each time a
status packet from E.sub.i,1 arrives at the source S, where k.sub.i is the
interval in units of T.sub.IN,i between two successive status packets of
E.sub.i,1.
In terms of the data structures used by the destinations, each destination
maintains two tables: one corresponding to the blocks and the other
corresponding to the packets within the blocks. The table corresponding to
the blocks keeps track of which blocks have been received by the
destination while the table corresponding to the packets keeps track of
which packets within a block have been received by the destination. In
fact, an entry corresponding to a block is updated in the first table
based on the entries corresponding to the packets within the given block
in the second table. For example, if all packets p.sub.i,j within a block
b.sub.i are received at a destination, the entry corresponding to b.sub.i
in the first table is marked as received by the destination. Otherwise, it
is marked as not received by the destination. This information regarding
b.sub.i is carried in the LOB part of the status messages.
Some additional data structures can be used by a load source E.sub.i,1.
Each E.sub.i,1 maintains a table T.sup.(i) to keep track of the status of
the blocks it has locally multicast. Thus T.sup.(i) helps E.sub.i,1 to
determine which blocks have been received by all the destinations in its
jurisdiction and if there is a block which has not been received by a
destination in its jurisdiction during the expected time. Each entry in
T.sup.(i) corresponds to a block which has been locally multicast.
T.sup.(i) is similar in structure to T. That is, an entry in T.sup.(i) has
an array of retransmission counts count[j] and an array of acknowledgments
ack[j] in which a count[j] and an ack[j] correspond, respectively, to the
retransmission count and acknowledgement status of E.sub.i,j as known to
E.sub.i,1. Each time a status packet arrives from E.sub.i,j, the count[j]
and ack[j] are updated by E.sub.i,1 in the table T.sup.(i). In fact,
count[j] is decremented by k.sub.j each time a status packet from
E.sub.i,j arrives at the local source E.sub.i,1 where k.sub.j is the
interval in units of T.sub.IN,j.sup.(i) between two successive status
packets of E.sub.i,j. T.sub.IN,j.sup.(i) =max (RTD.sub.j.sup.(i)
.vertline.kou,ipt) and RTD.sub.j.sup.(i) =round trip delay between
E.sub.i,1 and E.sub.i,j.
With definitions of the format of data and control packets and with
definitions of the data structures used by entities of the protocol, the
steps in the first embodiment of the protocol (i.e. the DSP protocol) can
be described in even more detail. In particular:
1. S multicasts packets to all the destinations (E.sub.i,j 's
.A-inverted.i,j) using the multicast tree and updates the table T. It sets
count[i] to k.sub.i and ack[i] to 0 for each block.sub.i.
2. Each E.sub.i,1 sends its status to S in the form of control (status)
packets at regular intervals (k.sub.i denotes the interval in terms of
T.sub.IN,i in the status packet). S re-multicasts a block if there exists
an i such that retransmission count count[i] corresponding to the block is
reduced to zero but ack[i] corresponding to the block is not 1. That is, a
block is re-multicast provided there is an E.sub.i,1 that has not received
the block within the time it was supposed to have.
3. Each E.sub.i,j sends its status to the corresponding E.sub.i,1 at
regular intervals. E.sub.i,1 which initializes count[j] and ack[j] to
k.sub.j and to 0 respectively, multicasts a block if there exists a j such
that count[j]=0 and ack[j]=0 in the table T.sup.(i). That is, a block is
locally multicast by E.sub.i,1 if there is an E.sub.i,j that has not
received the block.
4. S will multicast a new block provided buffer.sub.-- available.sub.i
>0.A-inverted.i. That is, buffer space is available at each E.sub.i,1 for
new packets. Note that an E.sub.i,1 may indicate that buffer.sub.--
available.sub.i =0 if it cannot remove old blocks from its retransmission
buffer because some local destinations E.sub.i,j 's have not yet
acknowledged the receipt of those blocks. In this way, an E.sub.i,1 may
prevent the source S from flooding the network with new multicast blocks.
The inventive DSP protocol has several advantages. First, acknowledgment
traffic to the source is considerably reduced compared to schemes in which
every destination individually acknowledges the receipt of a packet/block
to the multicasting source. This is because not all the destinations
(endpoints) send acknowledgment (status) packets to the source S in the
inventive protocol. Only the E.sub.i,1 's send status packets to the
source S. Second, by reason of local multicasting, retransmission traffic
due to redundant global remulticasts is considerably reduced as is the
data latency this protocol has many of the advantages of the SNR protocol.
See, A. N. Netravali et al., "Design and Implementation of a High Speed
Transport Protocol," IEEE Trans. Comm., Vol. 38, No. 11, November 1990. As
in the SNR protocol, the periodic exchange of complete state information
(i.e. the LW.sub.r, LOB and buffer.sub.-- available information) in the
DSP protocol makes error recovery simpler in this scheme as compared to
schemes which do not exchange complete state information periodically.
Third, the global multicast tree and the local multicast trees are set up
at the connection establishment time and hence the data transfer phase is
less time consuming in this scheme as compared to a scheme in which the
multicast trees are set up dynamically. Fourth, if a block does not reach
one of the E.sub.i,1 's, it is multicast as soon as the source detects the
loss of the block. Thus if a block is not received by more than one
E.sub.i,1, then S detects it from the "nearest" E.sub.i,1 that has not
received the block and does not wait for the acknowledgment of the other
E.sub.i,1 's that also have not received it. Therefore, recovery starts as
early as possible. Fifth, it may also be possible to selectively
re-transmit a block and reduce the retransmission traffic if two levels of
VCI's are available: point-to-multipoint and point-to-point.
However, it should be noted that the E.sub.i,1 's have to maintain a
retransmission buffer so that they can re-transmit the blocks locally to
the endpoints E.sub.i,j 's that have not received the blocks. Also, an
endpoint E.sub.i,1 has to take the responsibility of multicasting some
blocks even if it is simply a passive endpoint interested only in
receiving multicast messages, and finally, since the E.sub.i,1 's are
selected at the connection establishment time, it may so happen that in a
particular local exchange L.sub.i, E.sub.i,1 does not receive a block but
some other E.sub.i,j receives it. In that case, S has to re-multicast the
block even though some E.sub.i,j has received it in the jurisdiction of
E.sub.i,1. This problem could be overcome if the E.sub.i,j that received
the block is chosen to be the E.sub.i,1. However, if the E.sub.i,1 is
chosen dynamically, the local multicast tree needs to be built every time
a block is transmitted which is a time consuming procedure.
Note also that, in order to detect connection failures, it may be necessary
for E.sub.i,1 's to know the status of S and for the E.sub.i,j 's to know
the status of corresponding E.sub.i,1 's. In that case, a control packet
for S can be introduced which will be periodically sent to E.sub.i,1 's in
the same manner as in SNR protocol. Similarly, E.sub.i,1 must send its
status to E.sub.i,j 's at regular intervals.
The protocol described here is for a single source and multiple
destinations. In case of multiple sources and multiple destinations,
several multicast trees need to be set up, one rooted at each possible
source. That will allow concurrent multipoint-to-multipoint multicasting.
In order to prevent overbooking of resources along common branches of
various multicast trees, resource allocation techniques like RSVP can be
used in a connectionless network.
B. A Second Embodiment--Consolidated Status Protocol (CSP)
In DSP, an E.sub.i,1 is chosen at each L.sub.i and that designated endpoint
sends its own status message to the source S. In a second embodiment of
the inventive method, termed the Consolidated Status Protocol (CSP), a
status message is sent to the source by each local exchange L.sub.i and
this status message is a consolidated status message of all the
endpoints/destinations in its jurisdiction.
FIG. 7 is a diagram of the main steps in the CSP protocol. The protocol
works as follows:
1. S multicasts a block to all the destinations E.sub.i,j 's
.A-inverted.i,j in step 710 using the multicast tree which is set up at
the connection establishment phase.
2. The E.sub.i,j 's send their status at regular intervals to the
corresponding local exchange L.sub.i in step 720. The format of the status
message is the same as that of the status message 620 sent by E.sub.i,j 's
(for j.noteq.1) to E.sub.i,1 in DSP.
3. L.sub.i consolidates the status messages from the E.sub.i,j 's in its
jurisdiction. Periodically, L.sub.i sends its consolidated status to S in
step 730, i.e. a status signal will be sent to the source indicating a
reception status relative to the transmitted blocks. The following
paragraphs describe a preferred method in which L.sub.i prepares a
consolidated LW.sub.r, a consolidated LOB and a consolidated buffer.sub.--
available fields for the consolidated status message from the
corresponding fields of individual status messages of E.sub.i,j 's. Recall
that the LW.sub.r, LOB and buffer.sub.-- available fields are defined in
Table 1.
The consolidated LW.sub.r is formed as follows:
LW.sub.r(consolidated) =min (LW.sub.r.sup.(j)) where LW.sub.r.sup.(j) is
the LW.sub.r field of the status message of E.sub.i,j to L.sub.i. That is,
L.sub.i chooses the lowest value of LW.sub.r among the LW.sub.r 's of the
E.sub.i,j 's status messages as the LW.sub.r(consolidated). For example,
if the LW.sub.r 's of the E.sub.i,j 's are 4, 3, 2, 8 and 5, the L.sub.i
will choose 2 as LW.sub.r(consolidated) indicating to S that all the
destinations in its jurisdiction have received all the blocks up to block
number 2, although there are some destinations in the same jurisdiction
which have received all the blocks up to block numbers 3, 4, 5 and 8.
The consolidated LOB is formed as follows: the LOB.sub.consolidated is a
bitwise AND of the properly aligned LOB's of the E.sub.i,j 's. Note that
the LOB field has a different meaning for the different E.sub.i,j 's
depending upon the value of LW.sub.r. For example, if the LW.sub.r of
E.sub.i,2 is 3 and LOB is 01000010 (the leftmost bit in LOB corresponds to
the lower end of the window and the rightmost bit cor | | |
