rfc1301.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,474 行 · 第 1/5 页
TXT
1,474 行
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 |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| | |
| | |
| (data content and format |
| dependent on packet type | data
| and modifier) | fields
| |
| | |
| | |
| | |
---------------------------------------------------------- -----
Figure 1. MTP packet format
Armstrong, Freier & Marzullo [Page 6]
RFC 1301 Multicast Transport Protocol February 1992
2.2.1. Protocol version
The first 8 bits of the packet are the protocol version number. This
document describes version 1 of the Multicast Transport Protocol and
thus the version field has a value of 0x01.
2.2.2. Packet type and modifier
The second byte of the header is the packet type and the following
byte contains the packet type modifier. Typical control message
exchanges are in a request/response pair. The modifier field
simplifies the construction of responses by permitting reuse of the
incoming message with minimal modification. The following table gives
the packet type field values along with their modifiers. The
modifiers are valid only in the context of the type. In the prose of
the definitions and later in the document, the syntax for referring
to one of the entries described in the following table will be
type[modifier]. For example, a reference to data[eow] would be a
packet of type data with an end of window modifier.
type modifier description
data(0) data(0) The packet is one that contains user
information. Only the process possessing a
transmit token is permitted to send data
unless specifically requested to retransmit
previously transmitted data. All packets of
type data are multicast to the entire web.
eow(1) A data packet with the eow (end of window)
modifier set indicates that the transmitter
intends to send no more packets in this
heartbeat either because it has sent as many
as permitted given the window parameter or
simply has no more data to send during the
current heartbeat. This is not client
information but rather a hint to be used by
transport providers to synchronize the
computation and transmission of naks.
eom(2) Data[eom] marks the end of the message to the
consumers, and the surrendering of the
transmit token to the master. And like a
data[eow] a data[eom] packet implies the end
of window.
nak(1) request(0) A nak[request] packet is a consumer
requesting a retransmission of one or more
Armstrong, Freier & Marzullo [Page 7]
RFC 1301 Multicast Transport Protocol February 1992
data packets. The data field contains an
ordered list of packet sequence numbers that
are being requested. Naks of any form are
always unicast.
deny(1) A nak[deny] message indicates that the
producer source of the nak[deny]) cannot
retransmit one or more of the packets
requested. The process receiving the
nak[deny] must report the failure to its
client.
empty(2) dally(0) An empty[dally] packet is multicast to
maintain synchronization when no client data
is available.
cancel(1) If a producer finds itself in possession of a
transmit token and has no data to send, it
may cancel the token[request] by multicasting
an empty[cancel] message.
hibernate(2) If the master possesses all of the web's
transmit tokens and all outstanding messages
have been accepted or rejected, the master
may transmit empty[hibernate] packets at a
rate significantly slower than indicated by
the web's value of heartbeat.
join(3) request(0) A join[request] packet is sent by a process
wishing to join a web to the web's unknown
TSAP (see section 2.2.5).
confirm(1) The join[confirm] packet is the master's
confirmation of the destination's request to
join the web. It will be unicast by the
master (and only the master) to the station
that sent the join[request].
deny(2) A join[deny] packet indicates permission to
join the web was denied. It may only be
transmitted by the master and will be unicast
to the member that sent the join[request].
quit(4) request(0) A quit[request] may be unicast to the master
by any member of the web at any time to
indicate the sending process wishes to
withdraw from the web. Any member may unicast
a quit to another member requesting that the
Armstrong, Freier & Marzullo [Page 8]
RFC 1301 Multicast Transport Protocol February 1992
destination member quit the web due to
intolerable behavior. The master may
multicast a quit[request] requiring that the
entire web disband. The request will be
multicast at regular heartbeat intervals
until there are no responses to retention
requests.
confirm(1) The quit[confirm] packet is the indication
that a quit[request] has been observed and
appropriate local action has been taken.
Quit[confirm] are always unicast.
token(5) request(0) A token[request] is a producing member
requesting a transmit token from the master.
Such packets are unicast to the master.
confirm(1) The token[confirm] packet is sent by the
master to assign the transmit token to a
member that has requested it. token[confirm]
will be unicast to the member being granted
the token.
isMember(6) request(0) An isMember[request] is soliciting
verification that the target member is a
recognized member of the web. All forms of
the isMember packet are unicast to a specific
member.
confirm(1) IsMember[confirm] packets are positive
responses to isMember[requests].
deny(2) If the member receiving the isMember[request]
cannot confirm the target's membership in the
web, it responds with a isMember[deny].
2.2.3. Subchannel
The fourth byte of the transport header contains the client's
subchannel value. The default value of the subchannel field is zero.
Semantics of the subchannel value are defined by the transport client
and therefore are only applicable to packets of type data. All other
packet types must have a subchannel value of zero.
2.2.4. Source connection identifier
The source connection identifier field is a 32 bit field containing a
transmitting system unique value assigned at the time the transport
Armstrong, Freier & Marzullo [Page 9]
RFC 1301 Multicast Transport Protocol February 1992
is created. The field is used in identifying the particular transport
instantiation and is a component of the TSAP. Every packet
transmitted by the transport must have this field set.
2.2.5. Destination connection identifier
The destination connection identifier is the 32 bit identifier of the
target transport. From the point of view of a process sending a
packet, there are three types of destination connection identifiers.
First, there is the unknown connection identifier (0x00000000). The
unknown value is used only as the destination connection identifier
in the join[request] packet.
Second, there is the multicast connection identifier gleaned from the
join[confirm] message sent by the master. The multicast connection
identifier is used in conjunction with the multicast NSAP to form the
destination TSAP of all packets multicast to the entire web [2].
The last class of connection identifier is a unicast identifier and
is used to form the destination TSAP when unicasting packets to
individual members. Every member of the web has associated with it a
unicast connection identifier that is used to form its own unicast
TSAP.
2.2.6. Message acceptance
MTP ensures that all processes agree on which messages are accepted
and in what order they are accepted. The master controls this aspect
of the protocol by controlling allocation of transmit tokens and
setting the status of messages. Once a token for a message has been
assigned (see section 3.2.1) the master sets the status of that
message according to the following rules [AFM91]:
If the master has seen the entire message (i.e., has seen the
data[eom] and all intervening data packets), the status is accepted.
If the master has not seen the entire message but believes the
message sender is still operational and connected to the master (as
determined by the master), the status is pending.
If the master has not seen the entire message and believes the
sender to have failed or partitioned away, the status is rejected.
Message status is carried in the message acceptance record (see
Figure 2) of every packet, and processes learn the status of earlier
messages by processing this information.
The acceptance criteria is a multiple part record that carries the
Armstrong, Freier & Marzullo [Page 10]
RFC 1301 Multicast Transport Protocol February 1992
rules of agreement to determine the message acceptance. The most
significant 8 bits is a flag that, if not zero, indicates
synchronization is required. The field may vary on a per message
basis as directed by producing transport's client. The default is
that no synchronization is required.
The second part of the record is a 12 element vector that represents
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 record
Each element of the array is two bits in length and may have one of
three values: accepted(0), pending(1) or rejected(2). Initially, the
bit mask is set to all zeros. When the token for message m is
transmitted, the first (left-most) element of the vector represents
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?