rfc1221.txt

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

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

     2[0-15]   Response Information. If Response Code is:




Edmond                                                         [Page 16]

RFC 1221                          HAP2                        April 1991


                    3: Destination Host Address
                    5: Destination Host Address
                    7: Source Host Address
                    9: Stream ID (right justified)
                   10: Stream ID (right justified)
                   13: Word 0 of offending message
                   15: Word 0 of Loopback Request message

     3[0-15]   Response Information. If Response Code is:

                    3,5,7, or 9: Undefined
                    10: Source Host Address
                    13: Word 3 of offending message, or 0 if no word 3
                    15: Word 2 of Loopback Request message

6. The Service Agent

   Allocation of network resources, such as streams and groups, is
   accomplished via an exchange of datagram messages, called Setup
   messages, between the user host and the Service Agent (network
   address zero).  Setup operations include reserving, allocating,
   modifying, freeing, and deallocating resources.  The Service Agent
   causes the requested action to be carried out and serves as the
   intermediary between the user and the rest of the network.  In the
   process of implementing the requested action, various network data
   bases are updated to reflect the current state of the referenced
   resource.  The Service Agent also permits a host to inquire about
   resources it owns using Information Request and Information Reply
   messages.

   A setup interaction initiated by a host involves a 3-way exchange
   where: (1) the requesting host sends a Setup Request to the Service
   Agent, (2) the Service Agent returns a Setup Reply to the requesting
   host, and (3) the requesting host returns a Setup Acknowledgment to
   the Service Agent.  This procedure is used to ensure reliable
   transmission of Setup Requests and Replies.  In order to allow more
   than one Setup Request message from a host to be outstanding, each
   Request is assigned a unique Request ID.  The associated Reply and
   subsequent Acknowledgment are identified by the Request ID that they
   contain.  The requesting host should receive a reply to a setup
   request within 3 seconds.  The actual delay will depend on the nature
   of the request and the topology of the network.  For simple networks,
   the delay will often be less than one second.  The requesting host
   should respond to a Reply with a Setup Acknowledgment within one
   second.

   Setup exchanges initiated by the Service Agent involve a two-way
   exchange where: (1) the Service Agent sends a Notification to



Edmond                                                         [Page 17]

RFC 1221                          HAP2                        April 1991


   affected hosts, and (2) the hosts return a Setup Acknowledgment to
   the Service Agent.  Notifications are used to inform a host of
   changes in the status of a network resource.  In order to allow more
   than one Notification to be outstanding, each is assigned a unique
   Notification ID.  The Setup Acknowledgment returned by the notified
   host to the Service Agent must contain the Notification ID.  The host
   should respond within one second.

   An information query is initiated by a host and involves a two-way
   exchange where: (1) the host sends an Information Request message to
   the Service Agent, and (2) the Service Agent sends back an
   Information Reply.  There is no acknowledgment mechanism, since this
   request does not change any resource allocation.  Furthermore, if
   there is an error in the request, only one response will be sent by
   the WPS, and the WPS will make no effort to check for or retransmit
   lost responses.  It is the responsibility of the host to wait a
   certain amount of time and then determine that an unanswered
   information request has been lost and to resend it.  (The time
   necessary to answer such a request is usually much less than one
   second.)  The WPS will return the message ID of the information
   request in the information reply message.

          The general format of all Service Agent messages is:

                         <DATAGRAM MESSAGE HEADER>
                          <SERVICE AGENT HEADER>
                              <MESSAGE BODY>

   The Protocol ID field in the datagram message header must be
   HAP_PROTO_SETUP (1) (see Appendix C) for messages sent to the Service
   Agent and will be HAP_PROTO_SETUP in messages received from the
   Service Agent.  The Service Agent does not recognize or support use
   of other higher level protocols (e.g., IP), in setup messages, and
   will discard messages containing such headers.

   Illustrations of message formats below show only the Service Agent
   Header header and message body and do not include the datagram
   message header.  As a reminder that the datagram header is not
   included, word offsets are prefixed with an "S".

   The format of the Service Agent Header is illustrated in Figure 6.
   The body of the message will depend on the particular message type.
   Stream Request and Reply messages are described in Section 6.1.
   Group Request and Reply messages are described in Section 6.2.  The
   format of Notifications is described in Section 6.3, and Setup
   Acknowledgments are described in Section 6.4.  Information Request
   and Reply messages are described in Section 6.5.




Edmond                                                         [Page 18]

RFC 1221                          HAP2                        April 1991


                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     S0        |     MESSAGE TYPE      |          CODE         |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     S1        |                    CHECKSUM                   |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     S2        |                   MESSAGE ID                  |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                           SERVICE AGENT HEADER
                                 Figure 6


     S0[0-7]   Message Type.  This field determines the type of
               message.

                    0 = Setup Acknowledgment
                    1 = Setup Request
                    2 = Setup Reply
                    3 = Notification
                    4 = Information Request
                    5 = Information Reply

     S0[8-15]  Code.  For Setup Requests, this field identifies the
               request type.

                    1 = Create group (multicast) address
                    2 = Delete group address
                    3 = Join group
                    4 = Leave group
                    5 = Create stream
                    6 = Delete stream
                    7 = Change stream
                    8 = Create shared stream
                    9 = Delete all streams owned by this host
                   10 = Add member to group
                   11 = Remove member from group

               For Setup Replies, this field provides the Reply Code.
               Some of the Reply Codes can be returned to any setup
               request and others are request specific.

                    0 = Group or stream created
                    1 = Group or stream deleted
                    2 = Host added to group
                    3 = Host deleted from group
                    4 = Stream changed



Edmond                                                         [Page 19]

RFC 1221                          HAP2                        April 1991


                    5 = (Reserved)
                    6 = Request type invalid or unsupported
                    7 = (Reserved)
                    8 = Network trouble
                    9 = Bad group key
                   10 = Group address/stream ID nonexistent
                   11 = Not member of group/not creator of stream
                   12 = Stream precedence not being accepted
                   13 = (Reserved)
                   14 = (Reserved)
                   15 = (Reserved)
                   16 = Unable to add all the new hosts
                   17 = Insufficient network resources
                   18 = Requested bandwidth too large
                   19 = (Reserved)
                   20 = (Reserved)
                   21 = Maximum messages per interval too small
                   22 = Reply lost in network
                   23 = Illegal priority or precedence value
                   24 = Invalid address provided

               For Notifications, this field contains the Notification
               Type.  (See Section 6.3.)

               For Setup Acknowledgments, this field contains the
               Acknowledgment Type.  (See Section 6.4.)

               For Information Requests, this field contains the
               request type.  (See Section 6.5.)

               For Information Replies, this field contains the reply
               type.  (See Section 6.5.)

     S1[0-15]  Checksum.  The checksum is the 2's-complement of the
               2's-complement sum of the words in the Service Agent
               Header (excluding the checksum word itself) and the
               message body.  Messages received with bad checksums
               must be discarded.

     S2[0-15]  Message ID.  This field is assigned by the host to
               uniquely identify outstanding requests (Request ID) and
               by the Service Agent to uniquely identify outstanding
               notifications (Notification ID).

6.1. Stream Setup Messages

   Streams provide a means of reserving network resources for the
   delivery of traffic at a specified maximum throughput to a specified



Edmond                                                         [Page 20]

RFC 1221                          HAP2                        April 1991


   list of recipients.  Traffic sent via a stream has priority over all
   non-stream traffic, and is delivered with the minimum end-to-end
   delay possible.  Hosts use streams to support applications that have
   predictable traffic loads (such as packet voice or video or other
   continuous media traffic) or that require minimum transmission delay
   and lowest delay variance.  Streams are typically used for traffic
   flows of moderate to long duration, where the cost of performing a
   stream Setup is acceptable.

   Streams must be set up before stream data messages can flow.  The
   stream setup messages, each of which has a Request and a Reply, are
   Create Stream, Delete Stream, Change Stream, and Delete All Streams.
   (Create Shared Stream Request is a planned future addition to the
   protocol.)  The use of these messages is illustrated in the scenario
   of exchanges between a host and the Service Agent shown in Figure 7
   where the host establishes a stream, sends some data, modifies the
   stream characteristics, sends some more data, and finally closes down
   the stream.  Not illustrated, but implicit in this scenario, are the
   optional A/R indications associated with each of the stream Setup
   messages.


                                              Service     Other
                                     Host      Agent      hosts

          Create Stream Request        ---------->
          Create Stream Reply          <----------
          Reply Acknowledgment         ---------->
          Stream Messages              --------------------->
             :   :
          Change Stream Request        ---------->
          Change Stream Reply          <----------
          Reply Acknowledgment         ---------->
          Stream Messages              --------------------->
             :   :
          Delete Stream Request        ---------->
          Delete Stream Reply          <----------
          Reply Acknowledgment         ---------->

                              STREAM EXAMPLE
                                 Figure 7

   Streams have eight characteristic properties which are selected at
   stream setup time.  These properties are: (1) data words per time
   interval, (2) time interval, (3) reliability, (4) reliability length,
   (5) precedence, (6) maximum messages per interval, (7) the list of
   recipients, and (8) the set of other streams with which this stream
   shares resources.  To establish a stream, the host sends the Create



Edmond                                                         [Page 21]

RFC 1221                          HAP2                        April 1991


   Stream Request message (Figure 8) to the Service Agent.  After the
   network has processed the Create Stream Request, the Service Agent