rfc1301.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   |                                                        |      |
   |              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
   the the state of message m - 1, the second element of the vector is
   the status of message m - 2, and so forth. Therefore the status of
   the last 12 messages are visible, the status of older messages are
   lost, logically by shifting the elements out of the vector. Only the
   master is permitted to set the status of messages. The master is not
   permitted to shift a status of pending beyond the end of the vector.
   If that situation arises, the master must instead not confirm any
   token[request] until the oldest message can be marked as either
   rejected or accepted.

   Message sequence numbers are 16 bit unsigned values. The field is
   initialized to zero by the master when the transport is initialized,
   and incremented by one after each token is granted. Only the master
   is permitted to change the value of the message sequence number. Once
   granted, that message sequence number is consumed and the state of
   the message must eventually become either accepted or rejected. No
   transmit tokens may be granted if the assignment of a message
   sequence number that would cause a value of pending to be shifted
   beyond the end of the status vector.