As per Relevance of the word multicast, we have this rfc below:
Network Working Group S.
Request for Comments: 1301
A.
K.
February 1992
Multicast Transport
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo describes a protocol for reliable transport that
the multicast capability of applicable lower layer
architectures. The transport definition permits an arbitrary
of transport providers to perform realtime collaborations
requiring networking clients (aka, applications) to possess
knowledge of the population or geographical dispersion of
participating members. It is not network architectural specific,
does implicitly require some form of multicasting (or broadcasting
at the data link level, as well as some means of communicating
capability up through the layers to the transport
Keywords: reliable transport, multicast, broadcast, collaboration
networking
Table of
1. Introduction 2
2. Protocol description 3
2.1 Definition of terms 3
2.2 Packet format 6
2.2.1. Protocol version 7
2.2.2. Packet type and modifier 7
2.2.3. Subchannel 9
2.2.4. Source connection identifier 9
2.2.5. Destination connection identifier 10
2.2.6. Message acceptance 10
2.2.7. Heartbeat 12
2.2.8. Window 12
2.2.9. Retention 12
Armstrong, Freier & Marzullo [Page 1]
RFC 1301 Multicast Transport Protocol February 1992
2.3 Transport addresses 12
2.3.1. Unknown transport address 12
2.3.2. Web's multicast address 13
2.3.3. Member addresses 13
3. Protocol behavior 13
3.1. Establishing a transport 13
3.1.1. Join request 14
3.1.2. Join confirm/deny 16
3.2 Maintaining data consistency 17
3.2.1. Transmit tokens 17
3.2.2. Data transmission 20
3.2.3. Empty packets 23
3.2.4. Missed data 26
3.2.5. Retrying operations 26
3.2.6. Retransmission 27
3.2.7. Duplicate suppression 29
3.2.8. Banishment 29
3.3 Terminating the transport 29
3.3.1. Voluntary quits 30
3.3.2. Master quit 30
3.3.3. Banishment 30
3.4 Transport parameters 30
3.4.1. Quality of service 30
3.4.2. Selecting parameter values 31
3.4.3. Caching member information 33
A. Appendix: MTP as an Internet Protocol transport 34
A.1 Internet Protocol multicast addressing 34
A.2 Encapsulation 35
A.3 Fields of the bridge protocol 35
A.4 Relationship to other Internet Transports 36
References 36
Footnotes 37
Security Considerations 37
Authors' Addresses 38
1.
This document describes a flow controlled, atomic
transport protocol (MTP). The purpose of this document is to
sufficient information to implement the protocol
The MTP design has been influenced by the large body of
networking and distributed systems literature and technology that
been introduced during the last decade and a half.
sources include [Xer81], [BSTM79] and [Pos81] for transport design
and [Bog83] and [DIX82] for general concepts of broadcast
multicast. [CLZ87] influenced MTP's retransmission mechanisms,
[Fre84] influenced the transport timings. MTP over IP uses
Armstrong, Freier & Marzullo [Page 2]
RFC 1301 Multicast Transport Protocol February 1992
described in [Dee89]. MTP's ordering and agreement protocols
influenced by work done in [CM87], [JB89] and [Cri88]. Finally,
description of MTP's philosophy and its motivation can be found
[AFM91].
2. Protocol
MTP is a transport in that it is a client of the network layer (
defined by the OSI networking model) [1]. MTP provides
delivery of client data between one or more communicating processes
as well as a predefined principal process. The collection
processes is called a web
In addition to transporting data reliably and efficiently,
provides the synchronization necessary for web members to agree
the order of receipt of all messages and can agree on the delivery
the message even in the face of partitions. This ordering
agreement protocol uses serialized tokens granted by the master
producers
The processes may have any one of three levels of capability.
member must be the master. The master instantiates and controls
behavior of the web, including its membership and performance.
master members may be either producer/consumers or pure consumers
The former class of member is permitted to transmit user data to
entire membership (and expected to logically hear itself), while
latter is prohibited from transmitting user data
MTP is a negative acknowledgement protocol, exploiting the
reliable delivery of the local area and wide area
technologies of today. Successful delivery of data is accepted
consuming stations silently rather than having the
delivery noted to the producing process, thus reducing the amount
reverse traffic required to maintain synchronization
2.1 Definition of
The following terms are used throughout this document. They
defined here to eliminate ambiguity
consumer A consumer is a transport that is capable only
receiving user data. It may transmit control packets
such as negative acknowledgements, but may never
any requests for the transmit token or any form of
or empty messages
heartbeat A heartbeat is an interval of time, nominally measured
milliseconds. It is a key parameter in the transport'
Armstrong, Freier & Marzullo [Page 3]
RFC 1301 Multicast Transport Protocol February 1992
state and can be adapted to the requirements of
transport's client to provide the desired quality
service
master The master is the principal member of the web. The
capability is a superset of a producer member.
master is mainly responsible for giving out
tokens to members who wish to send data, and
the web's membership and operational parameters
member A web member is any process that has been permitted
join the web (by the master) as well as the
itself
membership Every member is classified as to its intentions
class joining the web. Membership classes are defined to
consumer, producer and master. Each successive class is
formal superset of the previous
message An MTP message is a concatenation of the user
portions of a series of data packets with the last
in the series carrying an end of message indication.
message may contain any number of bytes of user data
including zero
NSAP The network service access point. This is the
address, or the node address of the machine, where
service is available
producer Producer is a class of membership that is a
superset of a consumer. A producer is permitted (
expected) to transmit client data as well as consume
transmitted by other producers
retention Retention is one of the three fundamental parameters
make up the transport's state (along with heartbeat
window). Retention is a number of heartbeats, and
applied in several different circumstances, is
used as the number of heartbeats a producing client
maintain buffered data should it need to
retransmitted
token In order to transmit, a producer must first be
possesion of a token. Tokens are granted only by
master and include the message sequence number
Consequently, they are fundamental in the operation
the ordering and agreement protocol used by MTP
Armstrong, Freier & Marzullo [Page 4]
RFC 1301 Multicast Transport Protocol February 1992
TSAP The transport service access point. This is the
that uniquely defines particular instantiation of
service. TSAPs are formed by logically concatenating
node's NSAP with a transport identifier (and perhaps
packet/protocol type).
user data User data is the client information carried in MTP
packets and treated as uninterpreted octets by
transport. The end of message and subchannel
are also be treated as user data
web A collection of processes collaborating on the
of a single problem
window The window is one of the fundamental elements of
transport's state that can be controlled to affect
quality of service being provided to the client.
represents the number of user data carrying packets
may be multicast into the web during a heartbeat by
single member
Armstrong, Freier & Marzullo [Page 5]
RFC 1301 Multicast Transport Protocol February 1992
2.2 Packet
An MTP packet consists of a transport protocol header followed by
variable amount of data. The protocol header, shown in Figure 1,
part of every packet. The remainder of the packet is either user
(packet type = data) or additional transport specific information
The fields in the header are statically defined as n-bit
quantities. There are no undefined fields or fields that may at
time have undefined values. Reserved fields, if they exist,
always have a value of zero
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| | |
| | |
| (data content and format |
| dependent on packet type |
| and modifier) |
| |
| | |
| | |
| | |
---------------------------------------------------------- -----
Figure 1. MTP packet
Armstrong, Freier & Marzullo [Page 6]
RFC 1301 Multicast Transport Protocol February 1992
2.2.1. Protocol
The first 8 bits of the packet are the protocol version number.
document describes version 1 of the Multicast Transport Protocol
thus the version field has a value of 0x01.
2.2.2. Packet type and
The second byte of the header is the packet type and the
byte contains the packet type modifier. Typical control
exchanges are in a request/response pair. The modifier
simplifies the construction of responses by permitting reuse of
incoming message with minimal modification. The following table
the packet type field values along with their modifiers.
modifiers are valid only in the context of the type. In the prose
the definitions and later in the document, the syntax for
to one of the entries described in the following table will
type[modifier]. For example, a reference to data[eow] would be
packet of type data with an end of window modifier
type modifier
data(0) data(0) The packet is one that contains
information. Only the process possessing
transmit token is permitted to send
unless specifically requested to
previously transmitted data. All packets
type data are multicast to the entire web
eow(1) A data packet with the eow (end of window
modifier set indicates that the
intends to send no more packets in
heartbeat either because it has sent as
as permitted given the window parameter
simply has no more data to send during
current heartbeat. This is not
information but rather a hint to be used
transport providers to synchronize
computation and transmission of naks
eom(2) Data[eom] marks the end of the message to
consumers, and the surrendering of
transmit token to the master. And like
data[eow] a data[eom] packet implies the
of window
nak(1) request(0) A nak[request] packet is a
requesting a retransmission of one or
Armstrong, Freier & Marzullo [Page 7]
RFC 1301 Multicast Transport Protocol February 1992
data packets. The data field contains
ordered list of packet sequence numbers
are being requested. Naks of any form
always unicast
deny(1) A nak[deny] message indicates that
producer source of the nak[deny])
retransmit one or more of the
requested. The process receiving
nak[deny] must report the failure to
client
empty(2) dally(0) An empty[dally] packet is multicast
maintain synchronization when no client
is available
cancel(1) If a producer finds itself in possession of
transmit token and has no data to send,
may cancel the token[request] by
an empty[cancel] message
hibernate(2) If the master possesses all of the web'
transmit tokens and all outstanding
have been accepted or rejected, the
may transmit empty[hibernate] packets at
rate significantly slower than indicated
the web's value of heartbeat
join(3) request(0) A join[request] packet is sent by a
wishing to join a web to the web's
TSAP (see section 2.2.5).
confirm(1) The join[confirm] packet is the master'
confirmation of the destination's request
join the web. It will be unicast by
master (and only the master) to the
that sent the join[request].
deny(2) A join[deny] packet indicates permission
join the web was denied. It may only
transmitted by the master and will be
to the member that sent the join[request].
quit(4) request(0) A quit[request] may be unicast to the
by any member of the web at any time
indicate the sending process wishes
withdraw from the web. Any member may
a quit to another member requesting that
Armstrong, Freier & Marzullo [Page 8]
RFC 1301 Multicast Transport Protocol February 1992
destination member quit the web due
intolerable behavior. The master
multicast a quit[request] requiring that
entire web disband. The request will
multicast at regular heartbeat
until there are no responses to
requests
confirm(1) The quit[confirm] packet is the
that a quit[request] has been observed
appropriate local action has been taken
Quit[confirm] are always unicast
token(5) request(0) A token[request] is a producing
requesting a transmit token from the master
Such packets are unicast to the master
confirm(1) The token[confirm] packet is sent by
master to assign the transmit token to
member that has requested it. token[confirm
will be unicast to the member being
the token
isMember(6) request(0) An isMember[request] is
verification that the target member is
recognized member of the web. All forms
the isMember packet are unicast to a
member
confirm(1) IsMember[confirm] packets are
responses to isMember[requests].
deny(2) If the member receiving the isMember[request
cannot confirm the target's membership in
web, it responds with a isMember[deny].
2.2.3.
The fourth byte of the transport header contains the client'
subchannel value. The default value of the subchannel field is zero
Semantics of the subchannel value are defined by the transport
and therefore are only applicable to packets of type data. All
packet types must have a subchannel value of zero
2.2.4. Source connection
The source connection identifier field is a 32 bit field containing
transmitting system unique value assigned at the time the
Armstrong, Freier & Marzullo [Page 9]
RFC 1301 Multicast Transport Protocol February 1992
is created. The field is used in identifying the particular
instantiation and is a component of the TSAP. Every
transmitted by the transport must have this field set
2.2.5. Destination connection
The destination connection identifier is the 32 bit identifier of
target transport. From the point of view of a process sending
packet, there are three types of destination connection identifiers
First, there is the unknown connection identifier (0x00000000).
unknown value is used only as the destination connection
in the join[request] packet
Second, there is the multicast connection identifier gleaned from
join[confirm] message sent by the master. The multicast
identifier is used in conjunction with the multicast NSAP to form
destination TSAP of all packets multicast to the entire web [2].
The last class of connection identifier is a unicast identifier
is used to form the destination TSAP when unicasting packets
individual members. Every member of the web has associated with it
unicast connection identifier that is used to form its own
TSAP
2.2.6. Message
MTP ensures that all processes agree on which messages are
and in what order they are accepted. The master controls this
of the protocol by controlling allocation of transmit tokens
setting the status of messages. Once a token for a message has
assigned (see section 3.2.1) the master sets the status of
message according to the following rules [AFM91]:
If the master has seen the entire message (i.e., has seen
data[eom] and all intervening data packets), the status is accepted
If the master has not seen the entire message but believes
message sender is still operational and connected to the master (
determined by the master), the status is pending
If the master has not seen the entire message and believes
sender to have failed or partitioned away, the status is rejected
Message status is carried in the message acceptance record (
Figure 2) of every packet, and processes learn the status of
messages by processing this information
The acceptance criteria is a multiple part record that carries
Armstrong, Freier & Marzullo [Page 10]
RFC 1301 Multicast Transport Protocol February 1992
rules of agreement to determine the message acceptance. The
significant 8 bits is a flag that, if not zero,
synchronization is required. The field may vary on a per
basis as directed by producing transport's client. The default
that no synchronization is required
The second part of the record is a 12 element vector that
the status of the last 12 messages transmitted into the web
0 7 8 15 16 23 24 31
---------------------------------------------------------
| | |
| synchro | tri-state bitmask[12] |
---------------------------------------------------------
| message | packet sequence |
| sequence number | number |
---------------------------------------------------------
Figure 2. Message acceptance
Each element of the array is two bits in length and may have one
three values: accepted(0), pending(1) or rejected(2). Initially,
bit mask is set to all zeros. When the token for message m
transmitted, the first (left-most) element of the vector
the the state of message m - 1, the second element of the vector
the status of message m - 2, and so forth. Therefore the status
the last 12 messages are visible, the status of older messages
lost, logically by shifting the elements out of the vector. Only
master is permitted to set the status of messages. The master is
permitted to shift a status of pending beyond the end of the vector
If that situation arises, the master must instead not confirm
token[request] until the oldest message can be marked as
rejected or accepted
Message sequence numbers are 16 bit unsigned values. The field
initialized to zero by the master when the transport is initialized
and incremented by one after each token is granted. Only the
is permitted to change the value of the message sequence number.
granted, that message sequence number is consumed and the state
the message must eventually become either accepted or rejected.
transmit tokens may be granted if the assignment of a
sequence number that would cause a value of pending to be
beyond the end of the status vector
Packet sequence numbers are unsigned 16 bit numbers assigned by
producing process on a per message basis. Packet sequence
start at a value of zero for each new message and are incremented
one (consumed) for each data packet making up the message.
Armstrong, Freier & Marzullo [Page 11]
RFC 1301 Multicast Transport Protocol February 1992
detecting missing packet sequence numbers must send a nak[request]
the appropriate producer to recover the missed data
Control packets always contain the message acceptance criteria with
synchronization flag set to zero (0x00), the highest message
number observed and a packet sequence number one greater
previously observed. Control packets do not consume any
numbers. Since control messages are not reliably delivered,
acceptance criteria should only be checked to see if they fall
the proper range of message numbers, relative to the current
number of the receiving station. The range of acceptable
numbers should be m-11 to m-13, inclusive, where m is the
message number
2.2.7.
Heartbeat is an unsigned 32 bit field that has the units
milliseconds. The value of heartbeat is shared by all members of
web. By definition at least one packet (either data, empty or
from the master) will be multicast into the web within
heartbeat period
2.2.8.
The allocation window (or simply window) is a 16 bit unsigned
that indicates the maximum number of data packets that can
multicasted by a member in a single heartbeat. It is the sum of
retransmitted and new data packets
2.2.9.
The retention field is a 16 bit unsigned value that is the number
heartbeats for which a producer must retain transmitted client
and state for the purpose of retransmission
2.3 Transport
Associated with each transport are logically three transport
access points (TSAP), logically formed by the concatenation of
network service access point (NSAP) and a transport
identifier. These TSAPs are the unknown TSAP, the web's
TSAP and each individual member's TSAP
2.3.1. Unknown transport
Stations that are just joining must use the multicast NSAP
with the transport, but are not yet aware of either the web'
multicast TSAP the master process' TSAP. Therefore, joining
Armstrong, Freier & Marzullo [Page 12]
RFC 1301 Multicast Transport Protocol February 1992
fabricate a temporary TSAP (referred to as a unknown TSAP) by using
connection identifier reserved to mean unknown (0x00000000).
join[confirm] message will be sourced from the master's TSAP and
include the multicast transport connection identifier in the
field. Those values must be extracted from the join[confirm]
remembered by the joining process
2.3.2. Web's multicast
The multicast TSAP is formed by logically concatenating the
NSAP associated with the transport creation and the
connection identifier returned in the data field of the join[confirm
packet. If more than one network is involved in the web, then
multicast transport address becomes a list, one for each
represented. This list is supplied in the data field
token[confirm] packets
The multicast TSAP is used as the target for all messages that
destined to the entire web, such as data and empty. The master'
decision to abandon the transport (quit) is also sent to
multicast transport address
2.3.3. Member
The member TSAP is formed by using the process' unicast
concatenated with a locally generated unique connection identifier
That TSAP must be the source of every packet transmitted by
process, regardless of its destination, for the lifetime of
transport
Packets unicast to specific members must contain the
TSAP. For producers and consumers this is not difficult. The
TSAPs of interest are the master and the station(s)
transmitting data
3. Protocol
This section defines the expectations of the protocol implementation
These expectations should not be considered guidelines or hints,
rather part the protocol
3.1 Establishing a
Before any rendezvous can be affected, a process must first
an NSAP that will be the service access point for the
[3]. The process that first establishes at that NSAP is referred
as the master of the web. The decision as to what process acts as
master must be made a priori in order to guarantee
Armstrong, Freier & Marzullo [Page 13]
RFC 1301 Multicast Transport Protocol February 1992
creation in the face of network partitions. The process should make
robust effort to verify that the NSAP being used is not already
service. It may do so by repeatedly sending join[requests] to
web's unknown TSAP. If there is no response to repeated
the process may be relatively confident that the NSAP is not in
and proceed with the creation of the web. If not, the creation
be aborted and the situation reported to its client
3.1.1. Join
Additional members may join the web at any time after
establishment of the master by the joining process sending
join[request] to the unknown TSAP. The joining process should
already assigned a unique connection identifier to its
instantiation that will be used in the source TSAP of
join[request]. The join[request] must contain zeros in all of
acceptance fields. The heartbeat, window and retention parameters
filled in as requested by the transport provider's client. The
of the message must contain the type, class and quality of
parameters that the client has requested
field class
membership class master(0) There can be only a single
master, and that member has
privileges of a producer class
plus those acquitted only to
master
producer(1) A process that has producer
membership wishes to transmit
into the web as well as consume
consumer(2) A consumer process is a read
process. It will send naks in
to reliably receive data but
never ask for or be permitted to
possession of a transmit token
transport class reliable(0) Specifies a reliable transport, i.e.,
one that will generate and
naks. The implication is that
data will be reliably delivered
the failure will be detected
reported to the client
unreliable(1) The transport supports
Armstrong, Freier & Marzullo [Page 14]
RFC 1301 Multicast Transport Protocol February 1992
effort delivery. Such a transport
still fail if the error rates are
high, but tolerable loss
corruption of data will be
[4].
transport type NxN(0) The transport will accept
processes with producing capability
1xN(1) A 1xN transport permits only a
producer whose identity
established a priori
The client's desire for minimum throughput (expressed in
per second) is the lowest value that will be accepted.
throughput is calculated using the heartbeat and window parameters
the transport, and the maximum data unit size, not by
actual traffic. Any member that suggests a combination of
parameters that result in an unacceptable throughput will be
or asked to withdraw from the web
A joining client may also suggest a maximum data unit size.
field is expressed as a number of bytes that can be included in
data packet as client data
If no response is received in a single heartbeat, the join[request
should be retransmitted using the same source TSAP so the master
detect the difference between a new process and a retransmission of
join[request].
Armstrong, Freier & Marzullo [Page 15]
RFC 1301 Multicast Transport Protocol February 1992
3.1.2. Join confirm/
Only the master of the web will respond to join[request].
response may either permit the entry of the new process or deny it
The request to join may be denied because the new member
specifying service parameters that are in conflict with
established by the master. If the join is confirmed
join[confirm] will be unicast by the master with a data field
contains the web's current operating parameters. If those
are unacceptable to the joining process it may decide to
from the web. Otherwise the parameters must be accepted as
current operating values
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| member | transport | transport | | |
| class | class | type | reserved | |
----------------------------------------------------------
| minimum | maximum data |
| throughput | unit size |
---------------------------------------------------------- |
| multicast connection | |
| identifier | |
---------------------------------------------------------- -----
Figure 3. join
The join[confirm] will also contain the multicast
identifier. This must be used to form the TSAP that will be
destination for all multicast messages for the transport. The
Armstrong, Freier & Marzullo [Page 16]
RFC 1301 Multicast Transport Protocol February 1992
of the join[confirm] message will be the master's TSAP and must
recorded by the member for later use
The master must be in possession of all the transmit tokens when
sends a join[confirm]. Requiring the master to have the
tokens insures that the joining member will enter the web and
only complete messages. It also permits a notification of
master's client of the join so that application state may
automatically sent to the newly joining member. The newly
member may be on a network not previously represented in the web'
membership, thus requiring a new multicast TSAP be added to
existing list. The entire list will be conveyed in the data field
all subsequent token[confirm] messages (described later).
3.2 Maintaining data
The transport is responsible for maintaining the consistency of
data submitted for delivery by producing clients. The actual
data, while representing the bulk of the information that
through the web, is accompanied by significant amounts of
state information. In addition to the state information
with the client data, there is a minimum amount of protocol
that are purely for use by the transport, invisible to the
client
3.2.1. Transmit
Before any process may transmit client data or state it must
possess a transmit token. It may acquire the token by transmitting
token[request] to the master. Requests should be unicast to
master's TSAP and should be retransmitted at intervals
equal to the heartbeat. Since it is the central source for a
token, the master may apply some fairness algorithms to the
of permission to transmit. At a minimum the requests should be
in a first in, first out order. Duplicate requests from a
member should be ignored, keeping instead the first
request. When appropriate, the master will send a member with
request pending a token[confirm]. The data field of the
contains all the multicast TSAPs that are represented in the
web at that point in time
If the master detects no data or heartbeat messages being
into the web it will assume the token is lost, presumably because
member holding the token has failed or has become partitioned
from the master. In such cases, the master may attempt to confirm
state of the process (perhaps by sending isMember[request]). If
member does not respond it is removed from the active members of
web, the message is marked as rejected, the token is assumed by
Armstrong, Freier & Marzullo [Page 17]
RFC 1301 Multicast Transport Protocol February 1992
master
Figure 4 shows a timing diagram of a token pass. Increasing time
towards the bottom of the figure. In this figure, process A has
token, and process B requests a token when there are no free tokens
A master
"A" multicasts data | | "B"
|\ | | transmit
| \ | /|
| \ | / |
| \ | / |
"A" multicasts data | \ | / | "B"
w/eom set |\ \| / | token
| \ \V /|
| \ |\ / |
| \ | V / |
| \ | / |
| \| / |
| \V |
| |\ |
| | V |
| |\ | Master
| | \ | token to "B
| | \ |
| | \ |
| | \ |
| | V
| | |
| | /| "B"
| | / |
| | / |
| | / |
| | / |
| |/ |
| / |
| /| |
| V | |
| | |
Figure 4. Acquiring the
Token packets, like other control packets, do not consume
numbers. Hence, the master must be able to use another mechanism
determine whether multiple token[request] from a single member
actually requests for a separate token, or are a retransmission of
token[request]. To carry out this obligation, the master and
members must have an implicit understanding of each other's state
Armstrong, Freier & Marzullo [Page 18]
RFC 1301 Multicast Transport Protocol February 1992
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| | |
| TSAPs of all networks |
| represented in the web |
| membership |
| | |
| | |
---------------------------------------------------------- -----
Figure 5. token
Assume that the token, as viewed by the master, has three states
idle The token is not currently assigned. Specifically
message number that it defines is not represented in
current message acceptance vector
pending The token has been assigned by the master via
token[confirm] packet, but the master has not yet
any data packets to indicate that the from the
member received the notification
busy The token has been assigned and the master has seen
packets carrying the assigned message number. The
comprised by those packets is still represented in
message acceptance vector
Furthermore, a token that is not idle also has associated with
Armstrong, Freier & Marzullo [Page 19]
RFC 1301 Multicast Transport Protocol February 1992
state the TSAP of the process that owns (or owned) the token
Based on this state, the master will respond to any process that
a token in pending state with a reassignment of that token. This
based on the assumption that the original token[confirm] was
received by the requesting process. The only other possibility
that the process did receive the token and transmitted data
using that token, but the master did not see them. But data
are by design multi-packet messages, padded with empty packets
necessary. The possibility of the master missing all of the
of a message is considered less than the possibility of
requesting process missing a single token[confirm] packet
The process requesting tokens must consider the actions of the
and what prompted them. In most cases the assumptions made by
master will be correct. However, there are two ambiguous situations
There is the situation that the master is most directly addressing
not knowing whether the requesting process has failed to observe
token[confirm] or the master has failed to see data
transmitted by the producing process. There is also the
that the requesting process timed out too quickly and
retransmission of the token[request] passed the token[confirm] in
night. In any case the producing process may find itself
possession of a token for which it has no need. These can
dismissed by sending an empty[cancel] packet
Another possibility is that the requesting process has actually
use of the assigned token and is requesting another token. Unless
master has observed data using the token, the master will
consider the token pending. Therefore, a process that receives
duplicate token[confirm] should interpret it as a nak and
any data packets previously sent using the token's message
number
3.2.2. Data
Data is provided by the transport client in the form of
bytes. The bytes are encapsulated in packets immediately
the protocol's fixed overhead fields. The packet may have any
of data bytes between zero and the maximum number of bytes of
network protocol packet minus the network overhead and the
transport overhead. Every packet that consumes a sequence
must contain either client data or client state transitions such
the end of message indicator or a subchannel transition
Packets are transmitted in bursts of packets called windows.
protocol guarantees that no more than the current value of
data packets will be transmitted by a single process during
Armstrong, Freier & Marzullo [Page 20]
RFC 1301 Multicast Transport Protocol February 1992
heartbeat. Every packet transmitted always contains the
heartbeat, window and retention information. If full packets
unavailable [5], empty[dally] messages should be transmitted instead
The only packets that will be transmitted containing less
maximum capacity will be data[eom] or those containing
subchannel transitions
Armstrong, Freier & Marzullo [Page 21]
RFC 1301 Multicast Transport Protocol February 1992
----- | |
| |\ |
| | \ |
|\ \ |
heartbeat | \ \ |
|\ \ \ |
| | \ \ V| data(n
| | \ \ |
----- | \ V| data(n+1)
|\ \ |
| \ V| data(n+w-1) w/
|\ \ |
| \ \ |
|\ \ \ |
| \ \ V| data(n+w
| \ \ |
----- | \ V| data(n+w+1)
|\ \ |
| \ V| data(n+2w-1) w/
w = window = 3 | \ |
r = retention = 2 | \ |
| \ |
| V| empty(n+2w
| |
----- | |
|\ |
| \ |
| \ |
| \ |
| \ |
| V| data(n+2w) w/
| | Packets n..n+w-1 are released
----- | | token is surrendered
| |
| |
| |
| |
| |
| |
| |
----- | | Packets n+w..n+2w-1 are released
Figure 6. Normal data
Figure 6 shows a timing diagram of a process transmitting into a
(without any complicating naks). Increasing time is towards
bottom of the figure. The transmitting process is obligated
Armstrong, Freier & Marzullo [Page 22]
RFC 1301 Multicast Transport Protocol February 1992
retransmit requested packets for at least retention
intervals after their first transmission
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| uninterpreted data |
| |
| |
| | |
---------------------------------------------------------- -----
Figure 7. data
3.2.3. Empty
An empty packet is a control packet multicast into the web at
intervals by a producer possessing a transmit token when no
data is available. Empty packets are sent to maintain
and to advertise the maximum sequence number of the producer.
provides the opportunity for consuming processes to detect
request retransmission of missed data as well as identifying
owner of a transmit token
Armstrong, Freier & Marzullo [Page 23]
RFC 1301 Multicast Transport Protocol February 1992
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
Figure 8. empty
There are two situations where the empty[dally] packet is used.
first is when there is insufficient data for a full packet
by the client during a heartbeat. Partial packets should not
transmitted unless there is a client transition to be conveyed,
something must be transmitted during a heartbeat or the master
think the process owning a transmit token has failed. Empty[dally]
used instead of a data packet until the client provides
data to fill a packet or indicates a state transition such as an
of message or subchannel transition
The second situation where empty[dally] is used is after
transmission of short messages. Each message should consist
multiple packets in order to enhance the possibility that
will observe at least one packet of a message and therefore be
to identify the producer. The transport parameter retention
approximately the correct properties for that insurance. Therefore,
message must consist of at least retention packets. If the
data does not require that many packets, empty[dally] packets must
appended. A process that has no transmittable data and is
possession of a transmit token must send an empty[cancel].
Transmissions of empty[cancel] packets pass the ownership of
transmit token back to the master. When the master observes
control packet, it will mark the referenced to message as rejected
that other consumers do not believe the message lost and attempt
recover
Armstrong, Freier & Marzullo [Page 24]
RFC 1301 Multicast Transport Protocol February 1992
During periods of no activity (i.e., after all messages have
either accepted or rejected and there are no outstanding
tokens) the master may enter hibernation mode by
empty[hibernate] packets. In that mode the master will increase
value of the transport parameter heartbeat in order to reduce
traffic. Such packets are used to indicate that the packet'
heartbeat field should not be used for resource computation by
processes that observe it
Armstrong, Freier & Marzullo [Page 25]
RFC 1301 Multicast Transport Protocol February 1992
3.2.4. Missed
The most common method of detecting data loss will be the
of a data or a heartbeat message that has a sequence number
than expected from that producer. The second most common method
be a message fragment (missing the end of message) and seeing no
data or empty packets from the producer of the fragment for more
a single heartbeat. In any case the consumer process directs
negative acknowledgment (nak) to the producer of the
message. The data field of the nak message contains a list
ascending sequence number pairs the consumer needs to recover
missed data
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | | |
| message sequence (low) | packet sequence (low) |
----------------------------------------------------------
| | |
| message sequence (high) | packet sequence (high) | |
---------------------------------------------------------- -----
Figure 9. nak
3.2.5. Retrying
Operations must be retried in order to assure that a single
loss does not cause transport failure. In general the right
to do that with exist in the transport. The proper interval
retries is the transport's time constant or heartbeat. The
Armstrong, Freier & Marzullo [Page 26]
RFC 1301 Multicast Transport Protocol February 1992
number of retries is retention
Operations that are retriable (and represented by their
message types) are join, nak, token, isMember and quit.
application for the heartbeat and retention is when
empty messages. Empty[dally] messages are transmitted any time
is not available but the data[eom] has not yet been sent. Any
not observing data or empty for more than retention
intervals will assume to have failed or partitioned away and
transport will be abandoned
3.2.6.
If the producer receives a nak[request] from a consumer
requesting the retransmission of a packet that is no
available, the producer must send a nak[deny] to the source of
request. If that puts the consumer in a failed state, the
will initiate the withdrawal from the web. If a producer receives
nak[request] from a consumer requesting the retransmission of one
more packets, those packets will be multicast to the entire web [6].
All will contain the original client information (such as
and end of message state) and message and packet sequence number
However, the retransmitted packets must contain updated
parameter information (heartbeat, window and retention).
Retransmitted packets are subject to the same constraints
heartbeat and window as original transmissions. Therefore
producer's retransmissions consume a portion of the allocation
allowing less new data to be transmitted in a single heartbeat
Retransmitted packets have priority over (i.e., should be
before) new data packets
Armstrong, Freier & Marzullo [Page 27]
RFC 1301 Multicast Transport Protocol February 1992
----- | | retransmission count = rx=0
| |\ |
| | \ |
| |\ \ |
| | \ \ |
| |\ \ \ |
| | \ \ V| data(n
| | \ \ |
| \ *| data(n+1)
heartbeat | \ |
| V| data(n+w-1-rx) w/eow rx=0
| | |
| | /| nak(n') of n+1
| | / |
| | / |
| | / |
| | / |
| |V |
----- | |
|\ |
| \ |
|\ \ |
| \ \ |
|\ \ \ |
w = window = 3 | \ \ *| retransmission(n+1) rx=1
r = retention = 1 | \ \ |
| \ V| data(n+w
| \ |
| V| data(n+2w-1-rx) w/eow rx=1
| |
| /| nak(n') of n+1
| / |
----- | / |
|\ / |
| / |
|V \ |
|\ \ |
| \ \ |
|\ \ V| data(n+2w-rx) rx=1
| \ \ | Packets n..n+w-1-0 can be released
| \ \ |
| \ V| nak deny(n+1) rx=2
| \ |
| V| data(n+3w-1-rx) w/eom rx=2
| |
----- | | Packets n+w..n+2w-1-1 are released
Figure 10. naks and
Armstrong, Freier & Marzullo [Page 28]
RFC 1301 Multicast Transport Protocol February 1992
3.2.7. Duplicate
The consumer must be prepared to ignore duplicate packets received
They will invariably be the result of the producer's
in response to another consumer's nak
3.2.8.
If at any time a process detects another in violation of the
it may ask the offending process to withdraw from the web
unicasting to it a quit[request] that has the target field set to
value of the offender's TSAP. Any member that exhibits a
and recoverable protocol violation and still responds willingly
the quit[request] will be noted as having truly correct
behavior
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
----------------------------------------------------------
| |
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| |
| target TSAP |
| |
----------------------------------------------------------
Figure 11. quit
3.3 Terminating the
Transport termination is an advisory process that may be initiated
any member of the web. No process should intentionally quit the
while it has retransmittable data buffered. Stations should
Armstrong, Freier & Marzullo [Page 29]
RFC 1301 Multicast Transport Protocol February 1992
every reasonable attempt advise the master of their intentions
withdraw, as their departure may collapse the topology of the web
eliminate the need to carry multicast messages across
boundaries
3.3.1. Voluntary
Voluntary quit[requests] are unicast to the master's TSAP. When
master receives a quit from a member of the web, it responds with
quit[confirm] packet. At that time the member will be
removed from the web. The request should be retransmitted
heartbeat intervals until the confirmation is received from
master or as many times as the web's value of retention
3.3.2. Master
If the master initiates the transport termination it effects
members of the web. The master will retain all transmit tokens
refuse to assign them. Once the tokens are acquired, the master
multicast a quit[request] to the entire web. That request should
acknowledged by every active member. When the master receives
confirmations for retention transmissions, it may assume every
has terminated its transport and then may follow suit
3.3.3.
If the master receives any message other than a join[request] from
member that it does not recognize, it should transmit a quit[request
with that process as a target. This covers cases where the
did not see the termination reply and retransmitted its original
request, as well as unannounced and rejected consumers
3.4 Transport
The following section provides guidelines and rationale for
reasonable transport quality of service parameters. It also
some of the reasoning behind the ranges of values presented
3.4.1. Quality of
Active members of the web may suggest changes in the transport'
quality of service parameters during the lifetime of the transport
Producers in general adjust the transport's parameters to encourage
higher level of throughput. Since consumers are responsible
certifying reliable delivery, it is expected that they will
the force encouraging more reliability and stability. Both are
to optimize the quality of service. The negotiation that took
when members joined the web included the clients' desires
Armstrong, Freier & Marzullo [Page 30]
RFC 1301 Multicast Transport Protocol February 1992
regards to the worst case behavior that will be tolerated. If
member cannot maintain the negotiated lower bound, it may asked
withdraw from the web. That process will be sent a unicast
(quit[request]) indicating that it should retire. There
essentially three parameters maintained by the transport that
the client's quality of service requirements: heartbeat, window
retention. These three parameters can be adapted by the transport
reflect the capability of the members, the type of application
supported and the network topology. When members join the web,
suggest values for the quality of service parameters to the master
If the parameters are acceptable, the master will respond with
web's current operating values. During the lifetime of the web, it
expected that the parameters be modified by its members, though
may never result in a quality of service less than the lower
established by the joining procedure. Producers may try to
performance by reducing the heartbeat interval and increasing
window size. This will have the effect of increasing the
committed to the transport at any time. In order to keep
resources under control, the producer may also reduce the retention
Consumers must rely on their clients to consume the data
the resources of the transport. To do so the consumer
implementation must monitor the level of committed resources
insure that it does not exceed its capabilities. Since MTP is a
based protocol, the consumer is required to tell the producer if
change in parameters is required. The new information must
delivered to the producer(s) before the consumer's resource
becomes critical in order to avoid missing data
For more stable operation, consumers would try to extend
heartbeat interval and reduce the window. To a certain degree,
could also attempt to reduce the value of retention in order
reduce the amount of resources required to support the transport
However, that requires a more stringent real-time capability
3.4.2. Selecting parameter
The value of heartbeat is approximately the transport time constant
Assuming that the transport can be modelled as a closed loop
function, reaction to feedback into the transport should settle
in three time constants. In a transport that is constrained to
single network, the dominant cause of processing delay of
transport will most likely be page fault resolution time
For example, using a one MIP processor on a ethernet and an
standard disk, the worst case page fault resolution requiring
seeks (one to write out a dirty page, another to swap in the
page) and an average seek time of 40 milliseconds, page
Armstrong, Freier & Marzullo [Page 31]
RFC 1301 Multicast Transport Protocol February 1992
resolution should be less than 80 milliseconds. Allowing for
additional overhead and scheduling delays, two times the worst
page fault resolution time would appear to be the minimum
transport time constant one could expect. So
Heartbeat (minimum) = 160 - 200 milliseconds
The transmit time for a full (ethernet) packet is approximately 1.2
milliseconds. Processing time should be less than 3
(ignoring possible overlapped processing). Assuming disk access (
no faulting) is equivalent, and the total time per packet is the
of the parts, or 8.4 milliseconds. Therefore, the theoretical
value would be approximately 17 packets per heartbeat. The
should be capable of approximately 120 packets per second, or 19.2
packets per heartbeat
Window (maximum) = 17 - 20 packets per heartbeat
The (theoretical) throughput with these parameters in effect is 180
kilobytes per second
Reducing retention may introduce instability because the
will have less opportunity to react to missing data. Data can
missed for a variety of reasons. If constrained to the local net
data lost due to data link corruption should be in the
of one packet in every 50,000 (bit error rate of approximately 10-9).
Telephony links (between routers, for instance) exhibit
characteristics. Several orders of magnitude more packets are lost
receiving processes, including packet switch routers, than over
physical links. The losses are usually a result of congestion
resource starvation at lower layers due to the processing of (nearly
back to back packets. The incidental packet loss of this type
virtually unavoidable. One can only require that a receiving
be capable of receiving some number of back to back
successfully, and that number must be at least greater then the
of window. And beyond that the probability of success can be made
close to unity as required by providing the receiver the
to observe the data multiple times
The receiving process must detect packet loss. The simplest method
to notice gaps in the received message/packet sequence numbers.
detection should be done after receiving an end of window or
state transition indication. As such, the naks cannot be transmitted
let alone received, until the following heartbeat. In order to
have any single packet loss cause transport failure, the naks
have the opportunity to be transmitted at least twice
When the loss is detected, the nak must be transmitted and should
Armstrong, Freier & Marzullo [Page 32]
RFC 1301 Multicast Transport Protocol February 1992
received at the producing process in less than two heartbeats
the data it references was transmitted. Again, it is the
time that dominates, not the transmission of the nak
Retention (minimum) = 3.
The resources committed to a producing transport using the
assumptions are buffers sufficient for 80 packets of 1500 bytes each
Each buffer will be committed for 600 - 800 milliseconds
Transports that span multiple networks have unique problems. One
problem is that if a router drops a packet, all the processes on
remote network may attempt to send a nak[request] at the same time
That is not likely to enhance the router's quality of service
Furthermore, it is obvious that any one nak[request] will suffice
prompt the producer to retransmit the desired packet. To reduce
number of nak[requests] in this situation, the following scheme
be employed
First, extend the value of retention to a minimum value of N.
use a randomizing function that returns a value between zero and N -
2, choose how many heartbeat intervals to dally before sending
nak[request], thus spreading out the transmissions over time.
order for the method to be meaningful, the minimum value of
must be adjusted
Retention (minimum) = 5 (for internet cases
3.4.3. Caching member
In order to reduce transport member interaction and to
performance, a certain amount of caching should be employed
producing members. These caches may be filled by gleaning
from reliable sources such as multicast data or, when all else fails
from responses solicited from the web's master by use of
isMember[request]. IsMember[request] requests are unicast to a
that is believed to have an accurate state of the web, at least
the degree that it can answer the question posed. The destination
such a message is usually the master. But in cases where a
(such as the master) wants to verify that a process believes
to be valid, it can assign the target TSAP and the destination to
the same. It is assumed that every process can verify itself
If the member receiving the isMember[request] can confirm
target's active membership status in the web, it responds with
unicast isMember[confirm]. The data field contains the
value of the confirmation, that is the time (in milliseconds)
the information was confirmed from a reliable source
Armstrong, Freier & Marzullo [Page 33]
RFC 1301 Multicast Transport Protocol February 1992
Caches are risky as the information stored in them can become stale
Consequently, with only a few exceptions, the entries should be aged
and when sufficiently old, discarded. Ideally they may be renewed
the same gleanable sources alluded to in the previous paragraph.
not, they are simply discarded and refilled when needed
Web membership may be gleaned from any packet that does not have
value of unknown as the destination connection identifier.
producing transport may extract the TSAP from such packets and
create or refresh local caches. Then, if in the process
transmitting and NAK is received from one of the members
identity is cached, no explicit request will be needed to verify
source's membership
The explicit source of membership information is the master
Information can be requested by using the isMember message
Information gathered in that manner should be treated the same
gleaned information with respect to aging
The aging is a function of the transport's time constant,
heartbeat, and the retention. Information about a producing
must be cached at least as long as that producer has
messages. It may be cached longer. The namespace for both
numbers and connection identifiers is intentionally long to
that reuse of those namespaces will not likely collide
A. Appendix: MTP as an Internet Protocol
MTP is a transport layer protocol, designed to be layered on top of
number of different network layer protocols. Such a protocol
provide certain facilities that MTP expects. In particular,
underlying network level protocol must provide "ports" or "sockets
to facilitate addressing of processes within a machine, and
mechanism for multicast addressing of datagrams. These
addressing facilities are also used to formulate the NSAP for MTP
IP
A.1 Internet Protocol multicast
MTP on Internet Protocol uses the Internet Protocol
mechanisms defined in RFC 1112, "Host Extensions for
Multicasting". MTP requires "Level 2" conformance described in
paper, for hosts which need to both send and receive
packets, both on the local net and on an internet. MTP on
Protocol uses the permanent host group address 224.0.1.9.
Armstrong, Freier & Marzullo [Page 34]
RFC 1301 Multicast Transport Protocol February 1992
A.2
The Internet Protocol does not provide a port mechanism - ports
defined at the transport level instead. In order to encapsulate
packet within Internet Protocol packets, a simple convergence
"bridge" protocol must be defined to run on top of Internet Protocol
which will provide MTP with the mechanism needed to deliver
to the proper processes. We will call this protocol
"MTP/Internet Protocol Bridge Protocol", or just "Bridge".
protocol header is encapsulated the Internet Protocol data -
protocol field of the Internet Protocol packet carries the
indicating this packet is an MTP packet (92 decimal). The MTP
itself is encapsulated in the Bridge data. Figure A.1 shows
positions of the fields within the MTP packet while table A.1
the contents of those fields
A.3 Fields of the bridge
0 7 8 15 16 23 24 31
----------------------------------------------------------
| | |
| destination port | source port |
----------------------------------------------------------
| | |
| length | checksum |
----------------------------------------------------------
| |
| client data |
----------------------------------------------------------
Figure A.1 MTP bridge protocol header
destination port The port to which the packet is destined or sinked
source port The port from which the packet originates or is sourced
length The length in octets of the bridged packet,
header and all data (the MTP packet). The minimum
in this field is 8, the maximum is 65535. The
does not include any padding bytes that were used
compute the checksum. Note that though this field
for very long packets, most networks have
shorter maximum frame sizes - the allowable and
packet size must be determined by means beyond the
of this specification
checksum The 16 bit one's compliment of the one's compliment
of the entire bridge protocol header and data,
Armstrong, Freier & Marzullo [Page 35]
RFC 1301 Multicast Transport Protocol February 1992
with a zero octet (if necessary) to make multiple 16
quanities. A computed checksum of all zeros should
changed to all ones. The checksum field is optional -
all zeros in the field indicate that checksums are not
use
data The data field is the field that carries the
transport data. A single MTP packet will be carried
data field of each bridge packet
A.4 Relationship to other Internet Protocol
The astute reader might note that the MTP/Bridge Protocol looks
like the User Datagram Protocol (UDP). UDP itself was not
because the protocol field in the Internet Protocol packet
reflect the fact that the higher level protocol of interest is MTP
AFM91 Armstrong, S., A. Freier and K. Marzullo, "MTP: An
Multicast Transport Protocol", Xerox Webster Research
technical report X9100359, March 1991.
Bog83 Boggs, D., "Internet Broadcasting", Xerox PARC
report CSL-83-3, October 1983.
BSTM79 Boggs, D., J. Shoch, E. Taft, and R. Metcalfe, "Pup:
Internetwork Architecture", IEEE Transactions
Communications, COM-28(4), pages 612-624. April 1980.
DIX82 Digital Equipment Corp., Intel Corp., Xerox Corp., "
Ethernet, a Local Area Network: Data Link and Physical
Specifications", September 1982.
CLZ87 Clark, D., M. Lambert, and L. Zhang, "NETBLT: A
throughput transport protocol", In Proceedings of ACM
'87 Workshop, pages 353-359, 1987.
CM87 Chang J., and M. Maxemchuck. "Atomic broadcast",
Transactions on Computer Systems, 2(3):251-273, August 1987.
Cri88 Cristian, F., "Reaching agreement on processor
membership in synchronous distributed systems",
Proceedings of the 18th International Conference on Fault
Tolerant Computing. IEEE TOCS, 1988.
Dee89 Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
Armstrong, Freier & Marzullo [Page 36]
RFC 1301 Multicast Transport Protocol February 1992
Fre84 Freier, A., "Compatability and interoperability", Open
to XNS Interest Group, Xerox Systems Developement Division
December 13, 1984.
JB89 Joseph T., and K. Birman, "Reliable Broadcast Protocols",
pages 294-318, ACM Press, New York, 1989.
Pos81 Postel, J., "Transmission Control Protocol - DARPA
Program Protocol Specification", RFC 793, DARPA,
1981.
Xer81 Xerox Corp., "Internet Transport Protocols", Xerox
Integration Standard 028112, Stamford, Connecticut.
1981.
[1] The network layer is not specified by MTP. One of the goals is
specify a transport that can be implemented with equal
on many network architectures
[2] There's only one such multicast connection identifier per web.
there are multiple processes on the same machine participating in
web, the transport must descriminate between those processes by
the connnection identifier
[3] Determining the network service access point (NSAP) for a
instantiation of a web is not addressed by this protocol.
document may define some policy, but the actual means are left
other mechanisms
[4] Best effort delivery is also known as highly reliable delivery
It is somewhat unique that the qualifying adjective highly
the definition of reliable in this context
[5] The resource being flow controlled is packets carrying
data. Consequently, full data units provide the greatest efficiency
[6] There seems to be an opportunity to suppress retransmissions
networks that were not represented in the set of naks received
Security
Security issues are not discussed in this memo
Armstrong, Freier & Marzullo [Page 37]
RFC 1301 Multicast Transport Protocol February 1992
Authors'
Susan M.
Xerox Webster Research
800 Phillips Rd. MS 128-27
Webster, NY 14580
Phone: (716) 422-6437
EMail: armstrong@wrc.xerox.
Alan O.
Apple Computer, Inc
20525 Mariani Ave. MS 3-
Cupertino, CA 95014
Phone: (408) 974-9196
EMail: freier@apple.
Keith A.
Cornell
Department of Computer
Upson
Ithaca, NY 14853-7501
Phone: (607) 255-9188
EMail: marzullo@cs.cornell.
Keith Marzullo is supported in part by the Defense
Research Projects Agency (DoD) under NASA Ames grant number
2-593, Contract N00140-87-C-8904. The views, opinions
findings contained in this report are those of the authors
should not be construed as an official Department of
position, policy, or decision
Armstrong, Freier & Marzullo [Page 38]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
