home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1200s / rfc1221.txt < prev    next >
Text File  |  1991-04-15  |  153KB  |  3,811 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          W. Edmond
  8. Request for Comments: 1221                                           BBN
  9. Updates: RFC 907                                              April 1991
  10.  
  11.  
  12.           Host Access Protocol (HAP) Specification - Version 2
  13.  
  14. Status of this Memo
  15.  
  16.    This memo describes the Host Access Protocol implemented in the
  17.    Terrestrial Wideband Network (TWBNET).  It obsoletes most but not all
  18.    of RFC 907.  This memo provides information for the Internet
  19.    community.  It does not specify an Internet standard.  Distribution
  20.    of this memo is unlimited.
  21.  
  22. Preface
  23.  
  24.    This memo specifies the Host Access Protocol (HAP).  HAP is a Network
  25.    layer (OSI Layer 3 lower) access protocol that was first implemented
  26.    about a decade ago for the DARPA/DCA sponsored Wideband Packet
  27.    Satellite Network (WBNET), the precursor of the current Terrestrial
  28.    Wideband Network (TWBNET).  This version of the specification
  29.    obsoletes references [1] and [2] in addition to most of RFC 907.
  30.  
  31.    HAP is a developmental protocol, and will be revised as new
  32.    capabilities are added and unused features are eliminated or revised.
  33.    One reason that HAP is being revised now is that, unlike the original
  34.    WBNET's satellite channel, the TWBNET's T1 fiber links are not a
  35.    broadcast medium.  This has prompted some changes to the protocol
  36.    that will permit greater efficiency in a mesh topology network.
  37.    Another cause of revision is the need to make HAP able to support a
  38.    variety of OSI layer 3 upper protocols, such as DECNET Phase V, ST,
  39.    and CLNP, where before only Internet Protocol (IP) was used.
  40.    Appendix B describes how backward compatibility with the older IP-
  41.    only version of HAP is achieved.  A third cause of protocol changes
  42.    is the desire to simplify interaction between ST2 protocol (RFC 1190)
  43.    agents and the TWBNET.  This has mainly affected the way certain
  44.    setup errors are handled.  These changes are expected to be backward
  45.    compatible.  Appendix A describes two capabilities that may be added
  46.    to HAP in the future.
  47.  
  48.    One of the protocol enhancements, "Group Streams", described in
  49.    reference [2] has been eliminated.  There are no known applications
  50.    that use the feature.  As described in Appendix A, a new mechanism,
  51.    to be called "shared streams", capable of providing equivalent
  52.    capabilities will be implemented if needed.  Changes in [2] that have
  53.    been retained include various query/reply control messages that
  54.    permit a host to determine what resources it owns (mostly useful for
  55.  
  56.  
  57.  
  58. Edmond                                                          [Page 1]
  59.  
  60. RFC 1221                          HAP2                        April 1991
  61.  
  62.  
  63.    cleanup following a host reboot or crash).
  64.  
  65.    This document assumes the reader is familiar with DoD internetworking
  66.    terminology.
  67.  
  68. 1. Introduction
  69.  
  70.    The Host Access Protocol (HAP) is a network layer protocol (as is
  71.    X.25).  ("Network layer" here means ISO layer 3 lower, the protocol
  72.    layer below the DoD Internet Protocol (IP) layer [3] and above any
  73.    link layer protocol.)  HAP defines the different types of host-to-
  74.    network control messages and host-to-host data messages that may be
  75.    exchanged over the access link connecting a host and the network
  76.    packet switch node.  The protocol establishes formats for these
  77.    messages, and describes procedures for determining when each type of
  78.    message should be transmitted and what it means when one is received.
  79.  
  80.    HAP has been implemented in the wide-area network called the
  81.    Terrestrial Wideband Network (TWBNET) [5] and in the routers and
  82.    other hosts that connect to TWBNET.  The packet switch nodes that
  83.    compose the TWBNET are called Wideband Packet Switches (WPS).
  84.  
  85.    Both the precursor to HAP, the Host/SATNET Protocol [6], used in the
  86.    Atlantic Packet Satellite Network (SATNET) and the Mobile Access
  87.    Terminal Network (MATNET [7]), and HAP, used in the original Wideband
  88.    Satellite Network (WBNET) [8], were originally designed to provide
  89.    efficient access to the single satellite channel each network used to
  90.    connect all sites.  The HAP protocol designers reflected some of the
  91.    peculiarities of the single satellite channel environment in the HAP
  92.    protocol itself.  The current Terrestrial Wideband Network (TWBNET)
  93.    utilizes T1-speed fiber connections between sites.  Future networks
  94.    and TWBNET may use a combination of terrestrial connections and
  95.    satellite connections, and may have more than one of each.  The HAP
  96.    protocol has been changed to accommodate these extensions.
  97.  
  98.    Section 2 presents an overview of HAP.  Details of HAP formats and
  99.    message exchange procedures are contained in Sections 3 through 10.
  100.    Further explanation of some of the topics addressed in this HAP
  101.    specification can be found in reference [1].
  102.  
  103.    Any protocol employed to provide sufficiently reliable message
  104.    exchange over the Host-WPS link is assumed to be transparent to the
  105.    protocol defined in this document.  Examples of such link-level
  106.    protocols are ARPANET 1822 local and distant host [9], ARPANET VDH
  107.    protocol [9], and HDLC.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Edmond                                                          [Page 2]
  115.  
  116. RFC 1221                          HAP2                        April 1991
  117.  
  118.  
  119. 2. Overview
  120.  
  121.    HAP can be characterized as a full duplex, nonreliable protocol with
  122.    an optional flow control mechanism.  HAP messages flow simultaneously
  123.    in both directions between the WPS and the host.  Transmission is
  124.    nonreliable in the sense that the protocol does not provide any
  125.    guarantee of error-free sequenced delivery.  If error-free delivery
  126.    on the host's access link is required, it must be provided by the
  127.    link layer protocol below HAP.  (Use of link layer protocols for this
  128.    purpose is not within the scope of this document.)  HAP's flow
  129.    control mechanism operates independently in each direction, but the
  130.    choice to enable flow control or not applies to both directions
  131.    together.
  132.  
  133.    HAP supports host-to-host communication in two modes corresponding to
  134.    the two types of HAP data messages, datagram messages and stream
  135.    messages.  Each type of message can be up to 2048 octets in length.
  136.    The basic transmission service in the network is datagram service.
  137.    Datagrams are variable length, unsequenced, independent, and delivery
  138.    is not guaranteed.  The HAP header of each datagram determines the
  139.    processing of the message.
  140.  
  141.    On this datagram service base a "stream" service is built.  Stream
  142.    service provides network bandwidth guarantees, but requires explicit
  143.    setup and teardown operations to allocate and deallocate network
  144.    resources.  Stream traffic is best suited for continuous media
  145.    traffic, but may also be used to obtain the lowest possible network
  146.    delay.  Host streams are established by a setup message exchange
  147.    between the host and the network prior to the commencement of data
  148.    flow.  Although established host streams can have their
  149.    characteristics modified by subsequent setup messages while they are
  150.    in use, the fixed allocation properties of streams relative to
  151.    datagrams impose rather strict requirements on the source of the
  152.    traffic using the stream.  Stream traffic arrivals must match the
  153.    stream allocation both in interarrival time and message size if
  154.    reasonable efficiency is to be achieved.  The characteristics and use
  155.    of datagrams and streams are described in detail in Sections 3 and 4
  156.    of this document.
  157.  
  158.    Both datagram and stream transmission in the network use logical
  159.    addressing.  Each host on the network is assigned a permanent 16-bit
  160.    logical address which is independent of the physical port on the WPS
  161.    to which it is attached.  These 16-bit logical addresses are present
  162.    in all Host-to-WPS and WPS-to-Host data messages.
  163.  
  164.    HAP supports multicast addressing via "groups".  Multicast addressing
  165.    is provided primarily to support the multi-destination delivery
  166.    required for conferencing applications.  Group addresses are
  167.  
  168.  
  169.  
  170. Edmond                                                          [Page 3]
  171.  
  172. RFC 1221                          HAP2                        April 1991
  173.  
  174.  
  175.    dynamically created and deleted by the use of setup messages
  176.    exchanged between a host and the WPS.  Membership in a group may be
  177.    any arbitrary subset of the network hosts.  A message addressed to a
  178.    group address is delivered to all hosts that are members of that
  179.    group, except the sender.  Once a multicast address has been created,
  180.    any member host may use that address, not just the creator.
  181.  
  182.    Although HAP does not guarantee error-free delivery, error control is
  183.    an important aspect of the protocol design.  HAP error control is
  184.    concerned with both local transfers between a host and its local WPS
  185.    and transfers through the network to the destination(s).  The WPS
  186.    offers users a choice of network error protection options based on
  187.    the network's ability to selectively send messages over its
  188.    transmission media at different forward error correction (FEC) rates.
  189.    These FEC options are referred to as reliability levels.  Four
  190.    reliability levels (low, medium-low, medium-high, and high) are
  191.    available.  The precise error rate provided by each reliability level
  192.    is not specified.
  193.  
  194.    Various checksum and CRC mechanisms are employed in the network to
  195.    provide an error detection capability.  A host has an opportunity
  196.    when sending a message to indicate whether the message should be
  197.    delivered to its destination or discarded if a data error is detected
  198.    by the network.  Each message received by a host from the network
  199.    will have a flag indicating whether or not an error was detected in
  200.    that particular message.  A host can decide on a per-message basis
  201.    whether or not it wants to accept or discard transmissions containing
  202.    data errors.
  203.  
  204.    For connection of a host and WPS in close proximity, error rates due
  205.    to external noise or hardware failures on the access circuit may
  206.    reasonably be expected to be much smaller than the best network trunk
  207.    circuit error rates.  Thus for this case, little is gained by using
  208.    error detection and retransmission on the access circuit.  A 16-bit
  209.    header checksum is provided, however, to ensure that WPSen do not act
  210.    on incorrect control information.  For relatively long distances or
  211.    noisy connections, retransmissions over the access circuit may be
  212.    required to optimize performance for both low and high reliability
  213.    traffic.  It is expected that link layer error control procedures
  214.    (such as HDLC with retransmission) will be used for this purpose, but
  215.    use of a reliable link layer protocol is not within the scope of this
  216.    document.
  217.  
  218.    Each datagram message submitted to the WPS by a host is marked as
  219.    being in one of three priority classes, from priority 2 (highest)
  220.    through priority 0 (lowest).  The priority class is used by the WPS
  221.    for arbitrating contention for scarce network resources (e.g., link
  222.    bandwidth).  That is, if the network cannot deliver all of the
  223.  
  224.  
  225.  
  226. Edmond                                                          [Page 4]
  227.  
  228. RFC 1221                          HAP2                        April 1991
  229.  
  230.  
  231.    offered messages, high priority messages will be delivered in
  232.    preference to low priority messages.  Priority level affects the
  233.    order of access to intersite link bandwidth and the order of message
  234.    delivery at the destination WPS.
  235.  
  236.    Each stream message also has three priority classes, from priority 2
  237.    (highest) through priority 0 (lowest).  In addition, streams
  238.    themselves have three precedence classes, from precedence 2 (highest)
  239.    through precedence 0.  A stream of higher precedence can preempt a
  240.    stream of lower precedence at setup time.  Stream message priority
  241.    provides a mechanism for a low-bandwidth host to receive a high-
  242.    bandwidth stream and selectively discard messages marked as less
  243.    important by the sender.  Stream message priority does not affect the
  244.    order of delivery of stream messages between the source and the
  245.    destination.
  246.  
  247.    Datagram and stream messages being presented to the WPS by a host may
  248.    not be accepted for a number of reasons: priority too low,
  249.    destination dead, lack of buffers in the source WPS, etc.  The host
  250.    faces a similar situation with respect to handling messages from the
  251.    WPS.  To permit the receiver of a message to inform the sender of the
  252.    local disposition of its message, an acceptance/refusal (A/R)
  253.    mechanism is implemented.  The mechanism is the external
  254.    manifestation of the WPS's (or host's) internal flow and congestion
  255.    control algorithm.  If A/Rs are enabled, an explicit or implicit
  256.    acceptance or refusal for each message is returned to the host by the
  257.    WPS (and conversely).  This allows the host (or WPS) to retry refused
  258.    messages at its discretion and can provide information useful for
  259.    optimizing the sending of subsequent messages when the reason for
  260.    refusals is also provided.  The A/R mechanism can be disabled to
  261.    provide a "pure discard" interface.  The host's choice to use the A/R
  262.    mechanism or not does not limit its ability to send and receive
  263.    messages to any other hosts.
  264.  
  265.    While the A/R mechanism allows control of individual message
  266.    transfers, it does not facilitate regulation of priority flows.  Such
  267.    regulation is handled by passing advisory status information (GOPRI)
  268.    across the Host-WPS interface indicating which priorities are
  269.    currently being accepted.  As long as this information, relative to
  270.    the change in priority status, is passed frequently, the sender can
  271.    avoid originating messages which are sure to be refused.
  272.  
  273.    HAP defines both data messages (datagram messages and stream
  274.    messages) and link control messages.  Data messages are used to send
  275.    information between hosts on the network.  Link control messages are
  276.    exchanged between a host and the WPS to manage the local access link.
  277.  
  278.    Allocation of network resources, such as streams and groups, is
  279.  
  280.  
  281.  
  282. Edmond                                                          [Page 5]
  283.  
  284. RFC 1221                          HAP2                        April 1991
  285.  
  286.  
  287.    accomplished via an exchange of datagram messages, called Setups,
  288.    between the user host and an agent inside the WPS called the "Service
  289.    Agent."  Setups are used to reserve, allocate, modify, free, and
  290.    deallocate network resources.  Each allocated resource has a unique
  291.    identifier which, when placed in an appropriate field in a message
  292.    header, allows that message to use the resource.  E.g., after an
  293.    exchange of Setups to create a group address, a message may be sent
  294.    to the group by placing the group address in the destination field of
  295.    that message.  The Service Agent also permits a host to inquire about
  296.    resources it owns.
  297.  
  298.    Every HAP message consists of an integral number of 16-bit words
  299.    (i.e., an even number of octets).  The first several words of the
  300.    message always contain control information and are referred to as the
  301.    message header.  The first word of the message header identifies the
  302.    type of message which follows.  The second word of the message header
  303.    is a checksum which covers all header information.  Any message whose
  304.    received header checksum does not match the checksum computed on the
  305.    received header information must be discarded.  The format of the
  306.    rest of the header depends on the specific message type.
  307.  
  308.    The formats and use of the individual message types are detailed in
  309.    the following sections.  A common format description is used for this
  310.    purpose.  Words in a message are numbered starting at zero (i.e.,
  311.    zero is the first word of a message header).  Bits within a word are
  312.    numbered from zero (most significant) to fifteen (least significant).
  313.    The notation used to identify a particular field location is:
  314.  
  315.      <WORD#>{-<WORD#>}  [ <BIT#>{-<BIT#>} ]  <description>
  316.  
  317.    where optional elements in {} are used to specify the (inclusive)
  318.    upper limit of a range.  The reader should refer to these field
  319.    identifiers for precise field size specifications.  Fields which are
  320.    common to several message types are defined in the first section
  321.    which uses them.  Only the name of the field will usually appear in
  322.    the descriptions in subsequent sections.
  323.  
  324.    Link-level protocols used to support HAP can differ in the order in
  325.    which they transmit the bits constituting HAP messages.  The words of
  326.    the message are transmitted from word 0 to word N.
  327.  
  328. 3. Datagram Messages
  329.  
  330.    Datagrams are one of the two message types provided by HAP, as
  331.    described in the previous section.  Because network resources are not
  332.    reserved in advance for datagram traffic, delivery of datagram
  333.    traffic is subject to greater delivery delays and delay variance than
  334.    stream traffic, and is subject to flow and congestion controls.
  335.  
  336.  
  337.  
  338. Edmond                                                          [Page 6]
  339.  
  340. RFC 1221                          HAP2                        April 1991
  341.  
  342.  
  343.    Datagram priority determines which packets are delivered or discarded
  344.    when network resources do not permit handling all of the presented
  345.    traffic.  It is expected that datagram messages will be used to
  346.    support the majority of computer-to-computer and terminal-to-computer
  347.    traffic which is bursty in nature.
  348.  
  349.    The format of datagram messages and the purpose of each of the header
  350.    control fields is described in Figure 1.
  351.  
  352.  
  353.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  354.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  355.      0         | 0|LB|GOPRI|    0   | F|     MESSAGE NUMBER    |
  356.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  357.      1         |                HEADER CHECKSUM                |
  358.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  359.      2         |                      A/R                      |
  360.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  361.      3         | 0|IL| D| E| PRI | TTL | RLY |      RLEN       |
  362.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  363.      4         |            DESTINATION HOST ADDRESS           |
  364.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  365.      5         |              SOURCE HOST ADDRESS              |
  366.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  367.      6         |                  PROTOCOL ID                  |
  368.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  369.                |                                               |
  370.      7-N       :                      DATA                     :
  371.                |                                               |
  372.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  373.  
  374.  
  375.                              DATAGRAM MESSAGE
  376.                                  Figure 1
  377.  
  378.  
  379.  
  380.      0[0]      Message Class.  This bit identifies the message as a
  381.                data message or a control message.
  382.  
  383.                     0 = Data Message
  384.                     1 = Control Message
  385.  
  386.      0[1]      Loopback indicator.  This bit allows the sender of a
  387.                message to determine if its own messages are being
  388.                looped back.  The host and the WPS each use different
  389.                settings of this bit for their transmissions.  If a
  390.                message arrives with the loopback bit set equal to its
  391.  
  392.  
  393.  
  394. Edmond                                                          [Page 7]
  395.  
  396. RFC 1221                          HAP2                        April 1991
  397.  
  398.  
  399.                outgoing value, then the message has been looped.
  400.  
  401.                     0 = Sent by Host
  402.                     1 = Sent by WPS
  403.  
  404.      0[2-3]    Go-Priority.  In WPS-to-Host messages, this field
  405.                provides advisory information concerning the lowest
  406.                priority currently being accepted by the WPS.  The host
  407.                may optionally choose to provide similar priority
  408.                information to the WPS.
  409.  
  410.                     0 = Low Priority
  411.                     1 = Medium Priority
  412.                     2 = High Priority
  413.                     3 = (Reserved.)
  414.  
  415.      0[4-6]    Reserved.  Must be zero.
  416.  
  417.      0[7]      Reserved.  Must be zero.  Formerly used for WPS
  418.                diagnostic purposes.
  419.  
  420.      0[8-15]   Message Number.  This field contains the identification
  421.                of the message used by the acceptance/refusal (A/R)
  422.                mechanism (when enabled).  If the message number is
  423.                zero, A/R is disabled for this specific message.  See
  424.                Section 5 for a detailed description of the A/R
  425.                mechanism.
  426.  
  427.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  428.                the 2's-complement sum of words 0-6 (excluding the
  429.                checksum word itself).
  430.  
  431.      2[0-15]   Piggybacked A/R.  This field may contain an
  432.                acceptance/refusal word providing A/R status on traffic
  433.                flowing in the opposite direction.  Its inclusion may
  434.                eliminate the need for a separate A/R control message
  435.                (see Section 5).  A value of zero for this word is used
  436.                to indicate that no piggybacked A/R information is
  437.                present.
  438.  
  439.      3[0]      Data Message Type.  This bit identifies whether the
  440.                message is a datagram message or a stream message.
  441.  
  442.                     0 = Datagram Message
  443.                     1 = Stream Message
  444.  
  445.      3[1]      IL flag.  Obsolete.  Must be zero.  (See Appendix B.)
  446.  
  447.  
  448.  
  449.  
  450. Edmond                                                          [Page 8]
  451.  
  452. RFC 1221                          HAP2                        April 1991
  453.  
  454.  
  455.      3[2]      Discard Flag.  This flag allows a source host to
  456.                instruct the network (including the destination host)
  457.                what to do with the message when data errors are
  458.                detected (assuming the header checksum is correct).
  459.  
  460.                     0 = Discard message if data errors detected.
  461.                     1 = Don't discard message if data errors detected.
  462.  
  463.                The value of this flag, set by the source host, is
  464.                passed on to the destination host.
  465.  
  466.      3[3]      Data Error Flag.  This flag is used in conjunction with
  467.                the Discard Flag to indicate to the destination host
  468.                whether any data errors have been detected in the
  469.                message prior to transmission over the destination's
  470.                WPS-to-Host access link.  It is used only if Discard
  471.                Flag = 1.  It should be set to zero by the source host.
  472.  
  473.                     0 = No Data Errors Detected
  474.                     1 = Data Errors Detected
  475.  
  476.      3[4-5]    Priority.  The source host uses this field to specify
  477.                the priority with which the message should be handled
  478.                within the network.
  479.  
  480.                     0 = Low Priority
  481.                     1 = Medium Priority
  482.                     2 = High Priority
  483.                     3 = (Reserved.)
  484.  
  485.                The priority of each message is passed to the
  486.                destination host by the destination WPS.
  487.  
  488.      3[6-7]    Time-to-Live Designator.  The source host uses this
  489.                field to specify the maximum time that a message should
  490.                be allowed to exist within the network before being
  491.                deleted.  Elapsed time begins when the message has been
  492.                received by the WPS from the source host (or is sent by
  493.                a WPS agent) and is last checked when the message is
  494.                queued for transmission out the I/O interface to the
  495.                destination host.  If a message is multicast, each copy
  496.                is treated separately.
  497.  
  498.                     0 = 1 seconds
  499.                     1 = 2 seconds
  500.                     2 = 5 seconds
  501.                     3 = 10 seconds
  502.  
  503.  
  504.  
  505.  
  506. Edmond                                                          [Page 9]
  507.  
  508. RFC 1221                          HAP2                        April 1991
  509.  
  510.  
  511.      3[8-9]    Reliability.  The source host uses this field to
  512.                specify the basic bit error rate requirement for the
  513.                data portion of this message.  The source WPS uses this
  514.                field to determine the trunk circuit transmission
  515.                parameters and forward error correction level required
  516.                to provide that bit error rate.
  517.  
  518.                     0 = Low Reliability
  519.                     1 = Medium-Low Reliability
  520.                     2 = Medium-High Reliability
  521.                     3 = High Reliability
  522.  
  523.      3[10-15]  Reliability Length.  The source host uses this field to
  524.                specify a portion of the user data which should be
  525.                transmitted at the highest reliability level (lowest
  526.                bit error rate).  Both the HAP message header words and
  527.                the first 2*<Reliability Length> octets of user data
  528.                will be transmitted at high reliability while the
  529.                remainder of the user data will be transmitted at
  530.                whatever reliability level is specified in field 3[8-
  531.                9].  The reliability length mechanism gives the user
  532.                the ability to transmit private header information
  533.                (e.g., IP and TCP headers) at a higher reliability
  534.                level than the remainder of the data.
  535.  
  536.      4[0-15]   Destination Host Address.  This field contains the
  537.                network logical address of the destination host.
  538.  
  539.      5[0-15]   Source Host Address.  This field contains the network
  540.                logical address of the source host.
  541.  
  542.      6[0-15]   Protocol ID.  This field specifies the next higher
  543.                level protocol.  Protocol identifiers are assigned
  544.                administratively, except 0 which is reserved, and are
  545.                not part of this specification.  See reference [10].
  546.  
  547.      7-N       Data.  This field contains up to 16,384 bits (2048
  548.                octets) of user data, and must be an even number of
  549.                octets.
  550.  
  551. 4. Stream Messages
  552.  
  553.    Stream messages are the second message type provided by HAP, as
  554.    described in Section 2.  Streams provide guaranteed bandwidth between
  555.    the source and destination(s), and provide the minimum delivery delay
  556.    and delay variance available in the network.  Streams are suitable
  557.    for volatile traffic, such as speech, and for support of high duty
  558.    cycle applications that require throughput guarantees.
  559.  
  560.  
  561.  
  562. Edmond                                                         [Page 10]
  563.  
  564. RFC 1221                          HAP2                        April 1991
  565.  
  566.  
  567.    Streams must be created before stream messages can flow from host to
  568.    host.  The protocol to accomplish stream creation is described in
  569.    Section 6.1.  Once established, a stream is allocated specific
  570.    network resources, such as bandwidth.  Within the bounds of its
  571.    stream allocation, a host is permitted considerable flexibility in
  572.    how it may use the stream.  Although the time to live, reliability,
  573.    and reliability length of each stream message is fixed at stream
  574.    setup time, the destination logical address can vary from stream
  575.    message to stream message.
  576.  
  577.    A host can, therefore, multiplex a variety of logical flows onto a
  578.    single stream, as long as the stream was set up to reach all the
  579.    destination hosts.  The format of stream messages is described in
  580.    Figure 2.
  581.  
  582.  
  583.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  584.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  585.      0         | 0|LB|GOPRI|     0     |     MESSAGE NUMBER    |
  586.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  587.      1         |               HEADER CHECKSUM                 |
  588.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  589.      2         |                      A/R                      |
  590.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  591.      3         | 1|IL| D| E| PRI |       HOST STREAM ID        |
  592.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  593.      4         |            DESTINATION HOST ADDRESS           |
  594.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  595.      5         |              SOURCE HOST ADDRESS              |
  596.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  597.      6         |                  PROTOCOL ID                  |
  598.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  599.                |                                               |
  600.      7-N       :                      DATA                     :
  601.                |                                               |
  602.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  603.  
  604.  
  605.                               STREAM MESSAGE
  606.                                  Figure 2
  607.  
  608.  
  609.  
  610.      0[0]      Message Class = 0 (Data Message).
  611.  
  612.      0[1]      Loopback indicator.
  613.  
  614.      0[2-3]    Go-Priority.
  615.  
  616.  
  617.  
  618. Edmond                                                         [Page 11]
  619.  
  620. RFC 1221                          HAP2                        April 1991
  621.  
  622.  
  623.      0[4-7]    Reserved.
  624.  
  625.      0[8-15]   Message Number.  This field serves the same purpose as
  626.                the message number field in the datagram message.
  627.                Moreover, a single message number sequence is used for
  628.                both datagram and stream messages (see Section 5).
  629.  
  630.      1[0-15]   Header Checksum.  (See datagram checksum for
  631.                description.)
  632.  
  633.      2[0-15]   Piggybacked A/R.
  634.  
  635.      3[0]      Data Message Type = 1 (Stream).
  636.  
  637.      3[1]      IL flag.  Obsolete.  Must be zero.
  638.  
  639.      3[2]      Discard Flag.
  640.  
  641.      3[3]      Data Error Flag.
  642.  
  643.      3[4-5]    Stream message priority.  Note that all stream messages
  644.                have priority over any datagram message.  Priority will
  645.                not affect the order of stream message delivery.
  646.  
  647.                     0 = Low priority
  648.                     1 = Medium priority
  649.                     2 = High priority
  650.                     3 = Reserved
  651.  
  652.      3[6-15]   Stream ID.  The WPS uses this field to identify the
  653.                preallocated network resources (bandwidth allocations,
  654.                queues, buffers, etc.) to use for delivery of the
  655.                message.  Streams and their identifying numbers (stream
  656.                IDs) are established by an explicit Create Stream
  657.                request (see Section 6.1).
  658.  
  659.      4[0-15]   Destination Host Address.
  660.  
  661.      5[0-15]   Source Host Address.
  662.  
  663.      6[0-15]   Protocol ID.
  664.  
  665.      7-N       Data.  This field contains up to 16,384 bits (2048
  666.                octets) of user data, and must be an even number of
  667.                octets.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Edmond                                                         [Page 12]
  675.  
  676. RFC 1221                          HAP2                        April 1991
  677.  
  678.  
  679. 5. Flow Control Messages
  680.  
  681.    The WPS supports an acceptance/refusal (A/R) mechanism in each
  682.    direction on the host access link.  The A/R mechanism is enabled for
  683.    the link by the host by setting a bit in the Restart Complete control
  684.    message (see Section 8).  Each datagram and stream message contains
  685.    an 8-bit message number used to identify the message for flow control
  686.    purposes.  When the A/R mechanism is enabled, the message number is
  687.    incremented modulo 256 in successive messages, skipping over message
  688.    number zero (zero indicates that A/R's are disabled for that
  689.    message).  Up to 127 messages may be outstanding (awaiting acceptance
  690.    or refusal) in each direction.  If the receiver of a message is
  691.    unable to accept the message, a refusal indication containing the
  692.    message number of the refused message and the reason for the refusal
  693.    is returned.  The refusal indication may be piggybacked on data
  694.    messages in the opposite direction over the link or may be sent in a
  695.    separate control message in the absence of reverse data traffic.
  696.  
  697.    Acceptance indications are returned in a similar manner, either
  698.    piggybacked on data messages or in a separate control message.  An
  699.    acceptance is returned by the receiver to indicate that the
  700.    identified message was received from the host access link and was not
  701.    refused.  Acceptance indications returned by the WPS are not an end-
  702.    to-end acknowledgement and do not imply any guarantee of delivery to
  703.    the destination host(s), or even any assurance that the message will
  704.    not be intentionally discarded by the network.  They are sent
  705.    primarily to facilitate buffer management in the host.
  706.  
  707.    To reduce the number of A/R messages exchanged, a single A/R
  708.    indication can be returned for multiple (lower numbered) previously
  709.    unacknowledged messages.  Explicit acceptance of message number N
  710.    implies implicit acceptance of outstanding messages with numbers N-1,
  711.    N-2, etc., according to the definition of acceptance outlined above.
  712.    Analogous interpretation of the refusal message number allows the
  713.    receiver of a group of messages to reject them as a group when they
  714.    all are being refused for the same reason.  As a further efficiency
  715.    measure, HAP permits aggregation of any mix of A/R indications into a
  716.    single A/R control message.  Such a message might be used, for
  717.    example, to reject a group of messages where the refusal code on each
  718.    is different.
  719.  
  720.    In some circumstances the overhead associated with processing A/R
  721.    messages may prove unattractive.  For these cases, it is possible to
  722.    disable the A/R mechanism and operate the HAP interface in a purely
  723.    discard mode.  The ability to effect this on a link basis has already
  724.    been noted (see Sections 2 and 8).  In addition, messages with
  725.    sequence number zero are taken as messages for which the A/R
  726.    mechanism is selectively disabled.  To permit critical feedback, even
  727.  
  728.  
  729.  
  730. Edmond                                                         [Page 13]
  731.  
  732. RFC 1221                          HAP2                        April 1991
  733.  
  734.  
  735.    when operating in discard mode, HAP defines an "Unnumbered Response"
  736.    control message.  Flow control information, and other information
  737.    which cannot be sent as an A/R indication, is sent in an Unnumbered
  738.    Response control message.  The format of this type of message is
  739.    illustrated in Figure 5.
  740.  
  741.    The format shown in Figure 3 is used both for A/R indications that
  742.    are piggybacked on data messages (word 2), and for aggregated A/R
  743.    information in A/R control messages.  The format of A/R control
  744.    messages is shown in Figure 4.
  745.  
  746.  
  747.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  748.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  749.                |AR|    REFUSAL CODE    |  A/R MESSAGE NUMBER   |
  750.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  751.  
  752.  
  753.                           ACCEPTANCE/REFUSAL WORD
  754.                                  Figure 3
  755.  
  756.  
  757.  
  758.      [0]       Acceptance/Refusal Type.  This field identifies whether
  759.                A/R information is an acceptance or a refusal.
  760.  
  761.                     0 = Acceptance
  762.                     1 = Refusal
  763.  
  764.      [1-7]     Refusal Code.  When the Acceptance/Refusal Type = 1,
  765.                this field gives the Refusal Code.
  766.  
  767.                     0 = Priority not being accepted
  768.                     1 = Source WPS congestion
  769.                     2 = Destination WPS congestion
  770.                     3 = Destination host dead
  771.                     4 = Destination WPS dead
  772.                     5 = Illegal destination host address
  773.                     6 = Destination host access not allowed
  774.                     7 = Illegal source host address
  775.                     8 = Message lost in access link
  776.                     9 = Invalid stream ID
  777.                    10 = Illegal source host for stream ID
  778.                    11 = Message length too long
  779.                    12 = Stream message too early
  780.                    13 = Illegal control message type
  781.                    14 = Illegal refusal code in A/R
  782.                    15 = Can't implement loop
  783.  
  784.  
  785.  
  786. Edmond                                                         [Page 14]
  787.  
  788. RFC 1221                          HAP2                        April 1991
  789.  
  790.  
  791.                    16 = Destination host congestion
  792.                    17 = Delivery refused
  793.                    18 = Odd byte length packet (not allowed)
  794.                    19 = Invalid stream time-to-live value
  795.                    20 = "Reliability length" exceeds message length
  796.  
  797.      [8-15]    A/R Message Number.  This field contains the number of
  798.                the message to which this acceptance/refusal refers.
  799.                It also applies to all outstanding messages with
  800.                earlier numbers.  Note that this field can never be
  801.                zero since a message number of zero implies that the
  802.                A/R mechanism is disabled.
  803.  
  804.  
  805.  
  806.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  807.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  808.      0         | 1|LB|GOPRI|     0     |  LENGTH   |     1     |
  809.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  810.      1         |                HEADER CHECKSUM                |
  811.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  812.                |                                               |
  813.      2-N       :                     A/R's                     :
  814.                |                                               |
  815.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  816.  
  817.  
  818.                         ACCEPTANCE/REFUSAL MESSAGE
  819.                                  Figure 4
  820.  
  821.  
  822.  
  823.      0[0]      Message Class = 1 (Control Message).
  824.  
  825.      0[1]      Loopback indicator.
  826.  
  827.      0[2-3]    Go-Priority.
  828.  
  829.      0[4-7]    Reserved.
  830.  
  831.      0[8-11]   Message Length.  This field contains the total length
  832.                of this message in words (N+1).
  833.  
  834.      0[12-15]  Control Message Type = 1 (Acceptance/Refusal).
  835.  
  836.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  837.                the 2's-complement sum of words 0-N (excluding the
  838.                checksum word itself).
  839.  
  840.  
  841.  
  842. Edmond                                                         [Page 15]
  843.  
  844. RFC 1221                          HAP2                        April 1991
  845.  
  846.  
  847.      2[0-15]   Acceptance/Refusal Word.
  848.  
  849.      3-N       Additional Acceptance/Refusal Words (optional).
  850.  
  851.  
  852.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  853.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  854.      0         | 1|LB|GOPRI|     0     | RES-CODE  |     5     |
  855.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  856.      1         |                HEADER CHECKSUM                |
  857.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  858.      2         |                 RESPONSE INFO                 |
  859.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  860.      3         |                 RESPONSE INFO                 |
  861.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  862.  
  863.  
  864.                             UNNUMBERED RESPONSE
  865.                                  Figure 5
  866.  
  867.  
  868.  
  869.      0[0]      Message Class = 1 (Control Message).
  870.  
  871.      0[1]      Loopback indicator.
  872.  
  873.      0[2-3]    Go-Priority.
  874.  
  875.      0[4-7]    Reserved.
  876.  
  877.      0[8-11]   Response Code.
  878.  
  879.                     3 = Destination unreachable
  880.                     5 = Illegal destination host address
  881.                     7 = Illegal source host address
  882.                     9 = Nonexistent stream ID
  883.                    10 = Illegal stream ID
  884.                    13 = Protocol violation
  885.                    15 = Can't implement loop
  886.  
  887.      0[12-15]  Control Message Type = 5 (Unnumbered Response).
  888.  
  889.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  890.                the 2's-complement sum of words 0-3 (excluding the
  891.                checksum word itself).
  892.  
  893.      2[0-15]   Response Information. If Response Code is:
  894.  
  895.  
  896.  
  897.  
  898. Edmond                                                         [Page 16]
  899.  
  900. RFC 1221                          HAP2                        April 1991
  901.  
  902.  
  903.                     3: Destination Host Address
  904.                     5: Destination Host Address
  905.                     7: Source Host Address
  906.                     9: Stream ID (right justified)
  907.                    10: Stream ID (right justified)
  908.                    13: Word 0 of offending message
  909.                    15: Word 0 of Loopback Request message
  910.  
  911.      3[0-15]   Response Information. If Response Code is:
  912.  
  913.                     3,5,7, or 9: Undefined
  914.                     10: Source Host Address
  915.                     13: Word 3 of offending message, or 0 if no word 3
  916.                     15: Word 2 of Loopback Request message
  917.  
  918. 6. The Service Agent
  919.  
  920.    Allocation of network resources, such as streams and groups, is
  921.    accomplished via an exchange of datagram messages, called Setup
  922.    messages, between the user host and the Service Agent (network
  923.    address zero).  Setup operations include reserving, allocating,
  924.    modifying, freeing, and deallocating resources.  The Service Agent
  925.    causes the requested action to be carried out and serves as the
  926.    intermediary between the user and the rest of the network.  In the
  927.    process of implementing the requested action, various network data
  928.    bases are updated to reflect the current state of the referenced
  929.    resource.  The Service Agent also permits a host to inquire about
  930.    resources it owns using Information Request and Information Reply
  931.    messages.
  932.  
  933.    A setup interaction initiated by a host involves a 3-way exchange
  934.    where: (1) the requesting host sends a Setup Request to the Service
  935.    Agent, (2) the Service Agent returns a Setup Reply to the requesting
  936.    host, and (3) the requesting host returns a Setup Acknowledgment to
  937.    the Service Agent.  This procedure is used to ensure reliable
  938.    transmission of Setup Requests and Replies.  In order to allow more
  939.    than one Setup Request message from a host to be outstanding, each
  940.    Request is assigned a unique Request ID.  The associated Reply and
  941.    subsequent Acknowledgment are identified by the Request ID that they
  942.    contain.  The requesting host should receive a reply to a setup
  943.    request within 3 seconds.  The actual delay will depend on the nature
  944.    of the request and the topology of the network.  For simple networks,
  945.    the delay will often be less than one second.  The requesting host
  946.    should respond to a Reply with a Setup Acknowledgment within one
  947.    second.
  948.  
  949.    Setup exchanges initiated by the Service Agent involve a two-way
  950.    exchange where: (1) the Service Agent sends a Notification to
  951.  
  952.  
  953.  
  954. Edmond                                                         [Page 17]
  955.  
  956. RFC 1221                          HAP2                        April 1991
  957.  
  958.  
  959.    affected hosts, and (2) the hosts return a Setup Acknowledgment to
  960.    the Service Agent.  Notifications are used to inform a host of
  961.    changes in the status of a network resource.  In order to allow more
  962.    than one Notification to be outstanding, each is assigned a unique
  963.    Notification ID.  The Setup Acknowledgment returned by the notified
  964.    host to the Service Agent must contain the Notification ID.  The host
  965.    should respond within one second.
  966.  
  967.    An information query is initiated by a host and involves a two-way
  968.    exchange where: (1) the host sends an Information Request message to
  969.    the Service Agent, and (2) the Service Agent sends back an
  970.    Information Reply.  There is no acknowledgment mechanism, since this
  971.    request does not change any resource allocation.  Furthermore, if
  972.    there is an error in the request, only one response will be sent by
  973.    the WPS, and the WPS will make no effort to check for or retransmit
  974.    lost responses.  It is the responsibility of the host to wait a
  975.    certain amount of time and then determine that an unanswered
  976.    information request has been lost and to resend it.  (The time
  977.    necessary to answer such a request is usually much less than one
  978.    second.)  The WPS will return the message ID of the information
  979.    request in the information reply message.
  980.  
  981.           The general format of all Service Agent messages is:
  982.  
  983.                          <DATAGRAM MESSAGE HEADER>
  984.                           <SERVICE AGENT HEADER>
  985.                               <MESSAGE BODY>
  986.  
  987.    The Protocol ID field in the datagram message header must be
  988.    HAP_PROTO_SETUP (1) (see Appendix C) for messages sent to the Service
  989.    Agent and will be HAP_PROTO_SETUP in messages received from the
  990.    Service Agent.  The Service Agent does not recognize or support use
  991.    of other higher level protocols (e.g., IP), in setup messages, and
  992.    will discard messages containing such headers.
  993.  
  994.    Illustrations of message formats below show only the Service Agent
  995.    Header header and message body and do not include the datagram
  996.    message header.  As a reminder that the datagram header is not
  997.    included, word offsets are prefixed with an "S".
  998.  
  999.    The format of the Service Agent Header is illustrated in Figure 6.
  1000.    The body of the message will depend on the particular message type.
  1001.    Stream Request and Reply messages are described in Section 6.1.
  1002.    Group Request and Reply messages are described in Section 6.2.  The
  1003.    format of Notifications is described in Section 6.3, and Setup
  1004.    Acknowledgments are described in Section 6.4.  Information Request
  1005.    and Reply messages are described in Section 6.5.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Edmond                                                         [Page 18]
  1011.  
  1012. RFC 1221                          HAP2                        April 1991
  1013.  
  1014.  
  1015.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1016.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1017.      S0        |     MESSAGE TYPE      |          CODE         |
  1018.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1019.      S1        |                    CHECKSUM                   |
  1020.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1021.      S2        |                   MESSAGE ID                  |
  1022.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1023.  
  1024.  
  1025.                            SERVICE AGENT HEADER
  1026.                                  Figure 6
  1027.  
  1028.  
  1029.      S0[0-7]   Message Type.  This field determines the type of
  1030.                message.
  1031.  
  1032.                     0 = Setup Acknowledgment
  1033.                     1 = Setup Request
  1034.                     2 = Setup Reply
  1035.                     3 = Notification
  1036.                     4 = Information Request
  1037.                     5 = Information Reply
  1038.  
  1039.      S0[8-15]  Code.  For Setup Requests, this field identifies the
  1040.                request type.
  1041.  
  1042.                     1 = Create group (multicast) address
  1043.                     2 = Delete group address
  1044.                     3 = Join group
  1045.                     4 = Leave group
  1046.                     5 = Create stream
  1047.                     6 = Delete stream
  1048.                     7 = Change stream
  1049.                     8 = Create shared stream
  1050.                     9 = Delete all streams owned by this host
  1051.                    10 = Add member to group
  1052.                    11 = Remove member from group
  1053.  
  1054.                For Setup Replies, this field provides the Reply Code.
  1055.                Some of the Reply Codes can be returned to any setup
  1056.                request and others are request specific.
  1057.  
  1058.                     0 = Group or stream created
  1059.                     1 = Group or stream deleted
  1060.                     2 = Host added to group
  1061.                     3 = Host deleted from group
  1062.                     4 = Stream changed
  1063.  
  1064.  
  1065.  
  1066. Edmond                                                         [Page 19]
  1067.  
  1068. RFC 1221                          HAP2                        April 1991
  1069.  
  1070.  
  1071.                     5 = (Reserved)
  1072.                     6 = Request type invalid or unsupported
  1073.                     7 = (Reserved)
  1074.                     8 = Network trouble
  1075.                     9 = Bad group key
  1076.                    10 = Group address/stream ID nonexistent
  1077.                    11 = Not member of group/not creator of stream
  1078.                    12 = Stream precedence not being accepted
  1079.                    13 = (Reserved)
  1080.                    14 = (Reserved)
  1081.                    15 = (Reserved)
  1082.                    16 = Unable to add all the new hosts
  1083.                    17 = Insufficient network resources
  1084.                    18 = Requested bandwidth too large
  1085.                    19 = (Reserved)
  1086.                    20 = (Reserved)
  1087.                    21 = Maximum messages per interval too small
  1088.                    22 = Reply lost in network
  1089.                    23 = Illegal priority or precedence value
  1090.                    24 = Invalid address provided
  1091.  
  1092.                For Notifications, this field contains the Notification
  1093.                Type.  (See Section 6.3.)
  1094.  
  1095.                For Setup Acknowledgments, this field contains the
  1096.                Acknowledgment Type.  (See Section 6.4.)
  1097.  
  1098.                For Information Requests, this field contains the
  1099.                request type.  (See Section 6.5.)
  1100.  
  1101.                For Information Replies, this field contains the reply
  1102.                type.  (See Section 6.5.)
  1103.  
  1104.      S1[0-15]  Checksum.  The checksum is the 2's-complement of the
  1105.                2's-complement sum of the words in the Service Agent
  1106.                Header (excluding the checksum word itself) and the
  1107.                message body.  Messages received with bad checksums
  1108.                must be discarded.
  1109.  
  1110.      S2[0-15]  Message ID.  This field is assigned by the host to
  1111.                uniquely identify outstanding requests (Request ID) and
  1112.                by the Service Agent to uniquely identify outstanding
  1113.                notifications (Notification ID).
  1114.  
  1115. 6.1. Stream Setup Messages
  1116.  
  1117.    Streams provide a means of reserving network resources for the
  1118.    delivery of traffic at a specified maximum throughput to a specified
  1119.  
  1120.  
  1121.  
  1122. Edmond                                                         [Page 20]
  1123.  
  1124. RFC 1221                          HAP2                        April 1991
  1125.  
  1126.  
  1127.    list of recipients.  Traffic sent via a stream has priority over all
  1128.    non-stream traffic, and is delivered with the minimum end-to-end
  1129.    delay possible.  Hosts use streams to support applications that have
  1130.    predictable traffic loads (such as packet voice or video or other
  1131.    continuous media traffic) or that require minimum transmission delay
  1132.    and lowest delay variance.  Streams are typically used for traffic
  1133.    flows of moderate to long duration, where the cost of performing a
  1134.    stream Setup is acceptable.
  1135.  
  1136.    Streams must be set up before stream data messages can flow.  The
  1137.    stream setup messages, each of which has a Request and a Reply, are
  1138.    Create Stream, Delete Stream, Change Stream, and Delete All Streams.
  1139.    (Create Shared Stream Request is a planned future addition to the
  1140.    protocol.)  The use of these messages is illustrated in the scenario
  1141.    of exchanges between a host and the Service Agent shown in Figure 7
  1142.    where the host establishes a stream, sends some data, modifies the
  1143.    stream characteristics, sends some more data, and finally closes down
  1144.    the stream.  Not illustrated, but implicit in this scenario, are the
  1145.    optional A/R indications associated with each of the stream Setup
  1146.    messages.
  1147.  
  1148.  
  1149.                                               Service     Other
  1150.                                      Host      Agent      hosts
  1151.  
  1152.           Create Stream Request        ---------->
  1153.           Create Stream Reply          <----------
  1154.           Reply Acknowledgment         ---------->
  1155.           Stream Messages              --------------------->
  1156.              :   :
  1157.           Change Stream Request        ---------->
  1158.           Change Stream Reply          <----------
  1159.           Reply Acknowledgment         ---------->
  1160.           Stream Messages              --------------------->
  1161.              :   :
  1162.           Delete Stream Request        ---------->
  1163.           Delete Stream Reply          <----------
  1164.           Reply Acknowledgment         ---------->
  1165.  
  1166.                               STREAM EXAMPLE
  1167.                                  Figure 7
  1168.  
  1169.    Streams have eight characteristic properties which are selected at
  1170.    stream setup time.  These properties are: (1) data words per time
  1171.    interval, (2) time interval, (3) reliability, (4) reliability length,
  1172.    (5) precedence, (6) maximum messages per interval, (7) the list of
  1173.    recipients, and (8) the set of other streams with which this stream
  1174.    shares resources.  To establish a stream, the host sends the Create
  1175.  
  1176.  
  1177.  
  1178. Edmond                                                         [Page 21]
  1179.  
  1180. RFC 1221                          HAP2                        April 1991
  1181.  
  1182.  
  1183.    Stream Request message (Figure 8) to the Service Agent.  After the
  1184.    network has processed the Create Stream Request, the Service Agent
  1185.    will reply with a Create Stream Reply message (Figure 9).  If the
  1186.    reply code in the Create Stream Reply indicates that the stream has
  1187.    been created successfully, the host may proceed to transmit stream
  1188.    data messages after sending a Reply Acknowledgment.
  1189.  
  1190.    During the lifetime of a stream, the host which created it may decide
  1191.    that some of its characteristic properties should be modified.  All
  1192.    but one of the properties can be modified using the Change Stream
  1193.    Request message (Figure 10).  The one property that cannot be changed
  1194.    is whether or not the stream is willing to share its resources with
  1195.    other streams.  After the network has processed the Change Stream
  1196.    Request, the Service Agent will respond by sending a Change Stream
  1197.    Reply (Figure 11) to the host.  A host requesting a reduced channel
  1198.    allocation should decrease its sending rate immediately without
  1199.    waiting for receipt of the Change Stream Reply.  A host requesting an
  1200.    increased allocation should not proceed to transmit according to the
  1201.    new set of parameters without first having received a Reply Code
  1202.    indicating that the requested change has taken effect.
  1203.  
  1204.    When the host no longer needs the stream it created, it should first
  1205.    stop sending traffic via the stream and then send the Service Agent a
  1206.    Delete Stream Request message (Figure 12).  After the network has
  1207.    processed the Delete Stream Request, the Service Agent will respond
  1208.    by sending a Delete Stream Reply (Figure 13) to the host.
  1209.  
  1210.    If the host has crashed or restarted, it may no longer know what
  1211.    streams it owns.  The host may use an Information Request (see
  1212.    Section 6.5) to determine what streams it owns, or the host may use a
  1213.    Delete All Streams Request (Figure 14) to discard whatever stream
  1214.    resources it may own.  The format for the Delete All Streams Reply is
  1215.    shown in Figure 15.
  1216.  
  1217.    Note that streams, like all other resources allocated by the Service
  1218.    Agent, may be reclaimed by the network if unused.  Currently, if no
  1219.    traffic is sent to a stream in a 6 minute interval, and if the owner
  1220.    of the steam is down or unreachable, the stream may be deleted.
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Edmond                                                         [Page 22]
  1235.  
  1236. RFC 1221                          HAP2                        April 1991
  1237.  
  1238.  
  1239.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1240.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1241.      S0        |           1           |           5           |
  1242.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1243.      S1        |                 SETUP CHECKSUM                |
  1244.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1245.      S2        |                  REQUEST ID                   |
  1246.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1247.      S3        |  MAX MES  | PRE | INT | RLY |      RLEN       |
  1248.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1249.      S4        |            DATA WORDS PER INTERVAL            |
  1250.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1251.      S5        |                 INTERVAL                      |
  1252.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1253.      S6        |           0           |  ADDRESS LIST LENGTH  |
  1254.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1255.                |                                               |
  1256.      S7-SN     :            DESTINATION ADDRESS LIST           :
  1257.                |                                               |
  1258.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1259.  
  1260.  
  1261.                            CREATE STREAM REQUEST
  1262.                                  Figure 8
  1263.  
  1264.  
  1265.  
  1266.      S0[0-7]   Setup Type = 1 (Request).
  1267.  
  1268.      S0[8-15]  Request Type = 5 (Create Stream).
  1269.  
  1270.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1271.  
  1272.      S2[0-15]  Request ID.
  1273.  
  1274.      S3[0-3]   Maximum Messages Per Interval (1-15).  This field
  1275.                specifies the maximum number of stream messages the
  1276.                host will deliver to the WPS in any single stream
  1277.                interval.
  1278.  
  1279.      S3[4-5]   Precedence.  This field specifies the precedence of the
  1280.                stream.  When there are insufficient network resources
  1281.                to support all the requested streams, requests for
  1282.                higher precedence streams will preempt existing lower
  1283.                precedence streams, and requests for streams with
  1284.                insufficient precedence will be rejected.  Medium
  1285.                precedence is recommended as the default choice.
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Edmond                                                         [Page 23]
  1291.  
  1292. RFC 1221                          HAP2                        April 1991
  1293.  
  1294.  
  1295.                     0 = Low Precedence
  1296.                     1 = Medium Precedence
  1297.                     2 = High Precedence
  1298.  
  1299.      S3[6-7]   Interval.  This field specifies the interval, in
  1300.                multiples of 21.22 milliseconds.  (For backward
  1301.                compatibility only.  New applications should use 3.
  1302.                Use of this field to specify an interval is being
  1303.                phased out.)
  1304.  
  1305.                     0 =  21.22 milliseconds
  1306.                     1 =  42.44 milliseconds
  1307.                     2 =  84.88 milliseconds
  1308.                     3 =  use interval in word S5
  1309.  
  1310.      S3[8-9]   Reliability.  This field specifies the basic bit-error
  1311.                rate requirement for the data portion of all messages
  1312.                in the stream.  The exact error rate obtained by each
  1313.                choice is not specified.
  1314.  
  1315.                     0 = Low Reliability
  1316.                     1 = Medium-Low Reliability
  1317.                     2 = Medium-High Reliability
  1318.                     3 = High Reliability
  1319.  
  1320.      S3[10-15] Reliability Length.  This field specifies how many
  1321.                words beyond the stream message header should be
  1322.                transmitted at maximum reliability for all messages in
  1323.                the host stream.
  1324.  
  1325.      S4[0-15]  Data words per interval.  This field specifies the
  1326.                maximum number of 16-bit words of this stream's data
  1327.                the network will need to carry during each interval,
  1328.                not counting HAP stream message header words.  The
  1329.                stream data may be carried in however many messages (up
  1330.                to MAX MES) in each interval the host chooses.
  1331.  
  1332.      S5[0-15]  Interval (125 microsecond units).  This field specifies
  1333.                the time interval over which the <data words per
  1334.                interval> data in <max mes> messages will be sent.  For
  1335.                backward compatibility, an interval of 0 selects an
  1336.                interval of 169.76 milliseconds.  This field is ignored
  1337.                unless the INT field is 3.
  1338.  
  1339.      S6[0-7]   Reserved.  Must be zero.
  1340.  
  1341.      S6[8-15]  Destination address list length.  This field specifies
  1342.                the number of entries in the Destination Address List
  1343.  
  1344.  
  1345.  
  1346. Edmond                                                         [Page 24]
  1347.  
  1348. RFC 1221                          HAP2                        April 1991
  1349.  
  1350.  
  1351.                field.  Allowed values are 1-8.
  1352.  
  1353.      S7-SN     Destination address list.  This list must specify, at
  1354.                least indirectly, all the intended recipients of this
  1355.                stream's traffic.  At least one destination address
  1356.                must be supplied.  Any valid network address,
  1357.                specifically including group addresses, may be used
  1358.                (except the Service Agent's address, 0).  Messages sent
  1359.                in the stream are not limited to using the HAP
  1360.                addresses listed.  E.g., if the list consists of only
  1361.                group address G, and host A is a member of G, a stream
  1362.                message may be sent to A, which was not in the list.
  1363.  
  1364.    Caution: Group membership is only evaluated at setup time.  Changes
  1365.    in group membership do not cause the stream to be modified.
  1366.  
  1367.    Caution: Stream creation involves allocation of specific network
  1368.    resources along specific routes for delivery of that traffic.  A
  1369.    stream message sent to hosts other than those specified via Setup
  1370.    will probably be undeliverable.  A stream message to a group address
  1371.    that has gained new members since the stream's last Setup may be
  1372.    undeliverable to the new members.
  1373.  
  1374.  
  1375.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1376.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1377.      S0        |           2           |      REPLY CODE       |
  1378.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1379.      S1        |                 SETUP CHECKSUM                |
  1380.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1381.      S2        |                  REQUEST ID                   |
  1382.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1383.      S3        |        0        |         STREAM ID           |
  1384.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1385.      S4        |        0        |     ADDRESS LIST LENGTH     |
  1386.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1387.                |                                               |
  1388.      S5-SN     :                 ADDRESS LIST                  :
  1389.                |                                               |
  1390.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1391.  
  1392.  
  1393.                             CREATE STREAM REPLY
  1394.                                  Figure 9
  1395.  
  1396.  
  1397.  
  1398.      S0[0-7]   Setup Type = 2 (Reply).
  1399.  
  1400.  
  1401.  
  1402. Edmond                                                         [Page 25]
  1403.  
  1404. RFC 1221                          HAP2                        April 1991
  1405.  
  1406.  
  1407.      S0[8-15]  Reply Code.  Any reply other than "Stream created"
  1408.                means the stream was not created.
  1409.  
  1410.                     0 = Stream created
  1411.                     8 = Network trouble
  1412.                    12 = Stream precedence not being accepted
  1413.                    17 = Insufficient network resources
  1414.                    18 = Requested bandwidth too large
  1415.                    21 = Max. messages per interval too small
  1416.                    22 = Reply lost in network
  1417.                    23 = Illegal precedence value
  1418.                    24 = Invalid destination address in list
  1419.  
  1420.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1421.  
  1422.      S2[0-15]  Request ID.
  1423.  
  1424.      S3[0-5]   Reserved.  Must be zero.
  1425.  
  1426.      S3[6-15]  Stream ID.  This field contains a stream ID assigned by
  1427.                the network.  It must be included in all stream data
  1428.                messages sent by the host to allow the WPS to associate
  1429.                the message with stored stream characteristics and the
  1430.                resources reserved for that stream's traffic.
  1431.  
  1432.      S4[0-5]   Reserved.  Must be zero.
  1433.  
  1434.      S4[6-15]  Address list length.  The number of entries in the
  1435.                Address List field.
  1436.  
  1437.      S5-SN     Address list.  This contains the destination addresses
  1438.                from the Create Stream Request that were invalid or
  1439.                unreachable.  Unreachable destinations are listed as a
  1440.                group if every member of the group was unreachable, or
  1441.                individually otherwise; i.e., group addresses are
  1442.                expanded and the unreachable members are included in
  1443.                the list.  The list of unreachable destinations will be
  1444.                truncated, if needed, to limit this Reply to a single,
  1445.                maximum length HAP message.
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Edmond                                                         [Page 26]
  1459.  
  1460. RFC 1221                          HAP2                        April 1991
  1461.  
  1462.  
  1463.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1464.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1465.      S0        |           1           |           7           |
  1466.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1467.      S1        |                 SETUP CHECKSUM                |
  1468.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1469.      S2        |                  REQUEST ID                   |
  1470.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1471.      S3        |        0        |         STREAM ID           |
  1472.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1473.      S4        |  MAX MES  | PRE | INT | RLY |      RLEN       |
  1474.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1475.      S5        |            DATA WORDS PER INTERVAL            |
  1476.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1477.      S6        |                   INTERVAL                    |
  1478.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1479.      S7        |           0           |  ADDRESS LIST LENGTH  |
  1480.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1481.                |                                               |
  1482.      S8-SN     :            DESTINATION ADDRESS LIST           :
  1483.                |                                               |
  1484.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1485.  
  1486.  
  1487.                            CHANGE STREAM REQUEST
  1488.                                  Figure 10
  1489.  
  1490.  
  1491.  
  1492.      S0[0-7]   Setup Type = 1 (Request).
  1493.  
  1494.      S0[8-15]  Request Type = 7 (Change Stream).
  1495.  
  1496.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1497.  
  1498.      S2[0-15]  Request ID.
  1499.  
  1500.      S3[0-5]   Reserved.  Must be zero.
  1501.  
  1502.      S3[6-15]  Stream ID.
  1503.  
  1504.      S4[0-3]   New Maximum Messages Per Interval.
  1505.  
  1506.      S4[4-5]   New Precedence.
  1507.  
  1508.      S4[6-7]   New Interval selection.
  1509.  
  1510.      S4[8-9]   New Reliability.
  1511.  
  1512.  
  1513.  
  1514. Edmond                                                         [Page 27]
  1515.  
  1516. RFC 1221                          HAP2                        April 1991
  1517.  
  1518.  
  1519.      S4[10-15] New Reliability Length.
  1520.  
  1521.      S5[0-15]  New Data Words Per Interval.
  1522.  
  1523.      S6[0-15]  New Interval (ignored unless INT = 3).
  1524.  
  1525.      S7[0-7]   Reserved.  Must be zero.
  1526.  
  1527.      S7[8-15]  Destination Address List length.  This field specifies
  1528.                the number of entries in the new Destination Address
  1529.                List.  Allowed values are 0-8.  Use zero (indicating no
  1530.                addresses in the list) to avoid changing the list of
  1531.                recipient hosts.
  1532.  
  1533.      S8-SN     New Destination Address List.  The new, complete, list
  1534.                of recipient hosts.  Membership of group addresses is
  1535.                evaluated at setup execution time.  Subsequent changes
  1536.                in group membership do not cause the stream to be
  1537.                modified.  Note that using the same destination address
  1538.                list in the Change Stream Request as was used in the
  1539.                Create Stream Request can result in a change in the
  1540.                list of recipient hosts if membership in a group has
  1541.                changed.
  1542.  
  1543.  
  1544.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1545.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1546.      S0        |           2           |      REPLY CODE       |
  1547.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1548.      S1        |                 SETUP CHECKSUM                |
  1549.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1550.      S2        |                  REQUEST ID                   |
  1551.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1552.      S3        |        0        |     ADDRESS LIST LENGTH     |
  1553.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1554.                |                                               |
  1555.      S4-SN     :                 ADDRESS LIST                  :
  1556.                |                                               |
  1557.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1558.  
  1559.  
  1560.                             CHANGE STREAM REPLY
  1561.                                  Figure 11
  1562.  
  1563.  
  1564.  
  1565.      S0[0-7]   Setup Type = 2 (Reply).
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Edmond                                                         [Page 28]
  1571.  
  1572. RFC 1221                          HAP2                        April 1991
  1573.  
  1574.  
  1575.      S0[8-15]  Reply Code.  The number in parentheses indicates the
  1576.                processing phase at the time of the error (see Caution
  1577.                below).  Phase zero and phase one errors leave the
  1578.                stream unchanged; errors from later phases may leave
  1579.                the stream partially modified.
  1580.  
  1581.                     4 = Stream changed
  1582.                     8 = (1) Network trouble
  1583.                    10 = (0) Stream ID nonexistent
  1584.                    11 = (0) Not creator of stream
  1585.                    12 = (0) Stream precedence not being accepted
  1586.                    16 = (3) Unable to add all the new recipients
  1587.                    17 = (2) Insufficient network resources
  1588.                    18 = (2) Requested bandwidth too large
  1589.                    21 = (0) Maximum messages per interval too small
  1590.                    22 = (2) Reply lost in network
  1591.                    23 = (0) Illegal precedence value
  1592.                    24 = (0) Invalid destination address in list
  1593.  
  1594.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1595.  
  1596.      S2[0-15]  Request ID.
  1597.  
  1598.      S3[0-5]   Reserved.  Must be zero.
  1599.  
  1600.      S3[6-15]  Address list length.  This field specifies the number
  1601.                of addresses in the Address List.
  1602.  
  1603.      S4-SN     Address list.  This contains the destination addresses
  1604.                from the Change Stream Request that were invalid (phase
  1605.                0 errors) or unreachable (phase 3 errors).  Unreachable
  1606.                destinations are listed as a group if every member of
  1607.                the group was unreachable, or individually otherwise;
  1608.                i.e., group addresses are expanded and the unreachable
  1609.                members are included in the list.  The list of
  1610.                unreachable destinations will be truncated, if needed,
  1611.                to limit this Reply to a single, maximum length HAP
  1612.                message.
  1613.  
  1614.      Caution: The Change Stream Reply will indicate failure if any
  1615.      aspect of the requested changes did not occur.  However, the
  1616.      stream may have been partially modified.  Processing is performed
  1617.      in the following phases:
  1618.          0: check for invalid requests;
  1619.          1: drop former recipients that are not in the latest list;
  1620.          2: increase or decrease the stream's bandwidth allocation
  1621.              (decreases are normally successful); then
  1622.          3: extend the stream to any new recipients.
  1623.  
  1624.  
  1625.  
  1626. Edmond                                                         [Page 29]
  1627.  
  1628. RFC 1221                          HAP2                        April 1991
  1629.  
  1630.  
  1631.      If phase 2 fails, phase 3 is not performed, the Reply Code will
  1632.      indicate an error and the stream parameters will be unchanged.
  1633.      If phase 3 fails, the Address List will contain the destinations,
  1634.      if any, from the latest list that the stream does not reach.
  1635.      Phase 1 only fails if the stream has been suspended (see
  1636.      Notifications) or the WPS is experiencing network connectivity
  1637.      problems.
  1638.  
  1639.  
  1640.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1641.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1642.      S0        |           1           |           6           |
  1643.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1644.      S1        |                 SETUP CHECKSUM                |
  1645.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1646.      S2        |                  REQUEST ID                   |
  1647.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1648.      S3        |        0        |         STREAM ID           |
  1649.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1650.  
  1651.  
  1652.                            DELETE STREAM REQUEST
  1653.                                  Figure 12
  1654.  
  1655.  
  1656.  
  1657.  
  1658.      S0[0-7]   Setup Type = 1 (Request).
  1659.  
  1660.      S0[8-15]  Request Type = 6 (Delete Stream).
  1661.  
  1662.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1663.  
  1664.      S2[0-15]  Request ID.
  1665.  
  1666.      S3[0-5]   Reserved.  Must be zero.
  1667.  
  1668.      S3[6-15]  Stream ID.
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Edmond                                                         [Page 30]
  1683.  
  1684. RFC 1221                          HAP2                        April 1991
  1685.  
  1686.  
  1687.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1688.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1689.      S0        |           2           |      REPLY CODE       |
  1690.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1691.      S1        |                 SETUP CHECKSUM                |
  1692.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1693.      S2        |                  REQUEST ID                   |
  1694.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1695.  
  1696.  
  1697.                             DELETE STREAM REPLY
  1698.                                  Figure 13
  1699.  
  1700.  
  1701.      S0[0-7]   Setup Type = 2 (Reply).
  1702.  
  1703.      S0[8-15]  Reply Code.  If the request was valid, the Service
  1704.                Agent will have marked the stream for deletion even if
  1705.                the stream resources have not actually been deleted
  1706.                yet.
  1707.  
  1708.                     1 = Stream deleted
  1709.                    10 = Stream ID nonexistent
  1710.                    11 = Not creator of stream
  1711.  
  1712.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1713.  
  1714.      S2[0-15]  Request ID.
  1715.  
  1716.  
  1717.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1718.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1719.      S0        |           1           |           9           |
  1720.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1721.      S1        |                 SETUP CHECKSUM                |
  1722.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1723.      S2        |                  REQUEST ID                   |
  1724.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1725.  
  1726.  
  1727.                         DELETE ALL STREAMS REQUEST
  1728.                                  Figure 14
  1729.  
  1730.  
  1731.  
  1732.      S0[0-7]   Setup Type = 1 (Request).
  1733.  
  1734.      S0[8-15]  Request Type = 9 (Delete All Streams).
  1735.  
  1736.  
  1737.  
  1738. Edmond                                                         [Page 31]
  1739.  
  1740. RFC 1221                          HAP2                        April 1991
  1741.  
  1742.  
  1743.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1744.  
  1745.      S2[0-15]  Request ID.
  1746.  
  1747.  
  1748.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1749.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1750.      S0        |           2           |      REPLY CODE       |
  1751.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1752.      S1        |                 SETUP CHECKSUM                |
  1753.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1754.      S2        |                  REQUEST ID                   |
  1755.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1756.  
  1757.  
  1758.                          DELETE ALL STREAMS REPLY
  1759.                                  Figure 15
  1760.  
  1761.  
  1762.      S0[0-7]   Setup Type = 2 (Reply).
  1763.  
  1764.      S0[8-15]  Reply Code.  The Service Agent will have marked all of
  1765.                the host's streams for deletion, even if the stream
  1766.                resources have not actually been deleted yet.
  1767.  
  1768.                     1 = Streams deleted
  1769.  
  1770.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1771.  
  1772.      S2[0-15]  Request ID.
  1773.  
  1774. 6.2. Group Setup Messages
  1775.  
  1776.    Group (multicast) addressing allows a host to send the same message
  1777.    to N different hosts without having to send N copies of the message.
  1778.    The network duplicates the message as required.  In addition to
  1779.    reducing the burden on the originating host, multicasting reduces the
  1780.    load on the network because the network no longer has to carry the
  1781.    duplicates along the common portions of the paths between the source
  1782.    and destinations.  Multicasting is particularly recommended for
  1783.    multi-site conferencing and distributed simulations.
  1784.  
  1785.    Group addresses are dynamically created and deleted via setup
  1786.    messages exchanged between the hosts and the Service Agent.
  1787.    Membership in a group may be any arbitrary subset of the network
  1788.    hosts.  A datagram message or stream message addressed to a group is
  1789.    delivered to all hosts that are members of that group (exception:
  1790.    stream messages sent to a group address that includes hosts the
  1791.  
  1792.  
  1793.  
  1794. Edmond                                                         [Page 32]
  1795.  
  1796. RFC 1221                          HAP2                        April 1991
  1797.  
  1798.  
  1799.    stream was not set up to reach).  The group setup messages, each of
  1800.    which has a Request and a Reply, are Create Group, Delete Group, Join
  1801.    Group, Leave Group, Add Group Member, and Remove Group Member.
  1802.  
  1803.    Figure 16 shows a typical use of group setup messages.  The figure
  1804.    illustrates a scenario of exchanges between three hosts and the
  1805.    Service Agent.  In the scenario one host, Host A, creates a group
  1806.    which is joined by hosts B and C.  The hosts then exchange some data
  1807.    messages using the group address.  Note that multicast messages are
  1808.    not returned to their originator.  Hosts A and C then leave the
  1809.    group, and Host B decides to delete the group.  As in the scenario in
  1810.    Section 6.1, A/R indications have been omitted for clarity.
  1811.  
  1812.    Part of the group creation procedure involves the Service Agent
  1813.    returning to the creating host a 48-bit key along with the 16-bit
  1814.    group address.  The creating host must pass the key along with the
  1815.    group address to other hosts that want to join the group.  These
  1816.    other hosts must supply the key along with the group address in their
  1817.    Join Group Requests.  The key is used by the network to authenticate
  1818.    these operations and thereby minimize the probability that unwanted
  1819.    hosts will deliberately or inadvertently become members of the group.
  1820.    The procedure used by a host to distribute the group address and key
  1821.    is not within the scope of HAP.
  1822.  
  1823.    In the figure below, the network Service Agent is pictured as a
  1824.    single entity for simplicity.
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Edmond                                                         [Page 33]
  1851.  
  1852. RFC 1221                          HAP2                        April 1991
  1853.  
  1854.  
  1855.                                    Service   Host  Host  Host
  1856.                                     Agent     A     B     C
  1857.  
  1858.         Create Group Request         |<-------|
  1859.         Create Group Reply           |------->|
  1860.         Reply Acknowledgment         |<-------|
  1861.            :   :
  1862.         Distribute Group Adr & Key            |---->|
  1863.         Distribute Group Adr & Key            |---------->|
  1864.            :   :
  1865.         Join Group Request (C)       |<-------------------|
  1866.         Join Group Reply             |------------------->|
  1867.         Reply Acknowledgment         |<-------------------|
  1868.         Join Group Request (B)       |<-------------|
  1869.         Join Group Reply             |------------->|
  1870.         Reply Acknowledgment         |<-------------|
  1871.            :   :
  1872.         Data Message 1 (A to B and C)         |---->|---->|
  1873.         Data Message 2 (B to A and C)         |<----|---->|
  1874.         Data Message 3 (C to A and B)         |<----|<----|
  1875.            :   :
  1876.         Leave Group Request (C)      |<-------------------|
  1877.         Leave Group Reply            |------------------->|
  1878.         Reply Acknowledgment         |<-------------------|
  1879.         Leave Group Request (A)      |<-------|
  1880.         Leave Group Reply            |------->|
  1881.         Reply Acknowledgment         |<-------|
  1882.         Delete Group Request         |<-------------|
  1883.         Delete Group Reply           |------------->|
  1884.         Reply Acknowledgment         |<-------------|
  1885.  
  1886.                                GROUP EXAMPLE
  1887.                                  Figure 16
  1888.  
  1889.    An alternative method of adding and removing group members is the use
  1890.    of Add Group Member and Remove Group Member.  These setup requests
  1891.    allow hosts that are already members of the group to add or delete
  1892.    other hosts.
  1893.  
  1894.    The Setup requests Join Group, Leave Group, Add Group Member, Remove
  1895.    Group Member, and Delete Group are authenticated using the 48-bit
  1896.    key.  Leave Group and Remove Group Member will remove a host from the
  1897.    group membership list but will not alter the existence of the group.
  1898.    Delete Group expunges all knowledge of the group from the network.
  1899.    HAP permits any host with the proper key to delete the group at any
  1900.    time.  Thus, group addresses can be deleted even if the host which
  1901.    originally created the group has left the group or has crashed.
  1902.    Moreover, groups may exist for which there are currently no members
  1903.  
  1904.  
  1905.  
  1906. Edmond                                                         [Page 34]
  1907.  
  1908. RFC 1221                          HAP2                        April 1991
  1909.  
  1910.  
  1911.    because each member has executed a Leave while none has executed a
  1912.    Delete.  It is the responsibility of the hosts to coordinate and
  1913.    manage the use of group addresses.
  1914.  
  1915.    Note that group addresses, like all other resources allocated by the
  1916.    network, may be reclaimed by the network if unused for too long.
  1917.    Currently, if no traffic is sent to the group address in a 6 minute
  1918.    interval, the network may delete the group and notify all members
  1919.    that the group no longer exists.
  1920.  
  1921.    The Create Group Request (Figure 17) is used to establish a multicast
  1922.    address.  After the network has processed the Create Group Request,
  1923.    the Service Agent will respond by sending a Create Group Reply
  1924.    (Figure 18) to the host.
  1925.  
  1926.    A host may become a member of a group, once it knows the group
  1927.    address and the 48-bit key, by sending the Service Agent the Join
  1928.    Group Request message (Figure 19).  The Service Agent will respond to
  1929.    the Join Group Request with a Join Group Reply (Figure 20).  The host
  1930.    which creates a group automatically becomes a member of that group
  1931.    without any need for an explicit Join Group Request.
  1932.  
  1933.    A member host may add another host to the group by sending the
  1934.    Service Agent the Add Group Member Request message (Figure 21).  The
  1935.    Service Agent will respond with an Add Group Member Reply (Figure
  1936.    22).
  1937.  
  1938.    At any time after becoming a member of a group, a host may choose to
  1939.    drop out of the group.  To do this, the host sends the Service Agent
  1940.    a Leave Group Request (Figure 23).  The Service Agent will respond
  1941.    with a Leave Group Reply (Figure 24).
  1942.  
  1943.    One member host may expel another member of the group by sending the
  1944.    Service Agent the Remove Group Member Request message (Figure 25).
  1945.    The Service Agent will respond with a Remove Group Member Reply
  1946.    (Figure 26).
  1947.  
  1948.    A host can delete an existing group via a Delete Group Request
  1949.    (Figure 27).  The Service Agent will respond with a Delete Group
  1950.    Reply (Figure 28).  The Service Agent will also send the other
  1951.    members of the group, if any, a notification that the group has been
  1952.    deleted (see Section 6.3).
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Edmond                                                         [Page 35]
  1963.  
  1964. RFC 1221                          HAP2                        April 1991
  1965.  
  1966.  
  1967.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1968.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1969.      S0        |           1           |           1           |
  1970.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1971.      S1        |                 SETUP CHECKSUM                |
  1972.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1973.      S2        |                  REQUEST ID                   |
  1974.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1975.  
  1976.  
  1977.                            CREATE GROUP REQUEST
  1978.                                  Figure 17
  1979.  
  1980.  
  1981.  
  1982.      S0[0-7]   Setup Type = 1 (Request).
  1983.  
  1984.      S0[8-15]  Request Type = 1 (Create Group).
  1985.  
  1986.      S1[0-15]  Setup Checksum.  (See setup header description.)
  1987.  
  1988.      S2[0-15]  Request ID.
  1989.  
  1990.  
  1991.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  1992.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1993.      S0        |           2           |      REPLY CODE       |
  1994.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1995.      S1        |                 SETUP CHECKSUM                |
  1996.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1997.      S2        |                  REQUEST ID                   |
  1998.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  1999.      S3        |                 GROUP ADDRESS                 |
  2000.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2001.      S4        |                      KEY                      |
  2002.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2003.      S5        |                      KEY                      |
  2004.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2005.      S6        |                      KEY                      |
  2006.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2007.  
  2008.  
  2009.                             CREATE GROUP REPLY
  2010.                                  Figure 18
  2011.  
  2012.  
  2013.  
  2014.      S0[0-7]   Setup Type = 2 (Reply).
  2015.  
  2016.  
  2017.  
  2018. Edmond                                                         [Page 36]
  2019.  
  2020. RFC 1221                          HAP2                        April 1991
  2021.  
  2022.  
  2023.      S0[8-15]  Reply Code.
  2024.  
  2025.                     0 = Group created
  2026.                     8 = Network trouble
  2027.                    17 = Insufficient network resources
  2028.                    22 = Reply lost in network
  2029.  
  2030.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2031.  
  2032.      S2[0-15]  Request ID.
  2033.  
  2034.      S3[0-15]  Group Address.  This field contains the 16-bit
  2035.                multicast address that any group member may use to
  2036.                reach the other group members.  Multicast addresses are
  2037.                dynamically assigned by the network.
  2038.  
  2039.      S4-S6     Key.  This field contains a 48-bit key assigned by the
  2040.                network which is associated with the group address.  It
  2041.                must be provided for subsequent Join Group, Leave
  2042.                Group, Add Group Member, Remove Group Member, and
  2043.                Delete Group requests which reference the group
  2044.                address.
  2045.  
  2046.  
  2047.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2048.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2049.      S0        |           1           |           3           |
  2050.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2051.      S1        |                 SETUP CHECKSUM                |
  2052.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2053.      S2        |                  REQUEST ID                   |
  2054.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2055.      S3        |                 GROUP ADDRESS                 |
  2056.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2057.      S4        |                      KEY                      |
  2058.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2059.      S5        |                      KEY                      |
  2060.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2061.      S6        |                      KEY                      |
  2062.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2063.      S7        |                     0                   | MGP |
  2064.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2065.  
  2066.  
  2067.                             JOIN GROUP REQUEST
  2068.                                  Figure 19
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Edmond                                                         [Page 37]
  2075.  
  2076. RFC 1221                          HAP2                        April 1991
  2077.  
  2078.  
  2079.      S0[0-7]   Setup Type = 1 (Request).
  2080.  
  2081.      S0[8-15]  Request Type = 3 (Join Group).
  2082.  
  2083.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2084.  
  2085.      S2[0-15]  Request ID.
  2086.  
  2087.      S3[0-15]  Group Address.  This is the group that the host wishes
  2088.                to join.  Upon successfully joining the group, the host
  2089.                may send messages to the group and will receive
  2090.                messages sent to the group when those messages have a
  2091.                priority of MGP or higher.
  2092.  
  2093.      S4-S6     Key.  This is the key associated with the group
  2094.                address.
  2095.  
  2096.      S7[0-13]  Reserved.  Must be zero.
  2097.  
  2098.      S7[14-15] Minimum group message priority.  The host will not
  2099.                receive messages sent to the group that have a message
  2100.                priority less than MGP.  Send another Join Group
  2101.                Request message to change the minimum priority.
  2102.  
  2103.  
  2104.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2105.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2106.      S0        |           2           |      REPLY CODE       |
  2107.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2108.      S1        |                 SETUP CHECKSUM                |
  2109.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2110.      S2        |                   REQUEST ID                  |
  2111.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2112.  
  2113.  
  2114.                              JOIN GROUP REPLY
  2115.                                  Figure 20
  2116.  
  2117.  
  2118.  
  2119.      S0[0-7]   Setup Type = 2 (Reply).
  2120.  
  2121.      S0[8-15]  Reply Code.
  2122.  
  2123.                     2 = Host added to group
  2124.                     9 = Bad key
  2125.                    10 = Group address nonexistent
  2126.                    17 = Insufficient network resources
  2127.  
  2128.  
  2129.  
  2130. Edmond                                                         [Page 38]
  2131.  
  2132. RFC 1221                          HAP2                        April 1991
  2133.  
  2134.  
  2135.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2136.  
  2137.      S2[0-15]  Request ID.
  2138.  
  2139.  
  2140.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2141.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2142.      S0        |           1           |           10          |
  2143.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2144.      S1        |                 SETUP CHECKSUM                |
  2145.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2146.      S2        |                   REQUEST ID                  |
  2147.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2148.      S3        |                 GROUP ADDRESS                 |
  2149.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2150.      S4        |                      KEY                      |
  2151.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2152.      S5        |                      KEY                      |
  2153.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2154.      S6        |                      KEY                      |
  2155.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2156.      S7        |                  HOST ADDRESS                 |
  2157.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2158.  
  2159.  
  2160.                          ADD GROUP MEMBER REQUEST
  2161.                                  Figure 21
  2162.  
  2163.  
  2164.  
  2165.      S0[0-7]   Setup Type = 1 (Request).
  2166.  
  2167.      S0[8-15]  Request Type = 3 (Join Group).
  2168.  
  2169.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2170.  
  2171.      S2[0-15]  Request ID.
  2172.  
  2173.      S3[0-15]  Group Address.  This is the group the host will join.
  2174.                Upon successfully joining the group, the host may send
  2175.                messages to the group and will receive messages sent to
  2176.                the group by other hosts (the initial minimum priority
  2177.                will be 0).
  2178.  
  2179.      S4-S6     Key.  This is the key associated with the group
  2180.                address.
  2181.  
  2182.      S7[0-15]  Host address.  The network address of the host to add
  2183.  
  2184.  
  2185.  
  2186. Edmond                                                         [Page 39]
  2187.  
  2188. RFC 1221                          HAP2                        April 1991
  2189.  
  2190.  
  2191.                to the group.
  2192.  
  2193.  
  2194.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2195.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2196.      S0        |           2           |      REPLY CODE       |
  2197.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2198.      S1        |                 SETUP CHECKSUM                |
  2199.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2200.      S2        |                  REQUEST ID                   |
  2201.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2202.  
  2203.  
  2204.                           ADD GROUP MEMBER REPLY
  2205.                                  Figure 22
  2206.  
  2207.  
  2208.  
  2209.      S0[0-7]   Setup Type = 2 (Reply).
  2210.  
  2211.      S0[8-15]  Reply Code.
  2212.  
  2213.                     2 = Host added to group (or was already a member)
  2214.                     9 = Bad key
  2215.                    10 = Group address nonexistent
  2216.                    11 = Requestor is not a member of the group
  2217.                    17 = Insufficient network resources
  2218.                    22 = Reply lost in network
  2219.                    24 = Host address was invalid
  2220.  
  2221.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2222.  
  2223.      S2[0-15]  Request ID.
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Edmond                                                         [Page 40]
  2243.  
  2244. RFC 1221                          HAP2                        April 1991
  2245.  
  2246.  
  2247.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2248.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2249.      S0        |           1           |           4           |
  2250.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2251.      S1        |                 SETUP CHECKSUM                |
  2252.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2253.      S2        |                   REQUEST ID                  |
  2254.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2255.      S3        |                 GROUP ADDRESS                 |
  2256.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2257.      S4        |                      KEY                      |
  2258.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2259.      S5        |                      KEY                      |
  2260.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2261.      S6        |                      KEY                      |
  2262.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2263.  
  2264.  
  2265.                             LEAVE GROUP REQUEST
  2266.                                  Figure 23
  2267.  
  2268.  
  2269.  
  2270.      S0[0-7]   Setup Type = 1 (Request).
  2271.  
  2272.      S0[8-15]  Request Type = 4 (Leave Group).
  2273.  
  2274.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2275.  
  2276.      S2[0-15]  Request ID.
  2277.  
  2278.      S3[0-15]  Group Address.  This is the group that the host wishes
  2279.                to cease being a member of.  After leaving the group,
  2280.                the host will cease receiving messages sent to the
  2281.                group and will be unable to send to the group.
  2282.  
  2283.      S4-S6     Key.  This is the key associated with the group
  2284.                address.
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Edmond                                                         [Page 41]
  2299.  
  2300. RFC 1221                          HAP2                        April 1991
  2301.  
  2302.  
  2303.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2304.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2305.      S0        |           2            |     REPLY CODE       |
  2306.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2307.      S1        |                 SETUP CHECKSUM                |
  2308.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2309.      S2        |                  REQUEST ID                   |
  2310.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2311.  
  2312.  
  2313.                              LEAVE GROUP REPLY
  2314.                                  Figure 24
  2315.  
  2316.  
  2317.  
  2318.      S0[0-7]   Setup Type = 2 (Reply).
  2319.  
  2320.      S0[8-15]  Reply Code.
  2321.  
  2322.                     3 = Host deleted from group
  2323.                     9 = Bad key
  2324.                    10 = Invalid group address
  2325.                    11 = Not member of group
  2326.                    17 = Insufficient network resources
  2327.  
  2328.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2329.  
  2330.      S2[0-15]  Request ID.
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Edmond                                                         [Page 42]
  2355.  
  2356. RFC 1221                          HAP2                        April 1991
  2357.  
  2358.  
  2359.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2360.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2361.      S0        |           1           |           11          |
  2362.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2363.      S1        |                 SETUP CHECKSUM                |
  2364.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2365.      S2        |                   REQUEST ID                  |
  2366.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2367.      S3        |                 GROUP ADDRESS                 |
  2368.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2369.      S4        |                      KEY                      |
  2370.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2371.      S5        |                      KEY                      |
  2372.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2373.      S6        |                      KEY                      |
  2374.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2375.      S7        |                  HOST ADDRESS                 |
  2376.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2377.  
  2378.  
  2379.                         REMOVE GROUP MEMBER REQUEST
  2380.                                  Figure 25
  2381.  
  2382.  
  2383.  
  2384.      S0[0-7]   Setup Type = 1 (Request).
  2385.  
  2386.      S0[8-15]  Request Type = 4 (Leave Group).
  2387.  
  2388.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2389.  
  2390.      S2[0-15]  Request ID.
  2391.  
  2392.      S3[0-15]  Group Address.  This is the group from which the host
  2393.                should be removed.  After leaving the group, that host
  2394.                will cease receiving messages sent to the group and
  2395.                will be unable to send to the group.
  2396.  
  2397.      S4-S6     Key.  This is the key associated with the group
  2398.                address.
  2399.  
  2400.      S7[0-15]  Host address.  The network address of the host to
  2401.                remove from the group.
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Edmond                                                         [Page 43]
  2411.  
  2412. RFC 1221                          HAP2                        April 1991
  2413.  
  2414.  
  2415.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2416.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2417.      S0        |           2            |     REPLY CODE       |
  2418.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2419.      S1        |                 SETUP CHECKSUM                |
  2420.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2421.      S2        |                  REQUEST ID                   |
  2422.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2423.  
  2424.  
  2425.                          REMOVE GROUP MEMBER REPLY
  2426.                                  Figure 26
  2427.  
  2428.  
  2429.  
  2430.      S0[0-7]   Setup Type = 2 (Reply).
  2431.  
  2432.      S0[8-15]  Reply Code.
  2433.  
  2434.                     3 = Host deleted from group (or was not a member)
  2435.                     9 = Bad key
  2436.                    10 = Invalid group address
  2437.                    11 = Requestor is not a member of the group
  2438.                    17 = Insufficient network resources
  2439.                    22 = Reply lost in network
  2440.                    24 = Host address was invalid
  2441.  
  2442.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2443.  
  2444.      S2[0-15]  Request ID.
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Edmond                                                         [Page 44]
  2467.  
  2468. RFC 1221                          HAP2                        April 1991
  2469.  
  2470.  
  2471.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2472.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2473.      S0        |           1           |           2           |
  2474.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2475.      S1        |                 SETUP CHECKSUM                |
  2476.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2477.      S2        |                   REQUEST ID                  |
  2478.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2479.      S3        |                 GROUP ADDRESS                 |
  2480.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2481.      S4        |                      KEY                      |
  2482.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2483.      S5        |                      KEY                      |
  2484.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2485.      S6        |                      KEY                      |
  2486.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2487.  
  2488.  
  2489.                            DELETE GROUP REQUEST
  2490.                                  Figure 27
  2491.  
  2492.  
  2493.  
  2494.      S0[0-7]   Setup Type = 1 (Request).
  2495.  
  2496.      S0[8-15]  Request Type = 2 (Delete Group).
  2497.  
  2498.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2499.  
  2500.      S2[0-15]  Request ID.
  2501.  
  2502.      S3[0-15]  Group Address.  This is the multicast address to
  2503.                delete.  If the group is deleted, the other remaining
  2504.                members of the group, if any, will be notified of the
  2505.                group's deletion.
  2506.  
  2507.      S4-S6     Key.
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Edmond                                                         [Page 45]
  2523.  
  2524. RFC 1221                          HAP2                        April 1991
  2525.  
  2526.  
  2527.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2528.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2529.      S0        |           2           |      REPLY CODE       |
  2530.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2531.      S1        |                 SETUP CHECKSUM                |
  2532.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2533.      S2        |                  REQUEST ID                   |
  2534.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2535.  
  2536.  
  2537.                             DELETE GROUP REPLY
  2538.                                  Figure 28
  2539.  
  2540.  
  2541.  
  2542.      S0[0-7]   Setup Type = 2 (Reply).
  2543.  
  2544.      S0[8-15]  Reply Code.
  2545.  
  2546.                     1 = Group deleted
  2547.                     8 = Network trouble
  2548.                     9 = Bad key
  2549.                    10 = Invalid group address
  2550.                    17 = Insufficient network resources
  2551.                    22 = Reply lost in network
  2552.  
  2553.      S1[0-15]  Setup Checksum.  (See setup header description.)
  2554.  
  2555.      S2[0-15]  Request ID.
  2556.  
  2557.  
  2558. 6.3. Notifications
  2559.  
  2560.    Notifications are Setup exchanges initiated by the WPS to inform a
  2561.    host of changes in the status of a network resource.  The format of
  2562.    Notification messages is shown in Figure 29.
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Edmond                                                         [Page 46]
  2579.  
  2580. RFC 1221                          HAP2                        April 1991
  2581.  
  2582.  
  2583.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2584.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2585.      S0        |           3           |          CODE         |
  2586.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2587.      S1        |                    CHECKSUM                   |
  2588.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2589.      S2        |                 NOTIFICATION ID               |
  2590.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2591.      S3        |                NOTIFICATION INFO              |
  2592.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2593.  
  2594.  
  2595.                            NOTIFICATION MESSAGE
  2596.                                  Figure 29
  2597.  
  2598.  
  2599.  
  2600.      S0[0-7]   Message Type = 3 (Notification).
  2601.  
  2602.      S0[8-15]  Code.  This indicates what the Notification signifies.
  2603.  
  2604.                     0 = Stream suspended
  2605.                     1 = Stream resumed
  2606.                     2 = Stream deleted
  2607.                     3 = Group deleted by a host
  2608.                     4 = Group deleted by network
  2609.                     5 = All streams deleted
  2610.                     6 = All groups deleted
  2611.                     7 = Group changed by a host
  2612.                     8 = Group changed by network
  2613.  
  2614.      S1[0-15]  Checksum.  (See Service Agent Header description.)
  2615.  
  2616.      S2[0-15]  Notification ID.
  2617.  
  2618.      S3[0-15]  Notification Information.
  2619.  
  2620.                For notification types 0, 1, and 2, NOTIFICATION INFO
  2621.                contains the following:
  2622.  
  2623.  
  2624.                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2625.                S3  |        0        |         stream ID           |
  2626.                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2627.  
  2628.                For notification types 3, 4, 7, and 8, NOTIFICATION
  2629.                INFO contains the following:
  2630.  
  2631.  
  2632.  
  2633.  
  2634. Edmond                                                         [Page 47]
  2635.  
  2636. RFC 1221                          HAP2                        April 1991
  2637.  
  2638.  
  2639.                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2640.                S3  |                  group address                |
  2641.                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2642.  
  2643.                For notification types 5 and 6, which refer to all
  2644.                streams or groups, NOTIFICATION INFO is zero.
  2645.  
  2646.  
  2647. 6.4. Setup Acknowledgments
  2648.  
  2649.    The host must acknowledge receipt of Setup Replies and Notifications
  2650.    from the Service Agent, as described earlier.  The format for the
  2651.    Setup Acknowledgment message is shown in Figure 30.
  2652.  
  2653.  
  2654.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2655.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2656.      S0        |           0           |           CODE        |
  2657.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2658.      S1        |                    CHECKSUM                   |
  2659.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2660.      S2        |                   MESSAGE ID                  |
  2661.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2662.  
  2663.  
  2664.                            SETUP ACKNOWLEDGMENT
  2665.                                  Figure 30
  2666.  
  2667.  
  2668.  
  2669.      S0[0-7]   Message Type = 0 (Acknowledgment).
  2670.  
  2671.      S0[8-15]  Code.  This field indicates the type of acknowledgment.
  2672.  
  2673.                    0 = Reply acknowledgment
  2674.                    1 = Notification acknowledgment
  2675.  
  2676.      S1[0-15]  Checksum.  (See Service Agent Header description.)
  2677.  
  2678.      S2[0-15]  Message ID.  This is either a Request ID or a
  2679.                Notification ID.
  2680.  
  2681. 6.5. Information Request / Reply Messages
  2682.  
  2683.    The host may obtain information about WPS state and about what
  2684.    resources the WPS currently has allocated for the host by sending an
  2685.    Information Request message to the Service Agent.  The Information
  2686.    Reply that is returned will enable the host to determine 1) what
  2687.  
  2688.  
  2689.  
  2690. Edmond                                                         [Page 48]
  2691.  
  2692. RFC 1221                          HAP2                        April 1991
  2693.  
  2694.  
  2695.    resources the WPS has allocated to the host, and 2) the current state
  2696.    of the network and, possibly, certain network parameters.  This
  2697.    allows the host to refrain from trying to use resources it no longer
  2698.    has, and to regain information it may have lost on its network
  2699.    resources.  This communication also informs the host of the network
  2700.    state so that it may make priority and routing decisions.
  2701.  
  2702.    Each Information Request (Figure 31) and Information Reply (Figure
  2703.    32) message deals with a single type of resource at a time.  The
  2704.    header of the Information Reply message contains the number of
  2705.    entries within the message, the number of 16-bit words in each entry,
  2706.    and an instance of the appropriate information structure for each
  2707.    resource the Information Reply message describes.  These information
  2708.    structures are described in Figures 33 and 34.
  2709.  
  2710.    Future versions of the HAP protocol may permit queries about network
  2711.    connectivity, estimated delay to a specified destination address
  2712.    under specified conditions, etc.  This is a section of the protocol
  2713.    that is likely to expand in the future.  Extensions are expected to
  2714.    be backward compatible provided implementors do not hard code the
  2715.    size of the returned information entries.
  2716.  
  2717.  
  2718.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2719.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2720.      S0        |           4           |           CODE        |
  2721.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2722.      S1        |                    CHECKSUM                   |
  2723.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2724.      S2        |                   MESSAGE ID                  |
  2725.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2726.  
  2727.  
  2728.                         INFORMATION REQUEST MESSAGE
  2729.                                  Figure 31
  2730.  
  2731.  
  2732.  
  2733.      S0[0-7]   Message type = 4 (Information Request).
  2734.  
  2735.      S0[8-15]  Code.  This field identifies the Information Request
  2736.                Type.
  2737.  
  2738.                     1 = streams owned by host
  2739.                     2 = groups to which the host belongs
  2740.  
  2741.      S1[0-15]  Checksum.  (See Service Agent Header description.)
  2742.  
  2743.  
  2744.  
  2745.  
  2746. Edmond                                                         [Page 49]
  2747.  
  2748. RFC 1221                          HAP2                        April 1991
  2749.  
  2750.  
  2751.      S2[0-15]  Message ID.  This field is assigned by the host to
  2752.                uniquely identify outstanding requests (Request ID).
  2753.                This ID is copied into Information Replies by the
  2754.                Service Agent.
  2755.  
  2756.  
  2757.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2758.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2759.      S0        |           5           |          CODE         |
  2760.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2761.      S1        |                    CHECKSUM                   |
  2762.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2763.      S2        |                   MESSAGE ID                  |
  2764.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2765.      S3        |   NUMBER OF ENTRIES   |    WORDS PER ENTRY    |
  2766.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2767.                |                                               |
  2768.      S4-SN     :              ENTRIES (0 or more)              :
  2769.                |                                               |
  2770.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2771.  
  2772.  
  2773.                          INFORMATION REPLY MESSAGE
  2774.                                  Figure 32
  2775.  
  2776.  
  2777.  
  2778.      S0[0-7]   Message type = 5 (Information Reply).
  2779.  
  2780.      S0[8-15]  Code.  This field identifies the Information Reply
  2781.                Type.
  2782.  
  2783.                     1 = streams owned by host
  2784.                     2 = groups to which the host belongs
  2785.                     3 = error in Information Request message
  2786.                     4 = network trouble
  2787.                     5 = access not allowed
  2788.  
  2789.      S1[0-15]  Checksum.  (See Service Agent Header description.)
  2790.  
  2791.      S2[0-15]  Message ID.  This field is assigned by the host in the
  2792.                Information Request message to uniquely identify
  2793.                outstanding requests.  This ID is copied into the
  2794.                Information Reply message by the Service Agent.
  2795.  
  2796.      S3[0-7]   Number of entries included in the Information Reply
  2797.                message.
  2798.  
  2799.  
  2800.  
  2801.  
  2802. Edmond                                                         [Page 50]
  2803.  
  2804. RFC 1221                          HAP2                        April 1991
  2805.  
  2806.  
  2807.      S3[8-15]  Number of 16-bit words per entry.
  2808.  
  2809.      S4-SN     Zero or more instances of either the stream information
  2810.                or group information structure.
  2811.  
  2812.  
  2813.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2814.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2815.      0         |       0         |          STREAM ID          |
  2816.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2817.      1         |          STREAM TYPE OF SERVICE WORD          |
  2818.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2819.      2         |        STREAM SIZE (bits per interval)        |
  2820.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2821.      3         |    STREAM INTERVAL (in units of 0.125 ms.)    |
  2822.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2823.  
  2824.  
  2825.                             STREAM INFORMATION
  2826.                                  Figure 33
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2833.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2834.      0         |                  GROUP ADDRESS                |
  2835.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2836.      1         |                    0                    | MGP |
  2837.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2838.  
  2839.  
  2840.                              GROUP INFORMATION
  2841.                                  Figure 34
  2842.  
  2843.  
  2844. 7. Host Access Link Monitoring
  2845.  
  2846.    While the access link is operating, statistics on traffic load and
  2847.    error rate are maintained by the host and WPS.  Once a second, the
  2848.    host and WPS exchange this information via Status messages (Figure
  2849.    35).  This periodic exchange of Status messages permits both ends of
  2850.    the link to monitor flows in both directions.  The WPS also reports
  2851.    these monitoring statistics to the Network Operations Center (NOC).
  2852.    If either host or WPS fails to receive Status messages for ten
  2853.    seconds, the link will be restarted (see Section 8).
  2854.  
  2855.  
  2856.  
  2857.  
  2858. Edmond                                                         [Page 51]
  2859.  
  2860. RFC 1221                          HAP2                        April 1991
  2861.  
  2862.  
  2863.    The link restart procedure initializes all internal WPS counts and
  2864.    statistics for that link to zero.  As data and control messages are
  2865.    processed, counts are updated to reflect the total number of messages
  2866.    sent, messages received correctly, and messages received with
  2867.    different classes of errors since the last link restart.  Whenever a
  2868.    Status message arrives, a snapshot is taken of the local WPS counts.
  2869.    The local receive counts, in conjunction with a sent count contained
  2870.    in the received Status message, permits the computation of traffic
  2871.    statistics in the one second update interval assuming that the set of
  2872.    counts at the time of the previous monitoring report have been saved.
  2873.    By including in the Status message sent (in the opposite direction)
  2874.    the receive counts and the received sent count that was used with
  2875.    them, the transmitting end of the access link as well as the
  2876.    receiving end can determine the link performance from sender to
  2877.    receiver.
  2878.  
  2879.  
  2880.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  2881.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2882.      0         | 1|LB|GOPRI|           0           |     0     |
  2883.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2884.      1         |                HEADER CHECKSUM                |
  2885.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2886.      2         |             MOST RECENT A/R SENT              |
  2887.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2888.      3         |                STREAM CAPACITY                |
  2889.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2890.      4         |                   TIMESTAMP                   |
  2891.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2892.      5         |                      SBU                      |
  2893.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2894.      6         |                      STU                      |
  2895.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2896.      7         |                      RNE                      |
  2897.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2898.      8         |                      RWE                      |
  2899.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2900.      9         |                      BHC                      |
  2901.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2902.      10        |                      HEI                      |
  2903.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2904.  
  2905.  
  2906.                               STATUS MESSAGE
  2907.                                  Figure 35
  2908.  
  2909.  
  2910.  
  2911.  
  2912.  
  2913.  
  2914. Edmond                                                         [Page 52]
  2915.  
  2916. RFC 1221                          HAP2                        April 1991
  2917.  
  2918.  
  2919.      0[0]      Message Class = 1 (Control Message).
  2920.  
  2921.      0[1]      Loopback indicator.
  2922.  
  2923.      0[2-3]    Go-Priority.
  2924.  
  2925.      0[4-11]   Reserved.  Must be zero.
  2926.  
  2927.      0[12-15]  Control Message Type = 0 (Status).
  2928.  
  2929.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  2930.                the 2's-complement sum of words 0-10 (excluding the
  2931.                checksum word itself).
  2932.  
  2933.      2[0-15]   Most Recent A/R Sent.  This field is a duplicate of the
  2934.                most recent acceptance/refusal word.  It is included in
  2935.                the periodic Status message in case previous
  2936.                transmissions containing A/R information were lost.
  2937.  
  2938.      3[0-15]   Stream Capacity.  When sent by the WPS, this field
  2939.                indicates how much stream capacity is unused, in units
  2940.                of data bits per millisecond.  There is no guarantee
  2941.                that a request for a stream of this size will succeed.
  2942.                Since available capacity depends directly on a variety
  2943.                of parameters that can be selected by the user, the
  2944.                value of this field is the maximum capacity that could
  2945.                be achieved if existing streams were expanded at low
  2946.                reliability.  This field is not meaningful in messages
  2947.                sent from the host to the WPS and must be set to zero.
  2948.  
  2949.      4[0-15]   Timestamp.  This field indicates the time that the
  2950.                Status message was generated.  When sent by a WPS, the
  2951.                time is in units of seconds since the last link
  2952.                restart.  The host should also timestamp its messages
  2953.                in units of seconds.
  2954.  
  2955.      5[0-15]   Sent By Us.  Count of messages sent by us since the
  2956.                last link restart (not including this one).
  2957.  
  2958.      6[0-15]   Sent To Us.  Count of messages sent to us since the
  2959.                last link restart.  This is the count from word 5 of
  2960.                the last Status message received.
  2961.  
  2962.      7[0-15]   Received, No Errors.  This is the count of messages
  2963.                received without errors (since the last link restart)
  2964.                at the time that the last Status message was received.
  2965.  
  2966.      8[0-15]   Received With Errors.  This is the count of messages
  2967.  
  2968.  
  2969.  
  2970. Edmond                                                         [Page 53]
  2971.  
  2972. RFC 1221                          HAP2                        April 1991
  2973.  
  2974.  
  2975.                received with errors (since the last link restart) at
  2976.                the time the last Status message was received.
  2977.  
  2978.      9[0-15]   Bad Header Checksums.  This is the count of messages
  2979.                received with bad header checksums (since the last link
  2980.                restart) at the time the last Status message was
  2981.                received.
  2982.  
  2983.      10[0-15]  Hardware Error Indication.  This is the count of
  2984.                messages received with hardware CRC errors or hardware
  2985.                interface error indications (since the last link
  2986.                restart) at the time the last Status message was
  2987.                received.
  2988.  
  2989. 8. Initialization
  2990.  
  2991.    The Host Access Protocol uses a number of state variables that must
  2992.    be initialized in order to function properly.  These variables are
  2993.    associated with the send and receive message numbers used by the
  2994.    acceptance/refusal mechanism and the statistics maintained to support
  2995.    link monitoring.  Link initialization should be carried out when a
  2996.    machine is initially powered up, when it does a system restart, when
  2997.    the ON state (see below) times out, when a loopback condition times
  2998.    out (see Section 9), or whenever the link transitions from non-
  2999.    operational to operational status.
  3000.  
  3001.    Initialization is accomplished by the exchange of Restart Request
  3002.    (RR) and Restart Complete (RC) messages between a host and a WPS.
  3003.    Either end (or both ends) may send an initial RR, and both ends must
  3004.    have sent and received an RC message in order to declare the link up.
  3005.    Because the RC message is a reply (to an RR or RC), receipt of an RC
  3006.    message by both ends guarantees that the physical link is operating
  3007.    in both directions.  The initialization state diagram that must be
  3008.    implemented by both WPS and host is shown in Figure 36.  Five states
  3009.    are identified in the state diagram:
  3010.  
  3011.      OFF       Entered upon recognition of a requirement to restart.
  3012.                The interface in the Host or WPS can recognize this
  3013.                requirement itself or be forced to restart by receipt
  3014.                of an RR message from the other end while in the ON
  3015.                state.
  3016.  
  3017.      INIT      Local state variables have been initialized but no RC
  3018.                messages have yet been sent or received.  If receipt of
  3019.                an RR initiated the restart, or if an RR has been
  3020.                received since this restart began, send an RC
  3021.                (optional, reduces startup time).  Otherwise, send an
  3022.                RR to alert the other end of the restart.
  3023.  
  3024.  
  3025.  
  3026. Edmond                                                         [Page 54]
  3027.  
  3028. RFC 1221                          HAP2                        April 1991
  3029.  
  3030.  
  3031.      RR-SNT    A request to reinitialize (RR) has been sent to the
  3032.                other end, but no RR or RC messages have been received.
  3033.  
  3034.      RC-SNT    An RC has been sent to the other end in response to an
  3035.                RR.  The interface is waiting to receive an RC.
  3036.  
  3037.      ON        RC messages have been both sent and received.  Local
  3038.                counters have been zeroed.  Data and control messages
  3039.                can now be exchanged between the WPS and host.
  3040.  
  3041.    All states have 10-second timeouts (not illustrated) which return the
  3042.    protocol to the OFF state.  The occurrence of any events other than
  3043.    those indicated in the diagram are ignored.
  3044.  
  3045.  
  3046.  
  3047.  
  3048.  
  3049.  
  3050.  
  3051.  
  3052.  
  3053.  
  3054.  
  3055.  
  3056.  
  3057.  
  3058.  
  3059.  
  3060.  
  3061.  
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.  
  3076.  
  3077.  
  3078.  
  3079.  
  3080.  
  3081.  
  3082. Edmond                                                         [Page 55]
  3083.  
  3084. RFC 1221                          HAP2                        April 1991
  3085.  
  3086.  
  3087.                               .-----.
  3088.          Any Timeout or ----->| OFF |<----------------------------+
  3089.          Device Down          `--+--'                             |
  3090.                                  |                                |
  3091.                                  | (When I/O Device Up)           |
  3092.                                  V                                |
  3093.                              .-------.                            |
  3094.                              | INIT  |                            |
  3095.                              `---+---'                            |
  3096.                                  |                                |
  3097.                    (Yes)         V            (No)                |
  3098.                   +---------RR Received?----------+               |
  3099.                   |                               |               |
  3100.                   |                            Send RR            |
  3101.                   |                               |               |
  3102.                   |                               V               |
  3103.                   |                           .--------.          |
  3104.                Send RC <-----+-------<--------+ RR-SNT |          |
  3105.                   |          |       (Rcv RR) `---+----'          |
  3106.                   |          |                    | (Rcv RC)      |
  3107.                   V          |                    |               |
  3108.              .--------.      |                    |               |
  3109.              | RC-SNT +--->--+                 Send RC            |
  3110.              `----+---'  (Rcv RR)                 |               |
  3111.          (Rcv RC) |                               |               |
  3112.                   |                               |               |
  3113.                   +------->------+-------<--------+               |
  3114.                                  |                                |
  3115.                       Initialize Status Counters                  |
  3116.                                  |                                |
  3117.                                  V                                |
  3118.                               .-----.   Rcv RR   or               |
  3119.               Rcv Any  +----->| ON  +---------------------->------+
  3120.               Other    |      `--+--'   Fail to Rcv Status message
  3121.                        +---------+      for 10 seconds
  3122.  
  3123.                       HAP LINK RESTART STATE DIAGRAM
  3124.                                  Figure 36
  3125.  
  3126.  
  3127.    The Restart Request control message (Figure 37) is sent by either a
  3128.    host or a WPS when it wishes to restart a link.  The Restart Request
  3129.    causes all the monitoring statistics reported in the Status Message
  3130.    to be reset to zero and stops all traffic on the link in both
  3131.    directions.  The Restart Complete message (Figure 38) is sent in
  3132.    response to a received Restart Request or Restart Complete to
  3133.    complete link initialization.  The Restart Complete carries a field
  3134.    used by the host to enable or disable the acceptance/refusal
  3135.  
  3136.  
  3137.  
  3138. Edmond                                                         [Page 56]
  3139.  
  3140. RFC 1221                          HAP2                        April 1991
  3141.  
  3142.  
  3143.    mechanism for the link being restarted (see Section 5).  After the
  3144.    Restart Complete is processed, traffic may flow on the link.
  3145.  
  3146.    The allocation and state of network resources (streams and groups)
  3147.    are separate from the state of the host's access link(s) to the WPS.
  3148.    The Information Request message (see Section 6.5) may be used by a
  3149.    host to determine what resources it has.  If the "SL" bit is set in
  3150.    the Restart Complete message from the WPS, and if the host believes
  3151.    it has resources allocated to it, the host is strongly encouraged to
  3152.    use an Information Request to verify that it still has its resources.
  3153.  
  3154.  
  3155.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  3156.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3157.      0         | 1|LB|    0   |VERSION |     0     |     3     |
  3158.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3159.      1         |                HEADER CHECKSUM                |
  3160.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3161.      2         |                 HOST ADDRESS                  |
  3162.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3163.      3         |                  LINK NUMBER                  |
  3164.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3165.  
  3166.  
  3167.                               RESTART REQUEST
  3168.                                  Figure 37
  3169.  
  3170.  
  3171.  
  3172.      0[0]     Message Type = 1 (Control Message).
  3173.  
  3174.      0[1]     Loopback indicator.
  3175.  
  3176.      0[2-4]   Reserved.  Must be zero.
  3177.  
  3178.      0[5-7]   HAP version number.  Use 1.  Use of zero invokes
  3179.               backward compatibility code (see Appendix B).
  3180.  
  3181.      0[8-11]  Reserved.  Must be zero.
  3182.  
  3183.      0[12-15] Control Message Type = 3 (Restart Request).
  3184.  
  3185.      1[0-15]  Header Checksum.  The checksum is the 2's-complement of
  3186.               the 2's-complement sum of words 0-3 (excluding the
  3187.               checksum word itself).
  3188.  
  3189.      2[0-15]  Host Address.  The WPS inserts the primary network
  3190.               address of the host.  The host may insert any of its
  3191.  
  3192.  
  3193.  
  3194. Edmond                                                         [Page 57]
  3195.  
  3196. RFC 1221                          HAP2                        April 1991
  3197.  
  3198.  
  3199.               network addresses in this field (hosts may have more
  3200.               than one logical address per physical port).  The WPS
  3201.               will only bring up the HAP link if the host address is
  3202.               valid for the port being used.
  3203.  
  3204.      3[0-15]  Link Number.  This field contains the sender's
  3205.               identification of the physical link being used.  This
  3206.               information is used to identify the link when reporting
  3207.               errors to the Network Operations Center (NOC).
  3208.  
  3209.  
  3210.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  3211.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3212.      0         | 1|LB|   0    |VERSION |  0  |SL|AR|     4     |
  3213.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3214.      1         |                HEADER CHECKSUM                |
  3215.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3216.      2         |                 HOST ADDRESS                  |
  3217.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3218.      3         |                  LINK NUMBER                  |
  3219.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3220.  
  3221.  
  3222.                              RESTART COMPLETE
  3223.                                  Figure 38
  3224.  
  3225.  
  3226.  
  3227.      0[0]     Message Type = 1 (Control Message).
  3228.  
  3229.      0[1]     Loopback indicator.
  3230.  
  3231.      0[2-4]   Reserved.  Must be zero.
  3232.  
  3233.      0[5-7]   HAP version number.  Use 1.  Use of zero invokes
  3234.               backward compatibility code (see Appendix B).
  3235.  
  3236.      0[8-9]   Reserved.  Must be zero.
  3237.  
  3238.      0[10]    Service loss alert (boolean) (WPS to host only; host
  3239.               must send zero).  If the WPS has any reason to believe
  3240.               that the resources allocated to the host may not match
  3241.               what the host believes is allocated, SL is set to one.
  3242.               If SL is one, a host that believes it owns any resources
  3243.               is strongly encouraged to use an Information Request to
  3244.               verify that the resources are still allocated.  SL will
  3245.               be one the first time a link is brought up after a WPS
  3246.               is restarted, and may be set in other cases.
  3247.  
  3248.  
  3249.  
  3250. Edmond                                                         [Page 58]
  3251.  
  3252. RFC 1221                          HAP2                        April 1991
  3253.  
  3254.  
  3255.      0[11]    Acceptance/Refusal Control.  This bit is used by the
  3256.               host to enable or disable the acceptance/refusal
  3257.               mechanism for all traffic on the link.
  3258.  
  3259.                    0 = Disable acceptance/refusal
  3260.                    1 = Enable acceptance/refusal
  3261.  
  3262.      0[12-15] Control Message Type = 4 (Restart Complete).
  3263.  
  3264.      1[0-15]  Header Checksum.  Covers words 0-3.
  3265.  
  3266.      2[0-15]  Host Address.
  3267.  
  3268.      3[0-15]  Link Number.
  3269.  
  3270. 9. Loopback Control
  3271.  
  3272.    The Host Access Protocol provides a Loopback Request control message
  3273.    which can be used by a WPS or a host to request the remote loopback
  3274.    of its HAP messages.  Such requests are usually the result of
  3275.    operator intervention for purposes of system fault diagnosis.  For
  3276.    clarity in the following discussion, the unit (WPS or host)
  3277.    requesting the remote loopback is referred to as the "transmitter"
  3278.    and the unit implementing (or rejecting) the loopback is referred to
  3279.    as the "receiver".
  3280.  
  3281.    When the host access link is remotely looped, all HAP messages will
  3282.    be returned, unmodified, over the access link by the receiver.
  3283.    (Messages that are too long to be valid HAP messages may be discarded
  3284.    instead of being returned.)  The receiver will not send any of its
  3285.    own messages to the transmitter while it is implementing the loop.
  3286.    WPS-generated messages are distinguished from host-generated messages
  3287.    by means of the Loopback indicator that is in every HAP message
  3288.    header.
  3289.  
  3290.    Two types of remote loopback may be requested: loopback at the
  3291.    receiver's interface hardware and loopback at the receiver's I/O
  3292.    driver software.  HAP does not specify the manner in which the
  3293.    receiver should implement these loops; additionally, some receivers
  3294.    may use interface hardware which is incapable of looping the
  3295.    transmitter's messages, only allowing the receiver to provide
  3296.    software loops.  A receiver may not be able to interpret the
  3297.    transmitter's messages as it is looping them back.  If such
  3298.    interpretation is possible, however, the receiver will not act on any
  3299.    of the transmitter's messages other than requests to reinitialize the
  3300.    WPS-host link (Restart Request (RR) control messages; see Section 8.)
  3301.  
  3302.    When a receiver initiates a loopback condition in response to a
  3303.  
  3304.  
  3305.  
  3306. Edmond                                                         [Page 59]
  3307.  
  3308. RFC 1221                          HAP2                        April 1991
  3309.  
  3310.  
  3311.    loopback request, it makes an implicit promise to maintain the
  3312.    condition for the duration specified in the Loopback Request message.
  3313.    However, if an unanticipated condition such as a system restart
  3314.    occurs in either the transmitter or the receiver, the affected unit
  3315.    will try to reinitialize the WPS-host link by sending an RR message
  3316.    to the other unit.  If the RR message is recognized by the other
  3317.    unit, a link initialization sequence can be completed.  This will
  3318.    restore the link to an unlooped condition even if the specified loop
  3319.    duration has not yet expired.  If a receiver cannot interpret a
  3320.    transmitter's RR messages, and in the absence of operator
  3321.    intervention at the receiver, the loop will remain in place for its
  3322.    duration.
  3323.  
  3324.    HAP does not specify the characteristics of any loopback conditions
  3325.    that may be locally implemented by a given unit.  An example of such
  3326.    a condition is that obtained when a WPS commands its host interface
  3327.    to loop back its own messages.  If such local loop conditions also
  3328.    cause the reflection of messages received from the remote unit, the
  3329.    remote unit will detect the condition via the HAP header Loopback
  3330.    indicator.
  3331.  
  3332.    A specific sequence must be followed for setting up a remote
  3333.    loopback.  It begins after the HAP link has been initialized and a
  3334.    decision is made to request a remote loop.  The transmitter then
  3335.    sends a Loopback Request message (Figure 39) to the receiver and
  3336.    waits for either (1) a 10-second timer to expire, (2) a "Can't
  3337.    implement loop" Unnumbered Response message from the receiver, or (3)
  3338.    one of its own reflected messages.  If event (1) or (2) occurs the
  3339.    request has failed and the transmitter may, at its option, try again
  3340.    with a new Loopback Request message.  If event (3) occurs, the remote
  3341.    loopback condition has been established.  While waiting for one of
  3342.    these events, messages from the receiver are processed normally.
  3343.    Note that RR messages arriving from the receiver during this time
  3344.    will terminate the loopback request.
  3345.  
  3346.    When a receiver gets a Loopback Request message, it either implements
  3347.    the requested loop for the specified duration, or returns a "Can't
  3348.    implement loop" response without changing the state of the link.  The
  3349.    latter response would be returned, for example, if a receiver is
  3350.    incapable of implementing a requested hardware loop.  A receiver
  3351.    should initiate reinitialization of the link with an RR message(s)
  3352.    whenever a loopback condition times out.
  3353.  
  3354.    There is one asymmetry that is required in the above sequence to
  3355.    resolve the (unlikely) case where both WPS and host request a remote
  3356.    loopback at the same time. If a WPS receives a Loopback Request
  3357.    message from a host while it is itself waiting for an event of type
  3358.    (1)-(3), it will return a "Can't implement loop" response to the host
  3359.  
  3360.  
  3361.  
  3362. Edmond                                                         [Page 60]
  3363.  
  3364. RFC 1221                          HAP2                        April 1991
  3365.  
  3366.  
  3367.    and will continue to wait.  A host in the converse situation,
  3368.    however, will abort its loopback request and will instead act on the
  3369.    WPS's loopback request.
  3370.  
  3371.  
  3372.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  3373.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3374.      0         | 1|LB|GOPRI|     0     | LOOP TYPE |     8     |
  3375.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3376.      1         |                HEADER CHECKSUM                |
  3377.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3378.      2         |                 LOOP DURATION                 |
  3379.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3380.  
  3381.  
  3382.                              LOOPBACK REQUEST
  3383.                                  Figure 39
  3384.  
  3385.  
  3386.  
  3387.      0[0]      Message Type = 1 (Control Message).
  3388.  
  3389.      0[1]      Loopback indicator.
  3390.  
  3391.      0[2-3]    Go-Priority.
  3392.  
  3393.      0[4-7]    Reserved.  Must be zero.
  3394.  
  3395.      0[8-11]   Loop Type.  This field indicates the type of loop that
  3396.                is being requested as follows:
  3397.  
  3398.                     0 = Undefined
  3399.                     1 = Loop at interface (hardware loop)
  3400.                     2 = Loop at driver (software loop)
  3401.                     3-15 = Undefined
  3402.  
  3403.      0[12-15]  Control Message Type = 8 (Loopback Request).
  3404.  
  3405.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  3406.                the 2's-complement sum of words 0-2 (excluding the
  3407.                checksum word itself).
  3408.  
  3409.      2[0-15]   Loop Duration.  The transmitter of a Loopback Request
  3410.                message uses this field to specify the number of
  3411.                seconds that the loop is to be maintained by the
  3412.                receiver.
  3413.  
  3414.  
  3415.  
  3416.  
  3417.  
  3418. Edmond                                                         [Page 61]
  3419.  
  3420. RFC 1221                          HAP2                        April 1991
  3421.  
  3422.  
  3423. 10. Other Control Messages
  3424.  
  3425.    Before a WPS or a host voluntarily disables a WPS-host link, it
  3426.    should send at least one Link Going Down control message (Figure 40)
  3427.    over that link.  HAP does not define the action(s) that should be
  3428.    taken by a WPS or a host when such a message is received; informing
  3429.    the Network Operations Center (NOC) and/or the network users of the
  3430.    impending event is a typical course of action.  Note that each Link
  3431.    Going Down message only pertains to the WPS-host link that it is sent
  3432.    over; if a host and a WPS are connected by multiple links, these
  3433.    links may be selectively disabled.
  3434.  
  3435.    A No Operation (NOP) control message (Figure 41) may be sent at any
  3436.    time by a WPS or a host.  A NOP message contains up to 32 words of
  3437.    arbitrary data which are undefined by HAP.  NOP messages may be
  3438.    required in some cases to clear the state of the WPS-host link
  3439.    hardware.
  3440.  
  3441.  
  3442.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  3443.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3444.      0         | 1|LB|GOPRI|     0     |  REASON   |     7     |
  3445.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3446.      1         |                HEADER CHECKSUM                |
  3447.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3448.      2         |               TIME UNTIL DOWN                 |
  3449.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3450.      3         |                DOWN DURATION                  |
  3451.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3452.  
  3453.  
  3454.                               LINK GOING DOWN
  3455.                                  Figure 40
  3456.  
  3457.  
  3458.  
  3459.      0[0]      Message Type = 1 (Control Message).
  3460.  
  3461.      0[1]      Loopback indicator.
  3462.  
  3463.      0[2-3]    Go-Priority.
  3464.  
  3465.      0[4-7]    Reserved.  Must be zero.
  3466.  
  3467.      0[8-11]   Reason.  This field is used by the WPS or the host to
  3468.                indicate the reason for disabling this WPS-host link as
  3469.                follows:
  3470.  
  3471.  
  3472.  
  3473.  
  3474. Edmond                                                         [Page 62]
  3475.  
  3476. RFC 1221                          HAP2                        April 1991
  3477.  
  3478.  
  3479.                     0 = Cancel previous notice, not going down
  3480.                     1 = Unspecified reason
  3481.                     2 = Scheduled PM
  3482.                     3 = Scheduled hardware work
  3483.                     4 = Scheduled software work
  3484.                     5 = Emergency restart
  3485.                     6 = Power outage
  3486.                     7 = Software breakpoint
  3487.                     8 = Hardware failure
  3488.                     9 = Not scheduled up
  3489.                    10 = Last warning:  The WPS or host will disable
  3490.                         the link in 10 seconds
  3491.                    11-15 = Undefined
  3492.  
  3493.      0[12-15]  Control Message Type = 7 (Link Going Down).
  3494.  
  3495.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  3496.                the 2's-complement sum of words 0-3 (excluding the
  3497.                checksum word itself).
  3498.  
  3499.      2[0-15]   Time Until Down.  This field specifies the amount of
  3500.                time remaining until the WPS or host disables the link
  3501.                (in minutes).  An entry of zero indicates that there is
  3502.                less than a minute remaining.
  3503.  
  3504.      3[0-15]   Down Duration.  This field specifies the amount of time
  3505.                that the WPS-host link will be down (in minutes).  An
  3506.                entry of zero indicates that the down duration will be
  3507.                less than a minute.  An entry of -1 (all bits set)
  3508.                indicates an indefinite down duration.
  3509.  
  3510.  
  3511.                  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  3512.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3513.      0         | 1|LB|       0      |    LENGTH    |     6     |
  3514.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3515.      1         |                HEADER CHECKSUM                |
  3516.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3517.                |                                               |
  3518.      2-N       :                ARBITRARY DATA                 :
  3519.                |                                               |
  3520.                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3521.  
  3522.  
  3523.                             NO OPERATION (NOP)
  3524.                                  Figure 41
  3525.  
  3526.  
  3527.  
  3528.  
  3529.  
  3530. Edmond                                                         [Page 63]
  3531.  
  3532. RFC 1221                          HAP2                        April 1991
  3533.  
  3534.  
  3535.      0[0]      Message Type = 1 (Control Message).
  3536.  
  3537.      0[1]      Loopback indicator.
  3538.  
  3539.      0[2-6]    Reserved.  Must be zero.
  3540.  
  3541.      0[7-11]   Length.  The number of words of arbitrary data.
  3542.  
  3543.      0[12-15]  Control Message Type = 6 (NOP).
  3544.  
  3545.      1[0-15]   Header Checksum.  The checksum is the 2's-complement of
  3546.                the 2's-complement sum of words 0-N (excluding the
  3547.                checksum word itself).
  3548.  
  3549.      2-N       Arbitrary Data.  Up to 32 words of data may be sent.
  3550.                The data are undefined by HAP.
  3551.  
  3552. 11. Appendix A -- Future Extensions
  3553.  
  3554.    The extensions to HAP described below are included to provide
  3555.    additional context for the understanding of HAP's current
  3556.    capabilities, as well as suggest how HAP may be enhanced in the
  3557.    future to provide better support for multi-site conferencing.  These
  3558.    capabilities are not supported by TWBNET.
  3559.  
  3560.    One change under consideration is the addition of a "conference"
  3561.    resource, which would own some number of streams and groups and
  3562.    improve the network's ability to meet the needs of video conference
  3563.    users.  A single request to modify the "conference", such as to add a
  3564.    new member, would result in modifying all the streams in the
  3565.    conference to include the new member, modifying the conference's
  3566.    primary group address to add the new member, etc., in a single
  3567.    network operation.  Such a capability would not only simplify
  3568.    conference resource management for hosts, but also reduce the number
  3569.    of network setup operations, permit more nearly "atomic" decisions of
  3570.    whether a particular conference modification is possible, and reduce
  3571.    the problem of recovery if modification is not possible.
  3572.  
  3573.    Another change under consideration is the addition of "shared
  3574.    streams."  This capability would allow hosts to share a single
  3575.    allocation of network bandwidth (and other resources) wherever the
  3576.    streams shared a common communication path.  Hosts using a shared
  3577.    stream must be willing to restrict their total transmission rate to
  3578.    the rate of the shared bandwidth.  Multi-site conferences could use
  3579.    such a capability to avoid allocating full bandwidth for voice data
  3580.    for all conference members.  Instead, bandwidth for, say, four active
  3581.    voices at once could be allocated and shared, and voice messages
  3582.    would only be lost when more than four people tried to talk at once.
  3583.  
  3584.  
  3585.  
  3586. Edmond                                                         [Page 64]
  3587.  
  3588. RFC 1221                          HAP2                        April 1991
  3589.  
  3590.  
  3591.    The Create Shared Stream Request would use a different request code
  3592.    than Create Stream Request, and the setup message would likely
  3593.    contain at least one additional field to identify the set of shared
  3594.    streams.  Change and Delete Stream requests could be used for both
  3595.    shared and non-shared streams.
  3596.  
  3597. 12. Appendix B -- Backward compatibility
  3598.  
  3599.    The WPS will support the use of HAP version 0 by hosts until all
  3600.    hosts have upgraded to version 1.  The WPS determines which HAP
  3601.    version the host is using by examining the Restart Request and/or
  3602.    Restart Complete control messages sent by the host to the WPS.  If
  3603.    the host initiates a restart and thus sends both a Restart Request
  3604.    and a Restart Complete, and if the HAP version numbers in the two
  3605.    messages differ, the version number in the Restart Complete will
  3606.    prevail.  The WPS will always set the version number to 1.  If the
  3607.    host sends 0 in the version number field, version 0 compatiblity mode
  3608.    will be invoked.
  3609.  
  3610.    Version 0 of HAP did not contain the PROTOCOL ID field in the
  3611.    datagram and stream message headers.  Instead, the IL bit in the Type
  3612.    of Service word was used to indicate the presence or absence of an
  3613.    Internet Protocol (IP) header (any version number) following the HAP
  3614.    header.  This is the original description of that bit:
  3615.  
  3616.      3[1]   Internet/Local Flag.  This flag is set by a source host to
  3617.             specify to a destination host whether the data portion of
  3618.             the message contains an Internet Protocol (IP) header [3].
  3619.             This field is passed transparently by the source and
  3620.             destination WPSen for traffic between network hosts.  This
  3621.             field is examined by WPS Agents in order to support
  3622.             Internet operation.
  3623.  
  3624.                  0 = Internet
  3625.                  1 = Local
  3626.  
  3627.    Conversion Algorithms
  3628.  
  3629.    Link control messages (e.g., Restart Request) do not require
  3630.    conversion.  Datagram and stream messages sent by or to a host
  3631.    running HAP version 0 will be converted by the WPS.  Message
  3632.    conversion will probably cause the maximum throughput of hosts using
  3633.    HAP version 0 to be somewhat lower than that of hosts using HAP
  3634.    version 1.
  3635.  
  3636.    HAP version 0 used the IL bit in the HAP Type of Service word to
  3637.    indicate the presence or absence of an IP header.  Version 1 uses the
  3638.    Protocol ID field.  To convert host-to-WPS messages, the IL bit will
  3639.  
  3640.  
  3641.  
  3642. Edmond                                                         [Page 65]
  3643.  
  3644. RFC 1221                          HAP2                        April 1991
  3645.  
  3646.  
  3647.    be cleared, and the protocol ID field will be inserted, with the
  3648.    value indicated:
  3649.  
  3650.         IL was   Destination   Protocol ID set to:
  3651.         ------  -------------  ---------------------
  3652.           0          any       HAP_PROTO_IP  (0x800)
  3653.           1     Service Agent  HAP_PROTO_SETUP (1)
  3654.           1         other      HAP_PROTO_NONE  (0)
  3655.  
  3656.      To convert WPS-to-host messages, the protocol ID field will be
  3657.      deleted, and the IL bit will be set by:
  3658.                IL = (protocol_id was HAP_PROTO_IP) ? 0 : 1;
  3659.  
  3660.      HAP_PROTO_IP (see Appendix C) will be used for IP "versions" 3
  3661.      (GG protocol), 4 (IP), and 5 (ST).
  3662.  
  3663.    The datagram message header fields TTL and PRI have been swapped in
  3664.    HAP version 0 compared to version 1.  The conversion code swaps the
  3665.    contents of these two fields for hosts running version 0.
  3666.  
  3667.    The stream message header field TTL in HAP version 0 was replaced by
  3668.    the PRE field in version 1.  Since the only permitted value of TTL
  3669.    was 1, and it is a valid PRE value, no conversion is necessary.
  3670.  
  3671.    In HAP version 0, messages between a host and the Service Agent were
  3672.    allowed to contain Internet Protocol headers.  No hosts use that
  3673.    capability, so no provision will be made to accommodate IP headers in
  3674.    Setups between hosts and the Service Agent.
  3675.  
  3676.    In version 0, the Restart Request control message contained a "reason
  3677.    for restart" field.  That field was ignored in all current
  3678.    implementations and has been eliminated in version 1.
  3679.  
  3680.    Current implementations expect the WPS to insert an "incarnation
  3681.    count" in bits 5-10 of the first word of both Restart Request and
  3682.    Restart Complete messages.  This functionality has been replaced by
  3683.    the "SL" bit in the Restart Complete message in version 1.
  3684.    Compatibility code will be added if needed, but it is expected that
  3685.    none will be needed.
  3686.  
  3687. 13. Appendix C -- HAP Protocol ID Assigned Numbers
  3688.  
  3689.    This section lists the values of the PROTOCOL ID field.  This part of
  3690.    the specification will be obsolete when a version of the Assigned
  3691.    Numbers RFC containing HAP protocol ID numbers is issued.
  3692.  
  3693.    HAP adopts the Ether-type numbers in the 1500-65535 range.  Protocol
  3694.    IDs 256-511 identify ISO protocols.  Zero indicates the absence of a
  3695.  
  3696.  
  3697.  
  3698. Edmond                                                         [Page 66]
  3699.  
  3700. RFC 1221                          HAP2                        April 1991
  3701.  
  3702.  
  3703.    higher level protocol header.  Other protocol IDs are reserved for
  3704.    future assignment.
  3705.  
  3706.  
  3707.              Protocol ID     Indicates
  3708.              -----------     ---------
  3709.                   0          No higher level protocol
  3710.                   1          For Network Service Agent messages
  3711.                 2-255        Reserved
  3712.                256-511       ISO protocol identifier + 256
  3713.                512-1499      Reserved
  3714.               1500-65535     Identical to Ether-type [10].
  3715.  
  3716.                           HAP PROTOCOL ID NUMBERS
  3717.                                  Figure 42
  3718.  
  3719. REFERENCES
  3720.  
  3721.     1. Falk, G., Groff, S., Koolish, R., and W. Milliken, "PSAT
  3722.        Technical Report", BBN Technical Report No. 4469, Chapter 4, May
  3723.        1981.
  3724.  
  3725.     2. Rees, T., Editor, "A Host Access Protocol Specification", BBN
  3726.        Laboratories, Inc., May 1987.  (A revision of RFC 907 that was
  3727.        distributed to DARPA and the WBNET user community but not
  3728.        resubmitted as an RFC.)
  3729.  
  3730.     3. Postel, J., Editor, "Internet Protocol - DARPA Internet Program
  3731.        Protocol Specification", RFC 791, USC/Information Sciences
  3732.        Institute, September 1981.
  3733.  
  3734.     4. Topolcic, C., Editor, "Experimental Internet Stream Protocol,
  3735.        Version 2 (ST-II)", RFC 1190, Bolt Beranek and Newman, Inc.,
  3736.        October 1990.
  3737.  
  3738.     5. Edmond, W., Seo, K., Leib, M., and C. Topolcic, "The DARPA
  3739.        Wideband Network Dual Bus Protocol", Proceedings of ACM SIGCOMM
  3740.        '90, pages 79-89, September 24-27, 1990.
  3741.  
  3742.     6. "Host/SATNET Protocol", Internet Engineering Note (IEN) 192, July
  3743.        1981.
  3744.  
  3745.     7. Evenchik, L., McNeill, D., Bressler, R., Owen, A., Rice, Jr., R.,
  3746.        Trout, G., Pavey, C., Damer, R., Deckelman, F., and T. Hughes,
  3747.        "MATNET, An Experimental Navy Shipboard Satellite Communications
  3748.        Network", Proceedings of INFOCOM '82, pages 3-11, March 30 -
  3749.        April 1, 1982.
  3750.  
  3751.  
  3752.  
  3753.  
  3754. Edmond                                                         [Page 67]
  3755.  
  3756. RFC 1221                          HAP2                        April 1991
  3757.  
  3758.  
  3759.     8. Falk, G., Groff, J., Milliken, W., Nodine, M., Blumenthal, S.,
  3760.        and W. Edmond, "Integration of Voice and Data in the Wideband
  3761.        Packet Satellite Network", IEEE Journal on Selected Areas in
  3762.        Communications, Vol. SAC-1, No. 6, December 1983.
  3763.  
  3764.     9. "Interface Message Processor: Specifications for the
  3765.        Interconnection of a Host and an IMP", BBN Technical Report No.
  3766.        1822, October 1980.
  3767.  
  3768.    10. Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  3769.        USC/Information Sciences Institute, March 1990.
  3770.  
  3771. Security Considerations
  3772.  
  3773.    Security issues are not discussed in this memo.
  3774.  
  3775. Author's Address
  3776.  
  3777.    Winston Edmond
  3778.    Bolt Beranek and Newman, Inc.
  3779.    Network Technologies Department
  3780.    10 Moulton Street
  3781.    Cambridge, Massachusetts 02138
  3782.  
  3783.    Phone: (617) 873-3000
  3784.  
  3785.    EMail: wbe@bbn.com
  3786.  
  3787.  
  3788.  
  3789.  
  3790.  
  3791.  
  3792.  
  3793.  
  3794.  
  3795.  
  3796.  
  3797.  
  3798.  
  3799.  
  3800.  
  3801.  
  3802.  
  3803.  
  3804.  
  3805.  
  3806.  
  3807.  
  3808.  
  3809.  
  3810. Edmond                                                         [Page 68]
  3811.