rfc1221.txt

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

   Every HAP message consists of an integral number of 16-bit words
   (i.e., an even number of octets).  The first several words of the
   message always contain control information and are referred to as the
   message header.  The first word of the message header identifies the
   type of message which follows.  The second word of the message header
   is a checksum which covers all header information.  Any message whose
   received header checksum does not match the checksum computed on the
   received header information must be discarded.  The format of the
   rest of the header depends on the specific message type.

   The formats and use of the individual message types are detailed in
   the following sections.  A common format description is used for this
   purpose.  Words in a message are numbered starting at zero (i.e.,
   zero is the first word of a message header).  Bits within a word are
   numbered from zero (most significant) to fifteen (least significant).
   The notation used to identify a particular field location is:

     <WORD#>{-<WORD#>}  [ <BIT#>{-<BIT#>} ]  <description>

   where optional elements in {} are used to specify the (inclusive)
   upper limit of a range.  The reader should refer to these field
   identifiers for precise field size specifications.  Fields which are
   common to several message types are defined in the first section
   which uses them.  Only the name of the field will usually appear in
   the descriptions in subsequent sections.

   Link-level protocols used to support HAP can differ in the order in
   which they transmit the bits constituting HAP messages.  The words of
   the message are transmitted from word 0 to word N.

3. Datagram Messages

   Datagrams are one of the two message types provided by HAP, as
   described in the previous section.  Because network resources are not
   reserved in advance for datagram traffic, delivery of datagram
   traffic is subject to greater delivery delays and delay variance than
   stream traffic, and is subject to flow and congestion controls.



Edmond                                                          [Page 6]

RFC 1221                          HAP2                        April 1991


   Datagram priority determines which packets are delivered or discarded
   when network resources do not permit handling all of the presented
   traffic.  It is expected that datagram messages will be used to
   support the majority of computer-to-computer and terminal-to-computer
   traffic which is bursty in nature.

   The format of datagram messages and the purpose of each of the header
   control fields is described in Figure 1.


                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     0         | 0|LB|GOPRI|    0   | F|     MESSAGE NUMBER    |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     1         |                HEADER CHECKSUM                |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     2         |                      A/R                      |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     3         | 0|IL| D| E| PRI | TTL | RLY |      RLEN       |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     4         |            DESTINATION HOST ADDRESS           |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     5         |              SOURCE HOST ADDRESS              |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     6         |                  PROTOCOL ID                  |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                                               |
     7-N       :                      DATA                     :
               |                                               |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                             DATAGRAM MESSAGE
                                 Figure 1



     0[0]      Message Class.  This bit identifies the message as a
               data message or a control message.

                    0 = Data Message
                    1 = Control Message

     0[1]      Loopback indicator.  This bit allows the sender of a
               message to determine if its own messages are being
               looped back.  The host and the WPS each use different
               settings of this bit for their transmissions.  If a
               message arrives with the loopback bit set equal to its



Edmond                                                          [Page 7]

RFC 1221                          HAP2                        April 1991


               outgoing value, then the message has been looped.

                    0 = Sent by Host
                    1 = Sent by WPS

     0[2-3]    Go-Priority.  In WPS-to-Host messages, this field
               provides advisory information concerning the lowest
               priority currently being accepted by the WPS.  The host
               may optionally choose to provide similar priority
               information to the WPS.

                    0 = Low Priority
                    1 = Medium Priority
                    2 = High Priority
                    3 = (Reserved.)

     0[4-6]    Reserved.  Must be zero.

     0[7]      Reserved.  Must be zero.  Formerly used for WPS
               diagnostic purposes.

     0[8-15]   Message Number.  This field contains the identification
               of the message used by the acceptance/refusal (A/R)
               mechanism (when enabled).  If the message number is
               zero, A/R is disabled for this specific message.  See
               Section 5 for a detailed description of the A/R
               mechanism.

     1[0-15]   Header Checksum.  The checksum is the 2's-complement of
               the 2's-complement sum of words 0-6 (excluding the
               checksum word itself).

     2[0-15]   Piggybacked A/R.  This field may contain an
               acceptance/refusal word providing A/R status on traffic
               flowing in the opposite direction.  Its inclusion may
               eliminate the need for a separate A/R control message
               (see Section 5).  A value of zero for this word is used
               to indicate that no piggybacked A/R information is
               present.

     3[0]      Data Message Type.  This bit identifies whether the
               message is a datagram message or a stream message.

                    0 = Datagram Message
                    1 = Stream Message

     3[1]      IL flag.  Obsolete.  Must be zero.  (See Appendix B.)




Edmond                                                          [Page 8]

RFC 1221                          HAP2                        April 1991


     3[2]      Discard Flag.  This flag allows a source host to
               instruct the network (including the destination host)
               what to do with the message when data errors are
               detected (assuming the header checksum is correct).

                    0 = Discard message if data errors detected.
                    1 = Don't discard message if data errors detected.

               The value of this flag, set by the source host, is
               passed on to the destination host.

     3[3]      Data Error Flag.  This flag is used in conjunction with
               the Discard Flag to indicate to the destination host
               whether any data errors have been detected in the
               message prior to transmission over the destination's
               WPS-to-Host access link.  It is used only if Discard
               Flag = 1.  It should be set to zero by the source host.

                    0 = No Data Errors Detected
                    1 = Data Errors Detected

     3[4-5]    Priority.  The source host uses this field to specify
               the priority with which the message should be handled
               within the network.

                    0 = Low Priority
                    1 = Medium Priority
                    2 = High Priority
                    3 = (Reserved.)

               The priority of each message is passed to the
               destination host by the destination WPS.

     3[6-7]    Time-to-Live Designator.  The source host uses this
               field to specify the maximum time that a message should
               be allowed to exist within the network before being
               deleted.  Elapsed time begins when the message has been
               received by the WPS from the source host (or is sent by
               a WPS agent) and is last checked when the message is
               queued for transmission out the I/O interface to the
               destination host.  If a message is multicast, each copy
               is treated separately.

                    0 = 1 seconds
                    1 = 2 seconds
                    2 = 5 seconds
                    3 = 10 seconds




Edmond                                                          [Page 9]

RFC 1221                          HAP2                        April 1991


     3[8-9]    Reliability.  The source host uses this field to
               specify the basic bit error rate requirement for the
               data portion of this message.  The source WPS uses this
               field to determine the trunk circuit transmission
               parameters and forward error correction level required
               to provide that bit error rate.

                    0 = Low Reliability
                    1 = Medium-Low Reliability
                    2 = Medium-High Reliability
                    3 = High Reliability

     3[10-15]  Reliability Length.  The source host uses this field to
               specify a portion of the user data which should be
               transmitted at the highest reliability level (lowest
               bit error rate).  Both the HAP message header words and
               the first 2*<Reliability Length> octets of user data
               will be transmitted at high reliability while the
               remainder of the user data will be transmitted at
               whatever reliability level is specified in field 3[8-
               9].  The reliability length mechanism gives the user
               the ability to transmit private header information
               (e.g., IP and TCP headers) at a higher reliability
               level than the remainder of the data.

     4[0-15]   Destination Host Address.  This field contains the
               network logical address of the destination host.

     5[0-15]   Source Host Address.  This field contains the network
               logical address of the source host.

     6[0-15]   Protocol ID.  This field specifies the next higher
               level protocol.  Protocol identifiers are assigned
               administratively, except 0 which is reserved, and are
               not part of this specification.  See reference [10].

     7-N       Data.  This field contains up to 16,384 bits (2048
               octets) of user data, and must be an even number of
               octets.

4. Stream Messages

   Stream messages are the second message type provided by HAP, as
   described in Section 2.  Streams provide guaranteed bandwidth between
   the source and destination(s), and provide the minimum delivery delay
   and delay variance available in the network.  Streams are suitable
   for volatile traffic, such as speech, and for support of high duty
   cycle applications that require throughput guarantees.



Edmond                                                         [Page 10]

RFC 1221                          HAP2                        April 1991


   Streams must be created before stream messages can flow from host to
   host.  The protocol to accomplish stream creation is described in
   Section 6.1.  Once established, a stream is allocated specific
   network resources, such as bandwidth.  Within the bounds of its
   stream allocation, a host is permitted considerable flexibility in
   how it may use the stream.  Although the time to live, reliability,
   and reliability length of each stream message is fixed at stream
   setup time, the destination logical address can vary from stream
   message to stream message.

   A host can, therefore, multiplex a variety of logical flows onto a
   single stream, as long as the stream was set up to reach all the
   destination hosts.  The format of stream messages is described in
   Figure 2.


                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     0         | 0|LB|GOPRI|     0     |     MESSAGE NUMBER    |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     1         |               HEADER CHECKSUM                 |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     2         |                      A/R                      |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     3         | 1|IL| D| E| PRI |       HOST STREAM ID        |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+