Add new files for HARP3

Host ATM Research Platform (HARP), Network Computing Services, Inc.
This software was developed with the support of the Defense Advanced
Research Projects Agency (DARPA).

9 files changed, 1274 insertions, 0 deletions

diff --git a/share/examples/atm/NOTES b/share/examples/atm/NOTES
new file mode 100644
index 0000000..6317188
--- /dev/null
+++ b/share/examples/atm/NOTES
@@ -0,0 +1,54 @@
+
+                                   HARP Notes
+                                   1998-09-14
+
+This is a list of currently known incompatibilities and miscellaneous gotchas 
+in HARP.  
+
+To report new items, please send mail to harp-bugs@magic.net.
+
+================================================================================
+
+
+Efficient Driver and DMA sizes
+==============================
+
+The Efficient adapter moves PDUs between host memory and adapter memory with 
+the help of DMA descriptor lists. Each DMA descriptor consists of two words. 
+Word 0 contains a DMA type identifier and a repetition count. Word 1 contains 
+the physical (not virtual) host buffer address. Each DMA type is really an 
+encoding of the burst size for the DMA. (See /usr/src/sys/dev/hea/eni.h for
+more on the DMA types.) HARP was originally developed using burst sizes of 
+8_WORD, 4_WORD, and 1_WORD sizes. Each DMA request would be built to first 
+move as much data as possible using an 8_WORD burst. This should leave 0-7 
+words left over. If there were more than 3 words remaining, a 4_WORD DMA burst 
+would be scheduled. The remaining data must then be 0-3 words in length and 
+would be moved with 1_WORD bursts. The use of large burst sizes makes more 
+efficient use of DMA by performing the same amount of work in fewer cycles.
+
+Several users have reported problems with DMA which were characterized by error
+messages of the form:
+
+	"eni_output: Transmit drain queue is full. Resources will be lost."
+or
+	"eni_output: not enough room in DMA queue".
+
+It was determined that these systems do not support the use of four- or 
+eight-word DMA bursts.  To resolve this problem, HARP now #ifdef's around the 
+8_WORD and 4_WORD DMA setup and #undef's both values by default. This results 
+in the default operation of the Efficient driver to use only 1_WORD DMA bursts.
+
+If you wish to experiment with larger DMA bursts, you can edit the file
+/usr/src/sys/dev/hea/eni_transmit.c and change the #undef to a #define for 
+DMA_USE_8WORD and/or DMA_USE_4WORD. You will need to rebuild and install your 
+kernel for this change to take effect.
+
+We are exploring solutions which would allow HARP to determine which DMA bursts
+are supported by the system at run-time.  This would allow the Efficient device
+driver to make use of larger, more efficient burst sizes where supported 
+without halting on systems which can't support the larger sizes.
+
+
+
+	@(#) $Id: NOTES,v 1.1 1997/08/22 22:11:17 mks Exp $
+
diff --git a/share/examples/atm/README b/share/examples/atm/README
new file mode 100644
index 0000000..73aa747
--- /dev/null
+++ b/share/examples/atm/README
@@ -0,0 +1,140 @@
+
+		===================================
+		HARP  |  Host ATM Research Platform
+		===================================
+
+		              HARP 3
+
+
+What is this stuff?
+-------------------
+The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
+Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
+the Host ATM Research Platform (HARP) software, which allows IP hosts to
+communicate over ATM networks using standard protocols.  It is intended to
+be a high-quality platform for IP/ATM research.
+
+HARP provides a way for IP hosts to connect to ATM networks.  It supports 
+standard methods of communication using IP over ATM.  A host's standard IP 
+software sends and receives datagrams via a HARP ATM interface.  HARP provides 
+functionality similar to (and typically replaces) vendor-provided ATM device 
+driver software.
+
+HARP includes full source code, making it possible for researchers to
+experiment with different approaches to running IP over ATM.  HARP is 
+self-contained; it requires no other licenses or commercial software packages.
+
+HARP implements support for the IETF Classical IP model for using IP over ATM 
+networks, including:
+
+   o IETF ATMARP address resolution client
+   o IETF ATMARP address resolution server
+   o IETF SCSP/ATMARP server
+   o UNI 3.1 and 3.0 signalling protocols
+   o Fore Systems's SPANS signalling protocol
+
+
+
+What's supported
+----------------
+The following are supported by HARP 3:
+
+   o ATM Host Interfaces
+	- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
+	- FORE Systems, Inc. PCA-200E ATM PCI Adapters
+	- Efficient Networks, Inc. ENI-155p ATM PCI Adapters
+
+   o ATM Signalling Protocols
+	- The ATM Forum UNI 3.1 signalling protocol
+	- The ATM Forum UNI 3.0 signalling protocol
+	- The ATM Forum ILMI address registration
+	- FORE Systems's proprietary SPANS signalling protocol
+	- Permanent Virtual Channels (PVCs)
+
+   o IETF "Classical IP and ARP over ATM" model
+	- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
+	- RFC 1577, "Classical IP and ARP over ATM"
+	- RFC 1626, "Default IP MTU for use over ATM AAL5"
+	- RFC 1755, "ATM Signaling Support for IP over ATM"
+	- RFC 2225, "Classical IP and ARP over ATM"
+	- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
+	- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
+		"A Distributed ATMARP Service Using SCSP"
+
+   o ATM Sockets interface
+	- The file atm-sockets.txt contains further information
+
+
+What's not supported
+--------------------
+The following major features of the above list are not currently supported:
+
+	o UNI point-to-multipoint support
+	o Driver support for Traffic Control/Quality of Service
+	o SPANS multicast and MPP support
+	o SPANS signalling using Efficient adapters
+
+
+For further information
+-----------------------
+For additional information about HARP, please see:
+
+	http://www.msci.magic.net
+
+
+Suggestions and Problem Reports
+-------------------------------
+While HARP is made available "as is" and is not supported, ANG is continuing
+development of HARP.  We welcome suggestions for new or enhanced features, 
+summaries of your experience with HARP, as well as reports of problems which
+you may experience.  Feel free to contact us at harp-bugs@magic.net.
+
+ANG is maintaining a mail list of those who wish to share their experiences
+with HARP, learn of others' experiences, or receive information about future 
+releases of HARP.  The HARP mailing list is at harp@magic.net.  To be added
+to the list, send email to harp-request@magic.net.
+
+
+Acknowledgments
+---------------
+This software was developed under the sponsorship of the Defense Advanced 
+Research Projects Agency (DARPA).
+
+
+Citing HARP
+-----------
+When citing HARP in published works, please use the following citation:
+
+Host ATM Research Platform (HARP), Network Computing Services, Inc.
+This software was developed with the support of the Defense Advanced
+Research Projects Agency (DARPA).
+
+
+Copyright and Permitted Use
+---------------------------
+The Host ATM Research Platform ("HARP") software (the "Software") is
+made available by Network Computing Services, Inc. ("NetworkCS")
+"AS IS".  NetworkCS does not provide maintenance, improvements or
+support of any kind.
+
+NETWORKCS MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED,
+INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY
+AND FITNESS FOR A PARTICULAR PURPOSE, AS TO ANY ELEMENT OF THE
+SOFTWARE OR ANY SUPPORT PROVIDED IN CONNECTION WITH THIS SOFTWARE.
+In no event shall NetworkCS be responsible for any damages, including
+but not limited to consequential damages, arising from or relating to
+any use of the Software or related support.
+
+Copyright 1994-1998 Network Computing Services, Inc.
+
+Copies of this Software may be made, however, the above copyright
+notice must be reproduced on all copies.
+
+Portions of this Software include materials copyrighted by the Regents of
+the University of California and by Sun Microsystems, Inc.  The applicable
+copyright notices are reproduced in the files where the material appears.
+
+--------------------------------------------------------------------------------
+
+	@(#) $Id: README,v 1.4 1998/08/07 19:23:36 mks Exp $
+
diff --git a/share/examples/atm/Startup b/share/examples/atm/Startup
new file mode 100644
index 0000000..4c0ec7d
--- /dev/null
+++ b/share/examples/atm/Startup
@@ -0,0 +1,127 @@
+HARP ATM Startup Configuration Instructions
+===========================================
+
+The following steps are required in order to use the HARP ATM software.
+See the file atm-config.sh for an example ATM startup script.
+
+1.  Each ATM physical interface must be configured with one or more network
+    interfaces.  The physical interfaces are named:
+
+	FORE Systems: hfa0, hfa1, ...
+	Efficient Networks: hea0, hea1, ...
+
+    The network interface names and the number of network interfaces for a
+    particular physical interface are specified via the atm command.  The
+    network interface name prefix may be any alphabetic string, but the 
+    generated network interface names must be unique amongst all network
+    interfaces, including non-ATM interfaces.
+
+    To configure the network interfaces, type:
+
+	atm set netif <interface_name> <netif_prefix> <netif_count>
+
+    For example, the command:
+
+	atm set netif hfa0 ni 3
+
+    will generate the network interfaces ni0, ni1 and ni2 on the physical
+    interface hfa0.
+
+    For further details, see the man page atm(8).
+
+
+2.  Each ATM network interface (netif) must be configured with an IP network
+    address.  Each network interface must be on a different IP subnet.
+
+    To configure the network interface, type:
+
+	ifconfig <netif_name> <IP_address> up
+
+
+3.  Each ATM physical interface must have a signalling manager attached.  The
+    interfaces may have the same or different signalling managers.
+ 
+    To attach a signalling manager, type:
+
+	atm attach <interface_name> <signalling_manager_name>
+
+	where <signalling_manager_name> may be:
+
+		sigpvc - to only support PVCs on the interface;
+		spans - to run FORE Systems SPANS signalling protocol across 
+			the interface, plus support of PVCs;
+		uni30 - to run ATM Forum UNI 3.0 signalling protocol across 
+			the interface, plus support of PVCs;
+		uni31 - to run ATM Forum UNI 3.1 signalling protocol across 
+			the interface, plus support of PVCs;
+
+    For further details, see the man page atm(8).
+
+
+4.  Each of the host's PVCs (if any) must be defined.  
+ 
+    To define a PVC, type:
+
+	atm add pvc <interface_name> <vpi> <vci> <aal> <encaps> <owner> ....
+
+	where <interface_name> is the name of the ATM physical interface 
+			over which the PVC is being defined;
+	      <vpi> is the VPI value for the PVC;
+	      <vci> is the VCI value for the PVC;
+	      <aal> is the AAL type which the PVC endpoints will use;
+	      <encaps> is the encapsulation which the PVC endpoints will use;
+	      <owner> specifies the the owner of the PVC, which may be:
+			ip - the PVC is used for IP traffic;
+
+	additional parameters may be required, depending on the PVC owner:
+
+	for owner=ip,
+	      <netif_name> is the name of the PVC's network interface;
+	      <dst> specifies the IP address at the remote end of this PVC;
+
+    For further details, see the man page atm(8).
+
+
+5.  HARP includes an ILMI daemon, which will perform host address registration
+    with the ATM switch for ATM Forum UNI interfaces.  If ILMI support is
+    available and activated in the ATM switch and the ILMI daemon is running
+    (see ilmid(8)), no further registration procedures are required.  
+    The 'atm set prefix' command is not needed in this case.
+
+    If ILMI address registration support is not available or activated, then
+    the host must be manually registered with its switch.  There should be
+    a user command available on the switch in order to do the registration.
+
+    For example, if you are using a FORE Systems switch, you should enter
+    the following AMI command:
+
+	> conf nsap route new <host_nsap> 152 <switch_port> 0 
+
+    If you are using a Cisco LightStream 1010 switch, you would use the
+    following configuration command:
+
+       > atm route <host_nsap> atm <atm_interface_#> internal
+
+    For ATM Forum UNI interfaces, the 'atm set prefix' command must also
+    be issued when not using ILMI address registration.
+
+
+6.  HARP includes support for the Server Cache Synchronization Protocol (SCSP),
+    which can synchronize the ATMARP caches of multiple ATMARP servers.
+    Obviously, this is only useful on hosts which are ATMARP servers.
+
+    To run SCSP between servers, two daemons, scspd and atmarpd, must be
+    started.  Scspd implements the SCSP protocol and atmarpd provides an
+    interface between scspd and the ATMARP server in the kernel.  Scspd
+    requires a configuration file.  It will look for a configuration
+    file at /etc/scspd.conf unless told otherwise.
+    
+    An example of commands to start the two daemons is:
+
+	# scspd
+	# atmarpd <netif>
+
+    See the man pages scspd(8) and atmarpd(8) for further information.
+
+	@(#) $Id: Startup,v 1.6 1998/08/26 21:37:42 johnc Exp $
+
diff --git a/share/examples/atm/atm-config.sh b/share/examples/atm/atm-config.sh
new file mode 100755
index 0000000..40606d4
--- /dev/null
+++ b/share/examples/atm/atm-config.sh
@@ -0,0 +1,88 @@
+#! /bin/sh
+#
+#
+# ===================================
+# HARP  |  Host ATM Research Platform
+# ===================================
+#
+#
+# This Host ATM Research Platform ("HARP") file (the "Software") is
+# made available by Network Computing Services, Inc. ("NetworkCS")
+# "AS IS".  NetworkCS does not provide maintenance, improvements or
+# support of any kind.
+#
+# NETWORKCS MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED,
+# INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS FOR A PARTICULAR PURPOSE, AS TO ANY ELEMENT OF THE
+# SOFTWARE OR ANY SUPPORT PROVIDED IN CONNECTION WITH THIS SOFTWARE.
+# In no event shall NetworkCS be responsible for any damages, including
+# but not limited to consequential damages, arising from or relating to
+# any use of the Software or related support.
+#
+# Copyright 1994-1998 Network Computing Services, Inc.
+#
+# Copies of this Software may be made, however, the above copyright
+# notice must be reproduced on all copies.
+#
+#	@(#) $Id$
+#
+#
+
+#
+# Sample script to load and configure ATM software
+#
+
+#
+# Download FORE microcode into adapter(s)
+#
+# This step is only required if you are using FORE ATM adapters.
+# This assumes that the FORE microcode file pca200e.bin is in /etc.
+# See the file fore-microcode.txt for further details.
+#
+/sbin/fore_dnld -d /etc
+
+#
+# Define network interfaces
+#
+/sbin/atm set netif hfa0 <netif_prefix> 1
+
+#
+# Configure physical interfaces
+#
+/sbin/atm attach hfa0 uni31
+
+#
+# Start ILMI daemon (optional)
+#
+/sbin/ilmid
+
+#
+# Set ATM address prefix
+#
+# Only need to set prefix if using UNI and not using ILMI daemon
+#
+#/sbin/atm set prefix hfa0 <nsap_prefix>
+
+#
+# Configure network interfaces
+#
+/sbin/ifconfig <netif> <ip_addr> netmask + up
+/sbin/atm set arpserver <netif> <atm_address>
+
+#
+# Configure PVCs (optional)
+#
+#/sbin/atm add pvc hfa0 <vpi> <vci> aal5 null ip <netif> <ip_addr>
+
+#
+# Start SCSP daemons (optional)
+#
+# This step is only required if your host is configured as an ATMARP server
+# and you wish to synchronize its cache with the cache(s) of some other
+# server(s).  Scspd will look for its configuration file at /etc/scspd.conf.
+#
+#/usr/sbin/scspd
+#/usr/sbin/atmarpd <netif> ...
+
+exit 0
+
diff --git a/share/examples/atm/atm-sockets.txt b/share/examples/atm/atm-sockets.txt
new file mode 100644
index 0000000..258a565
--- /dev/null
+++ b/share/examples/atm/atm-sockets.txt
@@ -0,0 +1,340 @@
+
+	HARP Native ATM Sockets API
+	===========================
+
+ATM sockets are an extension to the traditional BSD sockets API to allow
+direct user-level access to native ATM protocol services.  The ATM sockets
+extensions are implemented via the addition of a new protocol family (PF_ATM)
+and a new socket address structure (struct sockaddr_atm).  
+
+The HARP implementation of native ATM sockets capabilities is intended to be
+conformant with The Open Group specifications (with known differences listed 
+below) as defined in the following document:
+
+	The Open Group: Networking Services (XNS) Issue 5 
+		ISBN 1-85912-165-9
+		http://www.rdg.opengroup.org/public/pubs/catalog/c523.htm
+
+And in particular, it is based on the following ATM-specific sections in the
+above document:
+
+	ATM Transport Protocol Information for Sockets
+	ATM Transport Protocol Information for XTI
+	ATM Transport Headers
+
+The ATM sockets API is an implementation based on the definitions and
+descriptions set forth in the following document:
+
+	The ATM Forum: Native ATM Services: Semantic Description, Version 1.0
+		af-saa-0048.000
+		http://www.atmforum.com/atmforum/specs/approved.html
+
+
+Using the HARP Implementation
+-----------------------------
+This document only provides the HARP-specific information necessary for using 
+the ATM sockets API.  Please refer to the XNS document described above for
+all of the general interface specifications.  There is also sample source
+code for an ATM sockets application included at the end of this document.
+
+All user definitions for the HARP ATM sockets implementation are contained
+in the file /usr/include/netatm/atm.h.  This file must be included in the
+user's C program source file.  In this file, all HARP extensions to the base 
+XNS specifications are denoted with a comment string of "XNS_EXT".
+
+
+HARP Extensions to XNS Issue 5
+------------------------------
+o Socket address structure for ATM addresses
+
+  An ATM socket address structure was not specifically defined by XNS,
+  although the t_atm_sap structure was defined to be used as an ATM protocol
+  address.  Thus, HARP has defined an ATM socket address (using address
+  family AF_ATM) as a 'struct sockaddr_atm', which contains 'struct t_atm_sap'
+  as the protocol address.  This structure (properly cast) must be used on
+  all ATM socket system calls requiring a 'struct sockaddr' parameter.
+
+o Network Interface Selection socket option (T_ATM_NET_INTF)
+
+  This option is used to specify the name of the network interface to be
+  used to route an outgoing ATM call using a socket connection.  This option
+  is only needed when there are multiple ATM network interfaces defined on a
+  system.  If this option is not set, then the first network interface on
+  the first physical ATM interface defined will be used.
+
+  See the sample application below for an example of the use of this option.
+
+o LLC Multiplexing socket option (T_ATM_LLC)
+
+  For LLC encapsulated VCCs (BLLI Layer 2 Protocol == T_ATM_BLLI2_I8802),
+  HARP has implemented an LLC multiplexing facility.  In order to use this
+  multiplexing facility, a user must issue a setsockopt() call specifying the 
+  T_ATM_LLC option before the connect() or listen() system call is invoked.
+
+  If using the LLC multiplexor, the user will only receive PDUs which match
+  the LLC header information specified in the socket option.  The kernel 
+  multiplexing software will strip the LLC header from all inbound PDUs and 
+  add the specified LLC header to all outgoing PDUs - the user will never see 
+  the LLC header.  
+
+  For listening sockets, the listener will be notified for all incoming LLC 
+  calls (which also meet the other incoming call distribution selection 
+  criteria), since the LLC header information is only carried in the data 
+  PDUs, not in the signalling protocol.
+
+  The T_ATM_LLC_SHARING flag is used to denote whether this user wishes to
+  share the VCC with other LLC users requesting similar connection attributes 
+  to the same destination.
+
+o Application Name socket option (T_ATM_APP_NAME)
+
+  This option is used to associate an identifier string (typically, the
+  application's name) with an open ATM socket.  Currently, it is only used 
+  for the "Owner" field in the output of the 'atm show vcc' command.  If this 
+  option is not set, then the "Owner" field will default to "(AAL5)". 
+
+  See the sample application below for an example of the use of this option.
+
+o PVC support
+
+  The XNS document specifically does not provide support for ATM PVCs.
+  However, due in part to internal HARP requirements (the ILMI daemon), PVC
+  sockets are supported under the HARP implementation. 
+
+  To support PVC sockets, there is a new address format (T_ATM_PVC_ADDR) and
+  address definition (Atm_addr_pvc).   Since there is no actual signalling
+  involved in setting up a PVC, a PVC socket connection only defines the
+  local socket-to-pvc connection - the remainder of the virtual circuit through
+  the ATM network to the remote endpoint must be defined independent of the
+  local socket creation.  PVC socket connections are only allowed via the
+  connect() system call - listen()/accept() sockets cannot be supported.
+  Also, since there are no circuit parameters signalled, most of the 
+  setsockopt() options are silently ignored.
+
+o SPANS support
+
+  HARP has added ATM socket support for the FORE-proprietary SPANS address 
+  format (T_ATM_SPANS_ADDR).  A SPANS socket can only be established over 
+  an ATM physical interface which is using the SPANS signalling manager.
+  There is limited ATM socket option support - the socket options can be set, 
+  but most are silently ignored, since they are not applicable to the SPANS 
+  protocols.  The SPANS socket address support has not been thoroughly tested.
+
+o Miscellaneous user convenience typedefs, macros and defines
+
+
+XNS Issue 5 Features Not Supported in HARP
+------------------------------------------
+o ATM_PROTO_SSCOP
+
+  The socket protocol for reliable data transport (ATM_PROTO_SSCOP) is not
+  supported in this HARP release.  There is some initial skeleton code for
+  SSCOP support, but it was not completed.
+
+o Multipoint connections
+
+  The core HARP code does not provide support for multipoint connections, so,
+  obviously, multipoint socket connections are also not supported.  
+
+  The non-supported socket options are:
+	o T_ATM_ADD_LEAF
+	o T_ATM_DROP_LEAF
+	o T_ATM_LEAF_IND
+
+  The non-supported socket option values are:
+	o For the T_ATM_BEARER_CAP socket option:
+		o connection_configuration == T_ATM_1_TO_MANY
+
+
+Example ATM Socket Application
+------------------------------
+The following is a simple example application using the ATM socket API.
+
+/*
+ * ATM API sample application
+ *
+ * This application will open an ATM socket, send a text string in a PDU
+ * and then read one PDU from the socket and print its contents.
+ *
+ */
+#include <sys/param.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <net/if.h>
+#include <netatm/atm.h>
+
+#define	MAX_LEN		4096	/* Maximum PDU length */
+#define	MY_ID		11	/* BLLI Layer 2 protocol */
+#define MY_APPL		"SAMPLE"
+
+Atm_addr_nsap	dst_addr = {
+	0x47,
+	{0x00,0x05,0x80,0xff,0xdc,0x00,0x00,0x00,0x00,0x02,0xff,0xff},
+	{0x11,0x22,0x33,0x44,0x55,0x66},
+	0x00
+};
+
+static char	message[] = "Test message to send on connection";
+
+
+main(argc, argv)
+	int	argc;
+	char	**argv;
+{
+	struct sockaddr_atm	satm;
+	struct t_atm_aal5	aal5;
+	struct t_atm_traffic	traffic;
+	struct t_atm_bearer	bearer;
+	struct t_atm_qos	qos;
+	struct t_atm_net_intf	netintf;
+	struct t_atm_app_name	appname;
+	char	buffer[MAX_LEN+1];
+	int	s, n, optlen;
+
+	/*
+	 * Create socket
+	 */
+	s = socket(AF_ATM, SOCK_SEQPACKET, ATM_PROTO_AAL5);
+	if (s < 0) {
+		perror("socket");
+		exit(1);
+	}
+
+	/*
+	 * Set up destination SAP
+	 */
+	bzero((caddr_t) &satm, sizeof(satm));
+	satm.satm_family = AF_ATM;
+#if (defined(BSD) && (BSD >= 199103))
+	satm.satm_len = sizeof(satm);
+#endif
+	/* Destination ATM address */
+	satm.satm_addr.t_atm_sap_addr.SVE_tag_addr = T_ATM_PRESENT;
+	satm.satm_addr.t_atm_sap_addr.SVE_tag_selector = T_ATM_PRESENT;
+	satm.satm_addr.t_atm_sap_addr.address_format = T_ATM_ENDSYS_ADDR;
+	satm.satm_addr.t_atm_sap_addr.address_length = sizeof(Atm_addr_nsap);
+	bcopy((caddr_t)&dst_addr,
+		(caddr_t)satm.satm_addr.t_atm_sap_addr.address,
+		sizeof(dst_addr));
+
+	/* BLLI Layer-2 protocol */
+	satm.satm_addr.t_atm_sap_layer2.SVE_tag = T_ATM_PRESENT;
+	satm.satm_addr.t_atm_sap_layer2.ID_type = T_ATM_USER_ID; 
+	satm.satm_addr.t_atm_sap_layer2.ID.user_defined_ID = MY_ID; 
+
+	/* BLLI Layer-3 protocol */
+	satm.satm_addr.t_atm_sap_layer3.SVE_tag = T_ATM_ABSENT;
+
+	/* BHLI protocol */
+	satm.satm_addr.t_atm_sap_appl.SVE_tag = T_ATM_ABSENT;
+
+	/*
+	 * Set up connection parameters
+	 */
+	aal5.forward_max_SDU_size = MAX_LEN;
+	aal5.backward_max_SDU_size = MAX_LEN;
+	aal5.SSCS_type = T_ATM_NULL;
+	optlen = sizeof(aal5);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_AAL5, (caddr_t)&aal5,
+			optlen) < 0) {
+		perror("setsockopt(aal5)");
+		exit(1);
+	}
+
+	traffic.forward.PCR_high_priority = T_ATM_ABSENT;
+	traffic.forward.PCR_all_traffic = 100000;
+	traffic.forward.SCR_high_priority = T_ATM_ABSENT;
+	traffic.forward.SCR_all_traffic = T_ATM_ABSENT;
+	traffic.forward.MBS_high_priority = T_ATM_ABSENT;
+	traffic.forward.MBS_all_traffic = T_ATM_ABSENT;
+	traffic.forward.tagging = T_NO;
+	traffic.backward.PCR_high_priority = T_ATM_ABSENT;
+	traffic.backward.PCR_all_traffic = 100000;
+	traffic.backward.SCR_high_priority = T_ATM_ABSENT;
+	traffic.backward.SCR_all_traffic = T_ATM_ABSENT;
+	traffic.backward.MBS_high_priority = T_ATM_ABSENT;
+	traffic.backward.MBS_all_traffic = T_ATM_ABSENT;
+	traffic.backward.tagging = T_NO;
+	traffic.best_effort = T_YES;
+	optlen = sizeof(traffic);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_TRAFFIC, (caddr_t)&traffic,
+			optlen) < 0) {
+		perror("setsockopt(traffic)");
+		exit(1);
+	}
+
+	bearer.bearer_class = T_ATM_CLASS_X;
+	bearer.traffic_type = T_ATM_NULL;
+	bearer.timing_requirements = T_ATM_NULL;
+	bearer.clipping_susceptibility = T_NO;
+	bearer.connection_configuration = T_ATM_1_TO_1;
+	optlen = sizeof(bearer);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_BEARER_CAP, (caddr_t)&bearer,
+			optlen) < 0) {
+		perror("setsockopt(bearer)");
+		exit(1);
+	}
+
+	qos.coding_standard = T_ATM_NETWORK_CODING;
+	qos.forward.qos_class = T_ATM_QOS_CLASS_0;
+	qos.backward.qos_class = T_ATM_QOS_CLASS_0;
+	optlen = sizeof(qos);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_QOS, (caddr_t)&qos,
+			optlen) < 0) {
+		perror("setsockopt(qos)");
+		exit(1);
+	}
+
+	strncpy(netintf.net_intf, "ni0", IFNAMSIZ);
+	optlen = sizeof(netintf);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_NET_INTF, (caddr_t)&netintf,
+			optlen) < 0) {
+		perror("setsockopt(net_intf)");
+		exit(1);
+	}
+
+	strncpy(appname.app_name, MY_APPL, T_ATM_APP_NAME_LEN);
+	optlen = sizeof(appname);
+	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_APP_NAME, (caddr_t)&appname,
+			optlen) < 0) {
+		perror("setsockopt(app_name)");
+		exit(1);
+	}
+
+	/*
+	 * Now try to connect to destination
+	 */
+	if (connect(s, (struct sockaddr *) &satm, sizeof(satm)) < 0) {
+		perror("connect");
+		exit(1);
+	}
+
+	/*
+	 * Exchange message with peer
+	 */
+	if (write(s, message, sizeof(message)) != sizeof(message)) {
+		perror("write");
+		exit(1);
+	}
+
+	if ((n = read(s, buffer, MAX_LEN) < 0)) {
+		perror("read");
+		exit(1);
+	}
+
+	buffer[n] = '\0';
+	printf("received %d bytes: <%s>\n", n, buffer);
+
+	/*
+	 * Finish up
+	 */
+	if (close(s) < 0) {
+		perror("close");
+		exit(1);
+	}
+
+	exit(0);
+}
+
+	@(#) $Id: atm_sockets,v 1.1 1998/08/26 21:52:01 mks Exp $
+
diff --git a/share/examples/atm/cpcs-design.txt b/share/examples/atm/cpcs-design.txt
new file mode 100644
index 0000000..aecfa81
--- /dev/null
+++ b/share/examples/atm/cpcs-design.txt
@@ -0,0 +1,84 @@
+
+	CPCS Design
+	===========
+
+SAP_CPCS Interface
+------------------
+This is the stack SAP interface between an AAL CPCS provider and an AAL CPCS
+user.  The stack commands defined for this interface are modeled after the 
+AAL3/4 and AAL5 protocol specification primitives CPCS-xxx.  See the protocol 
+specification documents referenced below for full descriptions of the CPCS 
+interface.
+
+
+o The following stack commands are sent from a CPCS user to the CPCS provider:
+
+Stack Command:	CPCS_INIT
+Description:	Initialize a SAP instance.  This should be the first stack
+		command issued across the SAP instance after the service stack 
+		has been successfully instantiated.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	CPCS_TERM
+Description:	Terminate a SAP instance.  This must be the last stack command
+		issued across the SAP instance.  The stack instance will be
+		deleted upon completion of this command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	CPCS_UNITDATA_INV
+Description:	Request that an SDU be sent to the remote AAL user.
+Argument 1:	Pointer to an mbuf chain containing the user SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	CPCS_UABORT_INV
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+o The following stack commands are sent from the CPCS provider to a CPCS user:
+
+Stack Command:	CPCS_UNITDATA_SIG
+Description:	Indication that an SDU has been received from the remote AAL 
+		user.
+Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	CPCS_UABORT_SIG
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+Stack Command:	CPCS_PABORT_SIG
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+
+Protocol Specifications
+-----------------------
+See I.363.
+
+
+
+Implementation Limitations
+--------------------------
+o The CPCS-LP, CPCS-CI and CPCS-UU parameters are not supported.
+
+o The Streaming Mode service is not supported.
+
+o The Abort service is not supported.
+
+
+	@(#) $Id: cpcs.design,v 1.1.1.1 1996/12/04 20:48:14 mks Exp $
+
diff --git a/share/examples/atm/fore-microcode.txt b/share/examples/atm/fore-microcode.txt
new file mode 100644
index 0000000..ab1e16d
--- /dev/null
+++ b/share/examples/atm/fore-microcode.txt
@@ -0,0 +1,92 @@
+
+HARP and FORE Systems Microcode
+===============================
+
+ATM adapters from FORE Systems use Intel i960 embedded processors and 
+require that application software (herein called "microcode") be downloaded
+and executed on the adapter. The interface between the microcode and the host
+device driver is specified in the FORE ATM Adaptation Layer Interface (AALI) 
+(available from ftp.fore.com:/pub/docs/port). HARP uses microcode supplied 
+by FORE Systems. The HARP device driver for the FORE adapter (hfa) conforms 
+to the AALI specification.
+
+As part of the HARP ATM initialization procedure, the HARP 'fore_dnld' utility
+must be invoked in order to load the microcode file into each FORE adapter.
+However, the microcode file is NOT included in the FreeBSD distribution. It is 
+the user's responsibilty to obtain and install the FORE microcode file. Below 
+are notes to assist users in finding and installing microcode known to work
+with HARP. 
+
+FORE microcode files can be obtained from either FORE's web site
+(http://www.fore.com) or the CD distributed with new FORE adapters.
+When using FORE's web site, you must have a valid login to access the
+TACtics Online section of the site. The software download section is
+available via the 'Services & Support'->'TACtics Online'->Software links.
+
+If you are currently using HARP and already have a working microcode file, 
+that microcode will continue to work with this release of HARP.
+
+
+PCA200E
+-------
+
+From the FORE web pages, the following PCA200E adapter distributions
+are known to have microcode which will work with HARP:
+
+	pc_adapter->OS/2->archive->os2_4.0.2_1.20.200.zip
+		unzip the file and execute the command:
+
+		cp -p <unzip_directory>/Drivers/PCA200E.BIN /etc/pca200e.bin
+
+	pc_adapter->'Windows NT'->archive->pca2e_12.zip
+		unzip the file and execute the command:
+
+		cp -p <unzip_directory>/NT/I386/PCA200E.BIN /etc/pca200e.bin
+
+
+The following distributions from the FORE web pages are known to have 
+microcode which will NOT work with HARP:
+
+	pc_adapter:
+		OS/2:
+			release:
+				os2_4.1.0_1.74.zip
+		Windows95:
+			archive:
+				pc-w95_5.0.0.16432.zip
+				win95_4.0.3_1.04.200.zip
+				win95_4.1.6_1.16.zip
+			release:
+				pc-w95_4.1.6_27.zip
+		Windows NT:
+			archive:
+				pc-nt_5.0.0_16342.zip
+				winnt_4.0.3_1.05.200.zip
+				winnt_4.1.2_1.27.zip
+				winnt_4.1.6_1.16.zip
+			release:
+				pc-nt_4.1.6_27.zip
+				pc-nt_i386_5.0.0_25096.zip
+
+
+From the "ForeRunner 200E for PC/Mac" distribution CD-ROM, the following 
+PCA200E adapter distributions are known to have microcode which will work 
+with HARP (assuming the CD-ROM is mounted on /cdrom):
+
+	/cdrom/rel4.0/os2/
+		execute the command:
+		
+		cp -p /cdrom/rel4.0/os2/drivers/pca200e.bin /etc/pca200e.bin
+
+
+Note: Windows-based files are supplied in a compressed form. If the
+'fore_dnld' command complains about an unrecognized header format, you should
+try to uncompress the microcode file. To do so, move the file in binary mode
+to a DOS/Windows machine and use the DOS command 'expand' to uncompress the
+file. The command syntax is:
+
+	expand <in-file> <out-file>
+
+Move the resulting <out-file> in binary mode back to the HARP machine as
+/etc/pca200e.bin and try to initialize the ATM system again.
+
diff --git a/share/examples/atm/sscf-design.txt b/share/examples/atm/sscf-design.txt
new file mode 100644
index 0000000..a6e3f9e
--- /dev/null
+++ b/share/examples/atm/sscf-design.txt
@@ -0,0 +1,129 @@
+
+	SSCF UNI Design
+	===============
+
+SAP_SSCF_UNI Interface
+----------------------
+This is the stack SAP interface between the UNI signalling layer (eg. Q.2931)
+and the SSCF module.  The stack commands defined for this interface are modeled
+after the SSCF protocol specification primitives AAL-xxx.  See the protocol
+specification documents referenced below for full descriptions of the SSCF UNI
+interface presented to the signalling user.
+
+
+o The following stack commands are sent from the signalling module to SSCF:
+
+Stack Command:	SSCF_UNI_INIT
+Description:	Initialize a SAP instance.  This should be the first stack
+		command issued across the SAP instance after the service stack
+		has been successfully instantiated.
+Argument 1:	Specifies the UNI version to be used for this stack instance.
+		(enum uni_vers)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_TERM
+Description:	Terminate a SAP instance.  This must be the last stack command
+		issued across the SAP instance.  The stack instance will be
+		deleted upon completion of this command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_ESTABLISH_REQ
+Description:	Request the establishment of an assured SAAL connection to the
+		SAAL peer entity.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_RELEASE_REQ
+Description:	Request the termination of an assured SAAL connection to the
+		SAAL peer entity.
+Argument 1:	Specifies whether future session establishment indications from
+		the SAAL peer should be processed.  Valid values are 
+		SSCF_UNI_ESTIND_YES or SSCF_UNI_ESTIND_NO. (int)
+		Note that this is a local implementation parameter only.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_DATA_REQ
+Description:	Request that an assured SDU be sent to the SAAL peer.
+Argument 1:	Pointer to an mbuf chain containing the user SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_UNITDATA_REQ
+Description:	Request that an unacknowledged SDU be sent to the SAAL peer.
+Argument 1:	Pointer to an mbuf chain containing the user SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+o The following stack commands are sent from SSCF to the signalling module:
+
+Stack Command:	SSCF_UNI_ESTABLISH_IND
+Description:	Indication that an assured SAAL connection has been established
+		by the SAAL peer entity.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_ESTABLISH_CNF
+Description:	Confirmation of an assured SAAL connection establishment,
+		previously requested via an SSCF_UNI_ESTABLISH_REQ command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_RELEASE_IND
+Description:	Indication that an assured SAAL connection has been terminated
+		by the SAAL peer entity.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_RELEASE_CNF
+Description:	Confirmation of an assured SAAL connection termination,
+		previously requested via an SSCF_UNI_RELEASE_REQ command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_DATA_IND
+Description:	Indication that an assured SDU has been received from the 
+		SAAL peer.
+Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCF_UNI_UNITDATA_IND
+Description:	Indication that an unacknowledged SDU has been received from 
+		the SAAL peer.
+Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+
+Protocol Specifications
+-----------------------
+For UNI_VERS_3_0, see Q.SAAL2.
+For UNI_VERS_3_1, see Q.2130.
+
+
+
+Implementation Limitations
+--------------------------
+o The Parameter Data parameter is not supported for the following primitives:
+	AAL-ESTABLISH request
+	AAL-ESTABLISH indication
+	AAL-ESTABLISH confirm
+	AAL-RELEASE request
+	AAL-RELEASE indication
+
+
+	@(#) $Id: sscf.design,v 1.1.1.1 1996/12/04 20:48:17 mks Exp $
+
diff --git a/share/examples/atm/sscop-design.txt b/share/examples/atm/sscop-design.txt
new file mode 100644
index 0000000..009f242
--- /dev/null
+++ b/share/examples/atm/sscop-design.txt
@@ -0,0 +1,220 @@
+
+	SSCOP Design
+	============
+
+SAP_SSCOP Interface
+-------------------
+This is the stack SAP interface between the SSCOP module and an SSCOP user 
+module (eg. SSCF).  The stack commands defined for this interface are modeled 
+after the SSCOP protocol specification primitives AA-xxx.  See the protocol 
+specification documents referenced below for full descriptions of the SSCOP 
+interface presented to an SSCF.
+
+
+o The following stack commands are sent from an SSCF to SSCOP:
+
+Stack Command:	SSCOP_INIT
+Description:	Initialize a SAP instance.  This should be the first stack
+		command issued across the SAP instance after the service stack 
+		has been successfully instantiated.
+Argument 1:	Specifies the SSCOP version to be used for this stack instance.
+		(enum sscop_vers) 
+Argument 2:	Pointer to a structure containing the SSCOP protocol parameter
+		values to be used for this instance. (struct sscop_parms *)
+
+
+Stack Command:	SSCOP_TERM
+Description:	Terminate a SAP instance.  This must be the last stack command
+		issued across the SAP instance.  The stack instance will be
+		deleted upon completion of this command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_ESTABLISH_REQ
+Description:	Request the establishment of an SSCOP connection for assured 
+		information transfer to the remote peer entity.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data to be sent to the peer.
+		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
+Argument 2:	Buffer Release (BR) parameter.  Must be coded as SSCOP_BR_YES.
+		(int)
+
+
+Stack Command:	SSCOP_ESTABLISH_RSP
+Description:	Response indicating that an SSCOP connection establishment 
+		request from the remote peer is acceptable.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data to be sent to the peer.
+		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
+Argument 2:	Buffer Release (BR) parameter.  Must be coded as SSCOP_BR_YES.
+		(int)
+
+
+Stack Command:	SSCOP_RELEASE_REQ
+Description:	Request the termination of an SSCOP connection with the 
+		remote peer entity.  
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data to be sent to the peer.
+		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_DATA_REQ
+Description:	Request that an assured SDU be sent to the remote peer.
+Argument 1:	Pointer to an mbuf chain containing the user SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RESYNC_REQ
+Description:	Request the resynchronization of an SSCOP connection.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data to be sent to the peer.
+		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RESYNC_RSP
+Description:	Acknowledge the remote peer's resynchronization of an SSCOP 
+		connection.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RECOVER_RSP (Q.2110 only)
+Description:	Acknowledge the indication that the SSCOP connection has 
+		recovered from SSCOP protocol errors.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_UNITDATA_REQ
+Description:	Request that an unacknowledged SDU be sent to the remote peer.
+Argument 1:	Pointer to an mbuf chain containing the user SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RETRIEVE_REQ
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+o The following stack commands are sent from SSCOP to an SSCF:
+
+Stack Command:	SSCOP_ESTABLISH_IND
+Description:	Indication that a request to establish an SSCOP connection has 
+		been received from the remote peer entity.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data received from the peer.
+		(struct mbuf *)
+Argument 2:	Source of establish request (Q.SAAL1 only). Valid values are 
+		SSCOP_SOURCE_SSCOP or SSCOP_SOURCE_USER. (int)
+
+
+Stack Command:	SSCOP_ESTABLISH_CNF
+Description:	Confirmation from the remote peer of an SSCOP connection 
+		establishment, previously requested via an SSCOP_ESTABLISH_REQ
+		command.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data received from the peer.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RELEASE_IND
+Description:	Indication that an SSCOP connection has been terminated by 
+		the remote peer entity.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data received from the peer.
+		(struct mbuf *)
+Argument 2:	Source of release request. Valid values are SSCOP_SOURCE_SSCOP
+		or SSCOP_SOURCE_USER. (int)
+
+
+Stack Command:	SSCOP_RELEASE_CNF
+Description:	Confirmation from the remote peer of an SSCOP connection 
+		termination, previously requested via an SSCOP_RELEASE_REQ 
+		command.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_DATA_IND
+Description:	Indication that an assured SDU has been received from the 
+		remote peer.
+Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
+		(struct mbuf *)
+Argument 2:	Sequence number of the received SDU. (sscop_seq)
+
+
+Stack Command:	SSCOP_RESYNC_IND
+Description:	Indication that the remote peer has requested the
+		resynchronization of the SSCOP connection.
+Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
+		Information (SSCOP-UU / UUI) data received from the peer.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RESYNC_CNF
+Description:	Confirmation from the remote peer that an SSCOP connection
+		has been resynchronized.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RECOVER_IND (Q.2110 only)
+Description:	Indication that an SSCOP connection has recovered from SSCOP
+		protocol errors.
+Argument 1:	Not used.
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_UNITDATA_IND
+Description:	Indication that an unacknowledged SDU has been received from 
+		the remote peer.
+Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
+		(struct mbuf *)
+Argument 2:	Not used.
+
+
+Stack Command:	SSCOP_RETRIEVE_IND
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+Stack Command:	SSCOP_RETRIEVECMP_IND
+Description:	Not supported.
+Argument 1:	N/A
+Argument 2:	N/A
+
+
+
+Protocol Specifications
+-----------------------
+For SSCOP_VERS_QSAAL, see Q.SAAL1.
+For SSCOP_VERS_Q2110, see Q.2110.
+
+
+
+Implementation Limitations
+--------------------------
+o The following signals are not supported:
+	AA-RETRIEVE
+	AA-RETRIEVE COMPLETE
+	AA-RELEASEBUF (Q.SAAL1 only)
+	MAA-UNITDATA
+
+o Does not support sending the SSCOP-UU/UUI parameter, must be set to NULL
+
+o For the AA-ESTABLISH request and response signals, only BR=YES is supported 
+
+o For the AA-DATA request signal, only PR=NO is supported (Q.SAAL1 only)
+
+
+	@(#) $Id: sscop.design,v 1.1.1.1 1996/12/04 20:48:17 mks Exp $
+