rfc1301.txt

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

   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             |
   ----------------------------------------------------------      |
   |                  multicast connection                  |      |
   |                  identifier                            |      |
   ----------------------------------------------------------    -----

                           Figure 3. join packet

   The join[confirm] will also contain the multicast connection
   identifier.  This must be used to form the TSAP that will be the
   destination for all multicast messages for the transport. The source



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 be
   recorded by the member for later use.

   The master must be in possession of all the transmit tokens when it
   sends a join[confirm]. Requiring the master to have the transmit
   tokens insures that the joining member will enter the web and observe
   only complete messages. It also permits a notification of the
   master's client of the join so that application state may be
   automatically sent to the newly joining member. The newly joined
   member may be on a network not previously represented in the web's
   membership, thus requiring a new multicast TSAP be added to the
   existing list. The entire list will be conveyed in the data field of
   all subsequent token[confirm] messages (described later).