transmitter's messages, only allowing the receiver to provide
software loops. A receiver may not be able to interpret the
transmitter's messages as it is looping them back. If such
interpretation is possible, however, the receiver will not act on any
of the transmitter's messages other than requests to reinitialize the
WPS-host link (Restart Request (RR) control messages; see Section 8.)
When a receiver initiates a loopback condition in response to a
loopback request, it makes an implicit promise to maintain the
condition for the duration specified in the Loopback Request message.
However, if an unanticipated condition such as a system restart
occurs in either the transmitter or the receiver, the affected unit
will try to reinitialize the WPS-host link by sending an RR message
to the other unit. If the RR message is recognized by the other
unit, a link initialization sequence can be completed. This will
restore the link to an unlooped condition even if the specified loop
duration has not yet expired. If a receiver cannot interpret a
transmitter's RR messages, and in the absence of operator
intervention at the receiver, the loop will remain in place for its
duration.
HAP does not specify the characteristics of any loopback conditions
that may be locally implemented by a given unit. An example of such
a condition is that obtained when a WPS commands its host interface
to loop back its own messages. If such local loop conditions also
cause the reflection of messages received from the remote unit, the
remote unit will detect the condition via the HAP header Loopback
indicator.
A specific sequence must be followed for setting up a remote
loopback. It begins after the HAP link has been initialized and a
decision is made to request a remote loop. The transmitter then
sends a Loopback Request message (Figure 39) to the receiver and
waits for either (1) a 10-second timer to expire, (2) a "Can't
implement loop" Unnumbered Response message from the receiver, or (3)
one of its own reflected messages. If event (1) or (2) occurs the
request has failed and the transmitter may, at its option, try again
with a new Loopback Request message. If event (3) occurs, the remote
loopback condition has been established. While waiting for one of
these events, messages from the receiver are processed normally.
Note that RR messages arriving from the receiver during this time
will terminate the loopback request.
When a receiver gets a Loopback Request message, it either implements
the requested loop for the specified duration, or returns a "Can't
implement loop" response without changing the state of the link. The
latter response would be returned, for example, if a receiver is
incapable of implementing a requested hardware loop. A receiver
should initiate reinitialization of the link with an RR message(s)
whenever a loopback condition times out.
There is one asymmetry that is required in the above sequence to
resolve the (unlikely) case where both WPS and host request a remote
loopback at the same time. If a WPS receives a Loopback Request
message from a host while it is itself waiting for an event of type
(1)-(3), it will return a "Can't implement loop" response to the host
and will continue to wait. A host in the converse situation,
however, will abort its loopback request and will instead act on the
WPS's loopback request.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | LOOP TYPE | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | LOOP DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LOOPBACK REQUEST
Figure 39
0[0] Message Type = 1 (Control Message).
0[1] Loopback indicator.
0[2-3] Go-Priority.
0[4-7] Reserved. Must be zero.
0[8-11] Loop Type. This field indicates the type of loop that
is being requested as follows:
0 = Undefined
1 = Loop at interface (hardware loop)
2 = Loop at driver (software loop)
3-15 = Undefined
0[12-15] Control Message Type = 8 (Loopback Request).
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-2 (excluding the
checksum word itself).
2[0-15] Loop Duration. The transmitter of a Loopback Request
message uses this field to specify the number of
seconds that the loop is to be maintained by the
receiver.
10. Other Control Messages
Before a WPS or a host voluntarily disables a WPS-host link, it
should send at least one Link Going Down control message (Figure 40)
over that link. HAP does not define the action(s) that should be
taken by a WPS or a host when such a message is received; informing
the Network Operations Center (NOC) and/or the network users of the
impending event is a typical course of action. Note that each Link
Going Down message only pertains to the WPS-host link that it is sent
over; if a host and a WPS are connected by multiple links, these
links may be selectively disabled.
A No Operation (NOP) control message (Figure 41) may be sent at any
time by a WPS or a host. A NOP message contains up to 32 words of
arbitrary data which are undefined by HAP. NOP messages may be
required in some cases to clear the state of the WPS-host link
hardware.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | REASON | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | TIME UNTIL DOWN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | DOWN DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LINK GOING DOWN
Figure 40
0[0] Message Type = 1 (Control Message).
0[1] Loopback indicator.
0[2-3] Go-Priority.
0[4-7] Reserved. Must be zero.
0[8-11] Reason. This field is used by the WPS or the host to
indicate the reason for disabling this WPS-host link as
follows:
0 = Cancel previous notice, not going down
1 = Unspecified reason
2 = Scheduled PM
3 = Scheduled hardware work
4 = Scheduled software work
5 = Emergency restart
6 = Power outage
7 = Software breakpoint
8 = Hardware failure
9 = Not scheduled up
10 = Last warning: The WPS or host will disable
the link in 10 seconds
11-15 = Undefined
0[12-15] Control Message Type = 7 (Link Going Down).
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-3 (excluding the
checksum word itself).
2[0-15] Time Until Down. This field specifies the amount of
time remaining until the WPS or host disables the link
(in minutes). An entry of zero indicates that there is
less than a minute remaining.
3[0-15] Down Duration. This field specifies the amount of time
that the WPS-host link will be down (in minutes). An
entry of zero indicates that the down duration will be
less than a minute. An entry of -1 (all bits set)
indicates an indefinite down duration.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| 0 | LENGTH | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
2-N : ARBITRARY DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NO OPERATION (NOP)
Figure 41
0[0] Message Type = 1 (Control Message).
0[1] Loopback indicator.
0[2-6] Reserved. Must be zero.
0[7-11] Length. The number of words of arbitrary data.
0[12-15] Control Message Type = 6 (NOP).
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-N (excluding the
checksum word itself).
2-N Arbitrary Data. Up to 32 words of data may be sent.
The data are undefined by HAP.
11. Appendix A -- Future Extensions
The extensions to HAP described below are included to provide
additional context for the understanding of HAP's current
capabilities, as well as suggest how HAP may be enhanced in the
future to provide better support for multi-site conferencing. These
capabilities are not supported by TWBNET.
One change under consideration is the addition of a "conference"
resource, which would own some number of streams and groups and
improve the network's ability to meet the needs of video conference
users. A single request to modify the "conference", such as to add a
new member, would result in modifying all the streams in the
conference to include the new member, modifying the conference's
primary group address to add the new member, etc., in a single
network operation. Such a capability would not only simplify
conference resource management for hosts, but also reduce the number
of network setup operations, permit more nearly "atomic" decisions of
whether a particular conference modification is possible, and reduce
the problem of recovery if modification is not possible.
Another change under consideration is the addition of "shared
streams." This capability would allow hosts to share a single
allocation of network bandwidth (and other resources) wherever the
streams shared a common communication path. Hosts using a shared
stream must be willing to restrict their total transmission rate to
the rate of the shared bandwidth. Multi-site conferences could use
such a capability to avoid allocating full bandwidth for voice data
for all conference members. Instead, bandwidth for, say, four active
voices at once could be allocated and shared, and voice messages
would only be lost when more than four people tried to talk at once.
The Create Shared Stream Request would use a different request code
than Create Stream Request, and the setup message would likely
contain at least one additional field to identify the set of shared
streams. Change and Delete Stream requests could be used for both
shared and non-shared streams.
12. Appendix B -- Backward compatibility
The WPS will support the use of HAP version 0 by hosts until all
hosts have upgraded to version 1. The WPS determines which HAP
version the host is using by examining the Restart Request and/or
Restart Complete control messages sent by the host to the WPS. If
the host initiates a restart and thus sends both a Restart Request
and a Restart Complete, and if the HAP version numbers in the two
messages differ, the version number in the Restart Complete will
prevail. The WPS will always set the version number to 1. If the
host sends 0 in the version number field, version 0 compatiblity mode
will be invoked.
Version 0 of HAP did not contain the PROTOCOL ID field in the
datagram and stream message headers. Instead, the IL bit in the Type
of Service word was used to indicate the presence or absence of an
Internet Protocol (IP) header (any version number) following the HAP
header. This is the original description of that bit:
3[1] Internet/Local Flag. This flag is set by a source host to
specify to a destination host whether the data portion of
the message contains an Internet Protocol (IP) header [3].
This field is passed transparently by the source and
destination WPSen for traffic between network hosts. This
field is examined by WPS Agents in order to support
Internet operation.
0 = Internet
1 = Local
Conversion Algorithms
Link control messages (e.g., Restart Request) do not require
conversion. Datagram and stream messages sent by or to a host
running HAP version 0 will be converted by the WPS. Message
conversion will probably cause the maximum throughput of hosts using
HAP version 0 to be somewhat lower than that of hosts using HAP
version 1.
HAP version 0 used the IL bit in the HAP Type of Service word to
indicate the presence or absence of an IP header. Version 1 uses the
Protocol ID field. To convert host-to-WPS messages, the IL bit will
be cleared, and the protocol ID field will be inserted, with the
value indicated:
IL was Destination Protocol ID set to:
------ ------------- ---------------------
0 any HAP_PROTO_IP (0x800)
1 Service Agent HAP_PROTO_SETUP (1)
1 other HAP_PROTO_NONE (0)
To convert WPS-to-host messages, the protocol ID field will be
deleted, and the IL bit will be set by:
IL = (protocol_id was HAP_PROTO_IP) ? 0 : 1;
HAP_PROTO_IP (see Appendix C) will be used for IP "versions" 3
(GG protocol), 4 (IP), and 5 (ST).
The datagram message header fields TTL and PRI have been swapped in
HAP version 0 compared to version 1. The conversion code swaps the
contents of these two fields for hosts running version 0.
The stream message header field TTL in HAP version 0 was replaced by
the PRE field in version 1. Since the only permitted value of TTL
was 1, and it is a valid PRE value, no conversion is necessary.
In HAP version 0, messages between a host and the Service Agent were
allowed to contain Internet Protocol headers. No hosts use that
capability, so no provision will be made to accommodate IP headers in
Setups between hosts and the Service Agent.
In version 0, the Restart Request control message contained a "reason
for restart" field. That field was ignored in all current
implementations and has been eliminated in version 1.
Current implementations expect the WPS to insert an "incarnation
count" in bits 5-10 of the first word of both Restart Request and
Restart Complete messages. This functionality has been replaced by
the "SL" bit in the Restart Complete message in version 1.
Compatibility code will be added if needed, but it is expected that
none will be needed.
13. Appendix C -- HAP Protocol ID Assigned Numbers
This section lists the values of the PROTOCOL ID field. This part of
the specification will be obsolete when a version of the Assigned
Numbers RFCcontaining HAP protocol ID numbers is issued.
HAP adopts the Ether-type numbers in the 1500-65535 range. Protocol
IDs 256-511 identify ISO protocols. Zero indicates the absence of a
higher level protocol header. Other protocol IDs are reserved for
future assignment.
Protocol ID Indicates
----------- ---------
0 No higher level protocol
1 For Network Service Agent messages
2-255 Reserved
256-511 ISO protocol identifier + 256
512-1499 Reserved
1500-65535 Identical to Ether-type [10].
HAP PROTOCOL ID NUMBERS
Figure 42
REFERENCES
1. Falk, G., Groff, S., Koolish, R., and W. Milliken, "PSAT
Technical Report", BBN Technical Report No. 4469, Chapter 4, May
1981.
2. Rees, T., Editor, "A Host Access Protocol Specification", BBN
Laboratories, Inc., May 1987. (A revision of RFC907 that was
distributed to DARPA and the WBNET user community but not
resubmitted as an RFC.)
3. Postel, J., Editor, "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC791, USC/Information Sciences
Institute, September 1981.
4. Topolcic, C., Editor, "Experimental Internet Stream Protocol,
Version 2 (ST-II)", RFC1190, Bolt Beranek and Newman, Inc.,
October 1990.
5. Edmond, W., Seo, K., Leib, M., and C. Topolcic, "The DARPA
Wideband Network Dual Bus Protocol", Proceedings of ACM SIGCOMM
'90, pages 79-89, September 24-27, 1990.
6. "Host/SATNET Protocol", Internet Engineering Note (IEN) 192, July
1981.
7. Evenchik, L., McNeill, D., Bressler, R., Owen, A., Rice, Jr., R.,
Trout, G., Pavey, C., Damer, R., Deckelman, F., and T. Hughes,
"MATNET, An Experimental Navy Shipboard Satellite Communications
Network", Proceedings of INFOCOM '82, pages 3-11, March 30 -
April 1, 1982.
8. Falk, G., Groff, J., Milliken, W., Nodine, M., Blumenthal, S.,
and W. Edmond, "Integration of Voice and Data in the Wideband
Packet Satellite Network", IEEE Journal on Selected Areas in
Communications, Vol. SAC-1, No. 6, December 1983.
9. "Interface Message Processor: Specifications for the
Interconnection of a Host and an IMP", BBN Technical Report No.
1822, October 1980.
10. Reynolds, J., and J. Postel, "Assigned Numbers", RFC1060,
USC/Information Sciences Institute, March 1990.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Winston Edmond
Bolt Beranek and Newman, Inc.
Network Technologies Department
10 Moulton Street
Cambridge, Massachusetts 02138
Phone: (617) 873-3000
EMail: wbe@bbn.com