rfc1301.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,474 行 · 第 1/5 页

   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.

   Packet sequence numbers are unsigned 16 bit numbers assigned by the
   producing process on a per message basis. Packet sequence numbers
   start at a value of zero for each new message and are incremented by
   one (consumed) for each data packet making up the message. Consumers



Armstrong, Freier & Marzullo                                   [Page 11]

RFC 1301              Multicast Transport Protocol         February 1992


   detecting missing packet sequence numbers must send a nak[request] to
   the appropriate producer to recover the missed data.

   Control packets always contain the message acceptance criteria with a
   synchronization flag set to zero (0x00), the highest message sequence
   number observed and a packet sequence number one greater than
   previously observed. Control packets do not consume any sequence
   numbers.  Since control messages are not reliably delivered, the
   acceptance criteria should only be checked to see if they fall within
   the proper range of message numbers, relative to the current message
   number of the receiving station.  The range of acceptable sequence
   numbers should be m-11 to m-13, inclusive, where m is the current
   message number.

2.2.7.  Heartbeat

   Heartbeat is an unsigned 32 bit field that has the units of
   milliseconds. The value of heartbeat is shared by all members of the
   web. By definition at least one packet (either data, empty or quit
   from the master) will be multicast into the web within every
   heartbeat period.

2.2.8.  Window

   The allocation window (or simply window) is a 16 bit unsigned field
   that indicates the maximum number of data packets that can be
   multicasted by a member in a single heartbeat. It is the sum of the
   retransmitted and new data packets.

2.2.9.  Retention

   The retention field is a 16 bit unsigned value that is the number of
   heartbeats for which a producer must retain transmitted client data
   and state for the purpose of retransmission.

2.3     Transport addresses

   Associated with each transport are logically three transport service
   access points (TSAP), logically formed by the concatenation of a
   network service access point (NSAP) and a transport connection
   identifier. These TSAPs are the unknown TSAP, the web's multicast
   TSAP and each individual member's TSAP.

2.3.1.  Unknown transport address

   Stations that are just joining must use the multicast NSAP associated
   with the transport, but are not yet aware of either the web's
   multicast TSAP the master process' TSAP. Therefore, joining stations



Armstrong, Freier & Marzullo                                   [Page 12]

RFC 1301              Multicast Transport Protocol         February 1992


   fabricate a temporary TSAP (referred to as a unknown TSAP) by using a
   connection identifier reserved to mean unknown (0x00000000). The
   join[confirm] message will be sourced from the master's TSAP and will
   include the multicast transport connection identifier in the data
   field. Those values must be extracted from the join[confirm] and
   remembered by the joining process.

2.3.2.  Web's multicast address

   The multicast TSAP is formed by logically concatenating the multicast
   NSAP associated with the transport creation and the transport
   connection identifier returned in the data field of the join[confirm]
   packet. If more than one network is involved in the web, then the
   multicast transport address becomes a list, one for each network
   represented.  This list is supplied in the data field of
   token[confirm] packets.

   The multicast TSAP is used as the target for all messages that are
   destined to the entire web, such as data and empty. The master's
   decision to abandon the transport (quit) is also sent to the
   multicast transport address.

2.3.3.  Member addresses

   The member TSAP is formed by using the process' unicast NSAP
   concatenated with a locally generated unique connection identifier.
   That TSAP must be the source of every packet transmitted by the
   process, regardless of its destination, for the lifetime of the
   transport.

   Packets unicast to specific members must contain the appropriate
   TSAP.  For producers and consumers this is not difficult. The only
   TSAPs of interest are the master and the station(s) currently
   transmitting data.

3.      Protocol behavior

   This section defines the expectations of the protocol implementation.
   These expectations should not be considered guidelines or hints, but
   rather part the protocol.

3.1     Establishing a transport

   Before any rendezvous can be affected, a process must first acquire
   an NSAP that will be the service access point for the instantiation
   [3].  The process that first establishes at that NSAP is referred to
   as the master of the web. The decision as to what process acts as the
   master must be made a priori in order to guarantee unambiguous



Armstrong, Freier & Marzullo                                   [Page 13]

RFC 1301              Multicast Transport Protocol         February 1992


   creation in the face of network partitions. The process should make a
   robust effort to verify that the NSAP being used is not already in
   service. It may do so by repeatedly sending join[requests] to the
   web's unknown TSAP. If there is no response to repeated transmissions
   the process may be relatively confident that the NSAP is not in use
   and proceed with the creation of the web. If not, the creation must
   be aborted and the situation reported to its client.

3.1.1.  Join request

   Additional members may join the web at any time after the
   establishment of the master by the joining process sending a
   join[request] to the unknown TSAP. The joining process should have
   already assigned a unique connection identifier to its transport
   instantiation that will be used in the source TSAP of the
   join[request]. The join[request] must contain zeros in all of the
   acceptance fields. The heartbeat, window and retention parameters are
   filled in as requested by the transport provider's client. The data
   of the message must contain the type, class and quality of service
   parameters that the client has requested.


   field               class       definition

   membership class    master(0)   There can be only a single web
                                   master, and that member has all
                                   privileges of a producer class member
                                   plus those acquitted only to the
                                   master.

                       producer(1) A process that has producer class
                                   membership wishes to transmit data
                                   into the web as well as consume.

                       consumer(2) A consumer process is a read only
                                   process. It will send naks in order
                                   to reliably receive data but will
                                   never ask for or be permitted to take
                                   possession of a transmit token.

   transport class     reliable(0) Specifies a reliable transport, i.e.,
                                   one that will generate and process
                                   naks.  The implication is that the
                                   data will be reliably delivered or
                                   the failure will be detected and
                                   reported to the client.

                       unreliable(1)   The transport supports best



Armstrong, Freier & Marzullo                                   [Page 14]

RFC 1301              Multicast Transport Protocol         February 1992


                                   effort delivery. Such a transport may
                                   still fail if the error rates are too
                                   high, but tolerable loss or
                                   corruption of data will be permitted
                                   [4].

   transport type      NxN(0)      The transport will accept multiple
                                   processes with producing capability.

                       1xN(1)      A 1xN transport permits only a single
                                   producer whose identity was
                                   established a priori.

   The client's desire for minimum throughput (expressed in kilobytes
   per second) is the lowest value that will be accepted. That
   throughput is calculated using the heartbeat and window parameters of
   the transport, and the maximum data unit size, not by measuring
   actual traffic. Any member that suggests a combination of those
   parameters that result in an unacceptable throughput will be ignored
   or asked to withdraw from the web.

   A joining client may also suggest a maximum data unit size. This
   field is expressed as a number of bytes that can be included in a
   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 can
   detect the difference between a new process and a retransmission of a
   join[request].






















Armstrong, Freier & Marzullo                                   [Page 15]

RFC 1301              Multicast Transport Protocol         February 1992


3.1.2.  Join confirm/deny

   Only the master of the web will respond to join[request]. The
   response may either permit the entry of the new process or deny it.
   The request to join may be denied because the new member is
   specifying service parameters that are in conflict with those
   established by the master.  If the join is confirmed the
   join[confirm] will be unicast by the master with a data field that
   contains the web's current operating parameters. If those parameters
   are unacceptable to the joining process it may decide to withdraw
   from the web. Otherwise the parameters must be accepted as the
   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         |
   ---------------------------------------------------------- transport
   |                                                        |    header
   |              message acceptance criteria               |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              heartbeat                                 |      |
   ----------------------------------------------------------      |
   |                            |                           |      |
   |        window              |        retention          |      |
   ----------------------------------------------------------    -----
   |  member     |   transport  |  transport  |             |      |
   |  class      |   class      |  type       |  reserved   |      |
   ----------------------------------------------------------
   |        minimum             |     maximum data          |    data
   |        throughput          |     unit size             |
   ----------------------------------------------------------      |