diff options
Diffstat (limited to 'share/examples/atm')
| -rw-r--r-- | share/examples/atm/NOTES | 54 | ||||
| -rw-r--r-- | share/examples/atm/README | 140 | ||||
| -rw-r--r-- | share/examples/atm/Startup | 127 | ||||
| -rwxr-xr-x | share/examples/atm/atm-config.sh | 88 | ||||
| -rw-r--r-- | share/examples/atm/atm-sockets.txt | 340 | ||||
| -rw-r--r-- | share/examples/atm/cpcs-design.txt | 84 | ||||
| -rw-r--r-- | share/examples/atm/fore-microcode.txt | 92 | ||||
| -rw-r--r-- | share/examples/atm/sscf-design.txt | 129 | ||||
| -rw-r--r-- | share/examples/atm/sscop-design.txt | 220 |
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 $ + |
