rfc1301.txt

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

Network Working Group                                       S. Armstrong
Request for Comments: 1301                                         Xerox
                                                               A. Freier
                                                                   Apple
                                                             K. Marzullo
                                                                 Cornell
                                                           February 1992


                      Multicast Transport Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Summary

   This memo describes a protocol for reliable transport that utilizes
   the multicast capability of applicable lower layer networking
   architectures.  The transport definition permits an arbitrary number
   of transport providers to perform realtime collaborations without
   requiring networking clients (aka, applications) to possess detailed
   knowledge of the population or geographical dispersion of the
   participating members.  It is not network architectural specific, but
   does implicitly require some form of multicasting (or broadcasting)
   at the data link level, as well as some means of communicating that
   capability up through the layers to the transport.

   Keywords: reliable transport, multicast, broadcast, collaboration,
   networking.

Table of Contents

           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.      Introduction

   This document describes a flow controlled, atomic multicasting
   transport protocol (MTP).  The purpose of this document is to present
   sufficient information to implement the protocol.

   The MTP design has been influenced by the large body of the
   networking and distributed systems literature and technology that has
   been introduced during the last decade and a half.  Representative
   sources include [Xer81], [BSTM79] and [Pos81] for transport design,
   and [Bog83] and [DIX82] for general concepts of broadcast and
   multicast.  [CLZ87] influenced MTP's retransmission mechanisms, and
   [Fre84] influenced the transport timings. MTP over IP uses mechanisms



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


   described in [Dee89].  MTP's ordering and agreement protocols were
   influenced by work done in [CM87], [JB89] and [Cri88].  Finally, a
   description of MTP's philosophy and its motivation can be found in
   [AFM91].

2.      Protocol description

   MTP is a transport in that it is a client of the network layer (as
   defined by the OSI networking model) [1].  MTP provides reliable
   delivery of client data between one or more communicating processes,
   as well as a predefined principal process. The collection of
   processes is called a web.

   In addition to transporting data reliably and efficiently, MTP
   provides the synchronization necessary for web members to agree on
   the order of receipt of all messages and can agree on the delivery of
   the message even in the face of partitions.  This ordering and
   agreement protocol uses serialized tokens granted by the master to
   producers.

   The processes may have any one of three levels of capability. One
   member must be the master. The master instantiates and controls the
   behavior of the web, including its membership and performance. Non
   master members may be either producer/consumers or pure consumers.
   The former class of member is permitted to transmit user data to the
   entire membership (and expected to logically hear itself), while the
   latter is prohibited from transmitting user data.

   MTP is a negative acknowledgement protocol, exploiting the highly
   reliable delivery of the local area and wide area network
   technologies of today. Successful delivery of data is accepted by
   consuming stations silently rather than having the successful
   delivery noted to the producing process, thus reducing the amount of
   reverse traffic required to maintain synchronization.

2.1     Definition of terms

   The following terms are used throughout this document. They are
   defined here to eliminate ambiguity.

   consumer    A consumer is a transport that is capable only of
               receiving user data. It may transmit control packets,
               such as negative acknowledgements, but may never transmit
               any requests for the transmit token or any form of data
               or empty messages.

   heartbeat   A heartbeat is an interval of time, nominally measured in
               milliseconds. It is a key parameter in the transport's



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


               state and can be adapted to the requirements of the
               transport's client to provide the desired quality of
               service.

   master      The master is the principal member of the web. The master
               capability is a superset of a producer member.  The
               master is mainly responsible for giving out transmit
               tokens to members who wish to send data, and overseeing
               the web's membership and operational parameters.

   member      A web member is any process that has been permitted to
               join the web (by the master) as well as the master
               itself.

   membership  Every member is classified as to its intentions for
   class       joining the web. Membership classes are defined to be
               consumer, producer and master. Each successive class is a
               formal superset of the previous.

   message     An MTP message is a concatenation of the user data
               portions of a series of data packets with the last packet
               in the series carrying an end of message indication. A
               message may contain any number of bytes of user data,
               including zero.

   NSAP        The network service access point. This is the network
               address, or the node address of the machine, where a
               service is available.

   producer    Producer is a class of membership that is a formal
               superset of a consumer. A producer is permitted (and
               expected) to transmit client data as well as consume data
               transmitted by other producers.

   retention   Retention is one of the three fundamental parameters that
               make up the transport's state (along with heartbeat and
               window). Retention is a number of heartbeats, and though
               applied in several different circumstances, is primarily
               used as the number of heartbeats a producing client must
               maintain buffered data should it need to be
               retransmitted.

   token       In order to transmit, a producer must first be in
               possesion of a token. Tokens are granted only by the
               master and include the message sequence number.
               Consequently, they are fundamental in the operation of
               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 address
               that uniquely defines particular instantiation of a
               service. TSAPs are formed by logically concatenating the
               node's NSAP with a transport identifier (and perhaps a
               packet/protocol type).

   user data   User data is the client information carried in MTP data
               packets and treated as uninterpreted octets by the
               transport. The end of message and subchannel indicators
               are also be treated as user data.

   web         A collection of processes collaborating on the solution
               of a single problem.

   window      The window is one of the fundamental elements of the
               transport's state that can be controlled to affect the
               quality of service being provided to the client. It
               represents the number of user data carrying packets that
               may be multicast into the web during a heartbeat by a
               single member.































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


2.2     Packet format

   An MTP packet consists of a transport protocol header followed by a
   variable amount of data. The protocol header, shown in Figure 1, is
   part of every packet. The remainder of the packet is either user data
   (packet type = data) or additional transport specific information.
   The fields in the header are statically defined as n-bit wide
   quantities. There are no undefined fields or fields that may at any
   time have undefined values.  Reserved fields, if they exist, must
   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              |      |
   ----------------------------------------------------------      |