BSD 4.4 Lite Share Sources

84 files changed, 19717 insertions, 0 deletions

diff --git a/share/doc/iso/README b/share/doc/iso/README
new file mode 100644
index 0000000..7f3c679
--- /dev/null
+++ b/share/doc/iso/README
@@ -0,0 +1,3 @@
+The documentation contained here is horribly out of
+date and not to be trusted.  However, it's probably
+better than nothing at all.
diff --git a/share/doc/iso/ucb/addr.nr b/share/doc/iso/ucb/addr.nr
new file mode 100644
index 0000000..57eff30
--- /dev/null
+++ b/share/doc/iso/ucb/addr.nr
@@ -0,0 +1,155 @@
+.NC "NSAP Addresses & Routing"
+.sh 1 "OSI Address Formats"
+.pp
+ARGO supports an ISO address family, AF_ISO, in addition to the
+DoD Internet address family, AF_INET.
+Addresses in the family AF_ISO 
+take the form described by ISO 8348/DAD2, which is an addendum to the
+OSI network service standard that describes network layer addressing.
+.sh 2 "ISO 8348/DAD2 Tutorial"
+.pp
+.\" FIGURE
+.\".so figs/osi_addr.nr
+.so ../wisc/figs/addrfmt.nr
+.CF
+shows the
+format of an OSI NSAP-address.
+The address has two major parts: the initial domain part
+(IDP) and the domain specific part (DSP). The IDP is further divided into
+two parts: the authority and format identifier (AFI) and the
+initial domain identifier (IDI). The AFI specifies the format of the
+IDI, the authority responsible for allocating values of the IDI, and
+the syntax of the DSP. The IDI specifies the network addressing domain
+from which DSP values are allocated, and the authority responsible for
+allocating DSP values.
+.sh 2 "Supported Formats"
+.pp
+ARGO supports three types of ISO NSAP-addresses:
+one type with AFI 37(hex) and two types with AFI 47(hex).
+.sh 3 "AFI 37"
+.pp
+This value of the AFI defines the IDI to be an X.121 address or DTE
+address. 
+The DTE address is encoded in binary coded decimal.  
+The DSP syntax is binary.
+This form is intended to be used when communicating 
+across a public data network (PDN). 
+The ARGO software and documentation
+refer to this type of NSAP-address as a
+\*(lqtype 37.\*(rq
+address.
+.sh 3 "AFI 47"
+.pp
+The value of 47 for the AFI defines the IDI to be a 4 digit International
+Code Designator (ICD) allocated according to ISO 6523. 
+ARGO support two
+ICD values.
+.sh 4 "ICD 0004"
+.pp
+The ICD value of 0004 is assigned to OSINET,
+an experimental OSI network overseen by 
+National Institute of Science and Technology.\**
+.(f
+\** formerly the National Bureau of Standards
+.)f
+When this style of NSAP-address
+is used, 
+the DSP is divided into four parts: an organization identifier (2 bytes),
+a subnet identifier (2 bytes), 
+an SNPA-part (4-8 bytes), and
+an NSAP selector (1 byte). 
+The use of these fields is defined by the OSINET steering committee.
+This type of address is known as an
+\*(lqOSINET\*(rq
+address.
+.sh 4 "ICD 0006"
+.pp
+The ICD value of 0006 is assigned to the Department of Defense (DoD).
+In ARGO, NSAP-addresses with an ICD value of 0006 
+are of the format defined in RFC 986, a proposal for embedding DARPA Internet
+addresses within an OSI NSAP-address. 
+In this case, the DSP takes the form:
+version (1 byte), DARPA Internet Address (4 bytes), upper layer protocol
+identifier (1 byte).
+This is called an
+\*(lqrfc986\*(rq
+address.
+.sh 1 "Internal Representation"
+.pp
+Internally, an NSAP address takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s s.
+struct iso_addr {
+.T&
+l l l l l.
++u_char+isoa_afi;+/* authority &
++++format id */
++union+{+ 
+++struct addr_37+addr_37;+/* x.121 */
+++struct addr_osinet+addr_osinet;+/* OSINET */
+++struct addr_rfc986+addr_rfc986;+/* Internet*/
++}+isoa_u;
++u_char+isoa_len;+/* length */
+}
+.TE
+\fR
+.)b
+The field \fIisoa_afi\fR contains the AFI for the address. 
+The union
+\fIisoa_u\fR contains the remainder of the address. 
+The length of the entire address (the AFI, IDI, and DSP) is 
+stored in \fIisoa_len\fR.
+.sh 1 "Network Layer Routing"
+.pp
+Routing at the network layer is performed by the 
+routing procedure \fIrtalloc()\fR as described in Chapter 5. 
+\fIRtalloc()\fR was designed for used in the DoD Internet
+domain.
+An unfortunate
+effect of this is that routing decisions are based upon either the
+entire NSAP address or the network portion of the address. 
+The problem is defining the network portion of an NSAP address. 
+The location and extent of the 
+network portion of an NSAP address depends on the
+style of NSAP address. 
+This decision is made by the function \fIiso_netof()\fR.
+.sh 2 "Network Portion of Type 37 Addresses"
+.pp
+There is no network portion of an X.121 address. 
+In ARGO, the network portion of a type 37 address 
+is defined to be just the AFI. 
+The obvious consequence of this is that all type 37 addresses will 
+match all other type 37 addresses
+in a network-portion comparison.
+.sh 2 "Network Portion of OSINET Addresses"
+.pp
+The network portion of an OSINET address is the organization identifier and
+the subnet identifier.
+.sh 2 "Network Portion of RFC986 Addresses"
+.pp
+The network portion of an RFC986 address is the network portion of the
+embedded DARPA Internet address. 
+ARGO does not support subnetting, a method of subdividing Internet addresses.
+.sh 1 "NSAP Address / Subnetwork Point of Attachment Mapping"
+.pp
+In order to transmit a packet on a real subnetwork, the destination
+NSAP address
+must be mapped to an SNPA address. 
+An SNPA address is the real, "hardware" address
+of a system on a network. 
+This address corresponds to the 6 byte Ethernet or Token Ring
+Adapter address, 
+or to the DTE address, which may be up to 7 bytes
+long (14 decimal digits).
+.pp
+A table, \fIsnpa_cache\fR is kept in the kernel which contains the 
+translation between NSAP-addresses and SNPA-addresses. 
+This table is used by \fIiso_snparesolve()\fR whenever a 
+datagram must be dispatched.
+The table is maintained by the the ISO ES-IS protocol entity.
+Entries can be added and deleted
+by the user program \fIclnlutil(8)\fR and
+by the CONS entity.
diff --git a/share/doc/iso/ucb/def.nr b/share/doc/iso/ucb/def.nr
new file mode 100644
index 0000000..9d8e8b8
--- /dev/null
+++ b/share/doc/iso/ucb/def.nr
@@ -0,0 +1,144 @@
+.NC "Definitions"
+.sh 1 "General Terms"
+.ip "Kernel" 5
+The source code or binary module for the Acis Operating System 
+(also know as AOS and IBM/4.3).
+.ip "User process" 5
+An instance of a program that is 
+running in unprivileged mode, in the unprivileged address space 
+commonly know as "user address space", in other words, not
+part of the kernel.
+.ip "IPC" 5
+Interprocess communication, the mechanism by which two different
+user processes send messages to each other.
+.ip "Unix, AOS" 5
+ACIS Operating System, the special testing release of Berkeley Unix 4.4BSD.
+.ip "PCB, pcb" 5
+Protocol control block.  Each instance of a protocol machine
+keeps status information, addresses, and in some cases queues
+in a pcb for each connection or socket.
+.ip "Domain" 5
+In the Berkeley Unix environment, a domain is an abstract entity which
+comprises a network architecture, addressing scheme, address format, 
+network protocols, and transport protocols.
+.sh 1 "Transport Layer Terms"
+.ip "ISO 8073"
+ISO Draft International Standard 8073, Transport Protocol Specification
+.ip "TP" 5 
+The collection of transport
+classes that have been implemented in ARGO, classes 0 and 4.
+Also means the ARGO implementation of TP. 
+.ip "TP 0" 5 
+Transport class 0.
+.ip "TP 4" 5 
+Transport class 4.
+.ip "Transport entity" 5
+Software or hardware that implements the elements of procedure
+described in ISO 8073.
+.ip "Transport user" 5
+User process that make use of the services
+provided by a transport entity.
+.ip "Transport service interface" 5
+The syntax and semantics of the set of procedures, functions, and system calls
+that are invoked by a transport user, 
+through which the services of the transport entity are delivered.
+.ip "TPDU" 5
+Transport protocol data unit, a packet that is
+passed from one transport entity to another.
+.ip "TSDU" 5
+Transport service data unit, the logical unit of data that is
+passed from a transport entity to a transport user, or from
+a transport user to a transport entity.
+.ip "CR TPDU" 5
+Connection request TPDU. 
+.ip "CC TPDU" 5
+Connection confirm TPDU.
+.ip "DR TPDU" 5
+Disconnect request TPDU.
+.ip "DC TPDU" 5
+Disconnect confirm TPDU.
+.ip "DT TPDU" 5
+Normal data TPDU.
+.ip "XPD TPDU" 5
+Expedited data TPDU.
+.ip "AK TPDU" 5
+Normal data acknowledgment TPDU.
+.ip "XAK TPDU" 5
+Expedited data acknowledgment TPDU.
+.ip "ER TPDU" 5
+Error TPDU.
+.sh 1 "Network Layer Terms"
+.ip "ISO 8473"
+ISO Draft International Standard 8473, connectionless network protocol.
+.ip "CONS"
+Connection Oriented Network Service.
+.ip "COSNS"
+Connection Oriented Sub-Network Service.
+.ip "CLNS"
+Connectionless Network Service.
+.ip "CLNP"
+Connectionless Network Protocol, or ISO 8473.
+.ip "Network Entity"
+Software or hardware that implements the elements of procedure described
+in ISO 8473.
+.ip "Network Service User"
+Software components that make use of the services provided by a network
+entity.
+.ip "Network Service Provider"
+Software components that provide the services of a network entity.
+.ip "NSAP"
+Network Service Access Point. The point at which the OSI network service
+is made available to the network service user by the network service
+provider.
+.ip "NSAP address"
+Information that the network service provider needs to identify an
+NSAP. The source and destination address fields of a CLNP packet
+are NSAP addresses.
+.ip "ES"
+End system. A system running the complete suite of OSI protocols which can
+act as an end point for communication.
+.ip "IS"
+Intermediate system. A system running the OSI layers 1, 2, and 3 which
+can act only a packet router.
+.ip "SNPA"
+The Subnetwork Point of Attachement is the point where a \fIreal\fR 
+end or intermediate system is attached to a \fIreal\fR subnetwork.
+.ip "SNPA address"
+Information that a \fIreal\fR subnetwork need to identify a \fIreal\fR end 
+or intermediate system. This is commonly referred to as the hardware address.
+.ip "NPDU"
+Network Protocol Data Unit. The unit of data which is exchanged between
+network entities.
+.ip "DT NPDU"
+Normal data NPDU.
+.ip "ER NPDU"
+Error report NPDU.
+.ip "Initial NPDU"
+A NPDU carrying the whole of the user data from an N-UNITDATA request.
+.ip "Derived NPDU"
+a NPDU whose field ar identical to those of an initial NPDU, except that it
+carries only a segment of the user data from an N-UNITDATA request.
+.ip "Segment"
+A distinct unit of data consisting of part or all of the user data provided
+in the N-UNITDATA request and delivered in the N-UNITDATA indication.
+.ip "Segmentation"
+The act of generation two or more derived NPDUs from an initial or derived
+NPDU.
+.ip "Fragment"
+A DoD Internet Protocol term with the same meaning as "segment". Used
+synonymously with "segment."
+.ip "Fragmentation"
+A DoD Internet Protocol term with the same meaning as "segmentation". Used
+synonymously with "segmentation."
+.ip "Reassembly"
+The act of regenerating an initial NPDU from two ore more derived NPDUs.
+.ip "MTU"
+Maximum transmission unit.  The maximum size of a packet that can be
+transmitted on a medium or through a protocol.
+For example, the MTU of the TP protocol is 8192 bytes, the MTU
+of and Ethernet device is 1500 bytes, and the MTU of the OSI Network
+service is 512 bytes.
+.ip "Network interface"
+The device used to attach a computer to a network, for example,
+an Ethernet adapter, or a Token Ring adapter.
+This terminology is inherited from BSD Unix.
diff --git a/share/doc/iso/ucb/intro.nr b/share/doc/iso/ucb/intro.nr
new file mode 100644
index 0000000..196b7ae
--- /dev/null
+++ b/share/doc/iso/ucb/intro.nr
@@ -0,0 +1,72 @@
+.NC "Introduction"
+.sh 1 "Introduction"
+.pp
+This document describes the usage of the ISO
+transport and network layers written for the ACIS Operating System,
+the IBM ACIS port of Berkeley 4.3 Unix\**
+.(f
+\** Unix is a registered trademark of AT&T.
+.)f
+for the IBM RT PC,
+hereafter called AOS, as modified by UC Berkeley.
+This document describes work in progress and is an extremely
+hasty job of editing an earlier document written by colleagues
+at the university of Wisconsin.
+It is to be regarded as an emergency manual prepared for testers
+at NIST and should not be redistributed further.
+As such, there are philosophical
+statements that Berkeley fundamentally disagrees with, which
+we do not presently have the time to rip out.
+Collectively, this work is called the Wisconsin ARGO kernel. 
+The ARGO kernel supports the 
+the connection-oriented ISO transport service (COTS), the
+ISO connectionless network service (CLNS)
+and a
+connection-oriented network service (CONS).
+The COTS is provided by the ISO transport protocol TP,
+ISO 8073 Revised.
+The CLNS is provided by the connectionless network protocol,
+ISO 8473.
+The CONS is provided by the X.25 protocols.
+The ARGO implementation of the CONS is not a complete
+ISO CONS, but contains enough of the CONS to support
+the COTS and the CLNS (in the latter case, the CONS can be
+viewed as a subnetwork service).
+.pp
+The purposes of this document are
+.ip "1) "
+to describe the transport service and the software interface
+between the user and provider of this service,
+.ip "2) "
+to describe the network service and the software interface it
+provides.
+.pp
+It is assumed that the reader is familiar with the \fBC\fR
+programming language,
+with Unix conventions, and with the ISO specifications listed in Appendix A.
+.sh 1 "Organization"
+.pp
+This document is composed of several chapters.
+Chapter One contains this introduction. Chapter Two presents a
+definition of terms and phrases used throughout the document.
+Chapter Three describes the transport service interface, which is
+the interface between the transport protocol implementation software and the transport user software.
+Chapter Four describes the network service interface, and the interface
+above and below the network layer.
+Chapter Five explains the format of an OSI address.
+Chapter Six describes the
+the architecture of the interprocess communication support in the 
+kernel, which to a large degree mandates
+the design of a protocol implementation for a 4.3 Unix kernel.
+.\" Appendix A is a list of the applicable ISO standards.
+.\" The manual pages relevant to the transport and network layers
+.\" are included as Appendix B.
+.pp
+Several conventions are followed in this document.
+All procedure names and system call names are followed
+by a pair of parentheses, for example,
+.i read ().
+References to manual pages consist of the name of the
+manual page, followed by the section in which
+the man page is found:
+.i read (2).
diff --git a/share/doc/iso/ucb/ipc.nr b/share/doc/iso/ucb/ipc.nr
new file mode 100644
index 0000000..6944970
--- /dev/null
+++ b/share/doc/iso/ucb/ipc.nr
@@ -0,0 +1,331 @@
+.NC "The Design of Unix IPC"
+.sh 1 "General"
+.pp
+The ARGO implementation of 
+TP and CLNP was designed to fit into the AOS
+kernel
+as easily as possible.
+All the standard protocol hooks are used.
+To understand the design, it is useful to have
+read 
+Leffler, Joy, and Fabry:
+\*(lq4.2 BSD Networking Implementation Notes\*(rq July 1983.
+This section describes the
+design of the IPC support in the AOS kernel.
+.sh 1 "Functional Unit Overview"
+.pp
+The 
+AOS
+kernel
+is a monolithic program of considerable size and complexity.
+The code can be separated into parts of distinct function,
+but there are no kernel processes per se.
+The kernel code is either executed on behalf of a user
+process, in which case the kernel was entered by a system call, 
+or it is executed on behalf of a hardware or software interrupt.
+The following sections describe briefly the major functional units 
+of the kernel.
+.\" FIGURE
+.so ../wisc/figs/func_units.nr
+.CF
+shows the arrangement of these kernel units and 
+their interactions.
+.sh 2 "The file system."
+.pp
+.sh 2 "Virtual memory support."
+.pp
+This includes protection, swapping, paging, and
+text sharing.
+.sh 2  "Blocked device drivers (disks, tapes)."
+.pp
+All these drivers share some minor functional units,
+such as buffer management and bus support
+for the various types of busses on the machine.
+.sh 2 "Interprocess communication (IPC)."
+.pp
+This includes 
+support for various protocols, 
+buffer management, and a standard interface for inter-protocol
+communication.
+.sh 2 "Network interface drivers." 
+.pp
+These drivers are closely tied to the IPC support. 
+They use the IPC's buffer management unit rather
+than the buffers used by the blocked device drivers.
+The interface between these drivers and the rest of the kernel 
+differs from the interface used by the blocked devices.
+.sh 2 "Tty driver" 
+.pp
+This is terminal support, including the user interface
+and the device drivers.
+.sh 2 "System call interface." 
+.pp
+This handles signals, traps, and system calls.
+.sh 2 "Clock." 
+.pp
+The clock is used in various forms by many
+other units.
+.sh 2 "User process support (the rest)." 
+.pp
+This includes support for accounting, process creation, 
+control, scheduling, and destruction.
+.pp
+.sh 2 "IPC"
+.pp
+The major functional unit that supports IPC
+can be divided into the following smaller functional
+units.
+.sh 3 "Buffer management." 
+.pp
+All protocols share a pool of buffers called \fImbufs\fR.
+The internal structure has changed considerably since 4.3:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct mbuf {
+.T&
+l l l l.
++struct mbuf+*m_next;+/* next buffer in chain */
++struct mbuf+*m_act;+/* link in 2-d structure */
++u_long+m_len;+/* amount of data */
++char *+m_data;+/* location of data */
++short+m_type;+/* type of data */
++short+m_flags;+/* note if EOR, Packet HDR, Ext. stored */
++++/* If packet header add: */
+int+m_pkthdr.len;+/* total packet length */
+struct ifnet+*m_pkthdr.recvif;+/* rcv interface*/
++++/* If external storage add: */
++char +*m_ext.ext_buf;+/* start of buffer */
++void+(*m_ext.ext_free)();+/* free routine if not the usual */
++u_int+m_ext.ext_size;+/* size of buffer, for ext_free */
++++/* For non external */
++char+m_dat[depending];+/* done by unions, etc. */
+};
+.TE
+\fR
+.)b
+.pp
+There are two forms of mbufs - with and without external storage.
+Small ones are 128 octets in 4.4BSD.
+The data in these mbufs are located
+in the mbuf structure itself.
+Large mbufs, called \fIclusters\fR, are page-sized
+and page-aligned.
+They may be \*(lqcopied\*(rq by multiply mapping the pages they occupy.
+They consist of a page of memory plus a small mbuf structure 
+whose fields are used
+to link clusters into chains, but whose \fIm_dat\fR array is 
+not used.
+The \fIm_data\fR field of the structure 
+is a pointer to the active data in all cases.
+The remainder of the description in the argo document
+is generally obsolete, and I am merely deleting the
+rest of it at this point.
+.sh 3 "Routing." 
+.pp
+Routing decisions in the kernel are made by the procedure \fIrtalloc()\fR.
+This procedure will scan the kernel routing tables (stored in mbufs)
+looking for a route.
+The argo document here also is quite obsolete.
+We know keep a tree structure routing table,
+and do matching under masks.
+The structure for the routing entry contains tree related
+stuff pointers (parent, l-r child for internal nodes, mask and address
+for external nodes), and may be completely revised again
+to make use of patricia trees.
+.pp
+If a route is not found, then a default route is used (if present). 
+.pp
+If a route is found, the entity which called \fIrtalloc()\fR can use information
+from the \fIrtentry\fR structure to dispatch the datagram. Specifically, the
+datagram is queued on the interface identified by the interface 
+pointer \fIrt_ifp\fR.
+.sh 3 "Socket code." 
+.pp
+This is the protocol-independent part of the IPC support.
+Each communication endpoint (which may or may not be associated
+with a connection) is represented by the following structure:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct socket {
+.T&
+l l l l.
++short+so_type;+/* type, e.g. SOCK_DGRAM  */
++short+so_options;+/* from socket call */
++short+so_linger;+/* time to linger @ close */
++short+so_state;+/* internal state flags */
++caddr_t+so_pcb;+/* network layer pcb */
++struct protosw+*so_proto;+/* protocol handle */
++struct socket+*so_head;+/* ptr to accept socket */
++struct socket+*so_q0;+/* queue of partial connX */
++short+so_q0len;+/* # partials on so_q0 */
++struct socket+*so_q;+/* queue of incoming connX */
++short+so_qlen;+/* # connections on so_q */
++short+so_qlimit;+/* max # queued connX */
++struct sockbuf+{
+++short+sb_cc;+/* actual chars in buffer */
+++short+sb_hiwat;+/* max actual char count */
+++short+sb_mbcnt;+/* chars of mbufs used */
+++short+sb_mbmax;+/* max chars of mbufs to use */
+++short+sb_lowat;+/* low water mark (not used yet) */
+++short+sb_timeo;+/* timeout (not used ) */
+++struct mbuf+*sb_mb;+/* the mbuf chain */
+++struct proc+*sb_sel;+/* process selecting */
+++short+sb_flags;+/* flags, see below */
++} so_rcv, so_snd;
++short+so_timeo;+/* connection timeout */
++u_short+so_error;+/* error affecting connX */
++short+so_oobmark;+/* oob mark (TCP only) */
++short+so_pgrp;+/* pgrp for signals */
+}
+.TE
+\fR
+.)b
+.pp
+The socket code maintains a pair of queues for each socket,
+\fIso_rcv\fR and \fIso_snd\fR.
+Each queue is associated with a count of the number of characters
+in the queue, the maximum number of characters allowed to be put
+in the queue, some status information (\fIsb_flags\fR), and
+several unused fields.
+For a send operation, data are copied from the user's address space
+into chains of mbufs.
+This is done by the socket module, which then calls the underlying
+transport protocol module to place the data
+on the send queue. 
+This is generally done by 
+appending to the chain beginning at \fIsb_mb\fR.
+The socket module copies data from the \fIso_rcv\fR queue
+to the user's address space to effect a receive operation.
+The underlying transport layer is expected to have put incoming
+data into \fIso_rcv\fR by calling procedures in this module.
+.in -5
+.sh 3 "Transport protocol management."
+.pp
+All protocols and address types must be \*(lqregistered\*(rq in a
+common way in order to use the IPC user interface.
+Each protocol must have an entry in a protocol switch table.
+Each entry takes the form:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct protosw {
+.T&
+l l l l.
++short+pr_type;+/* socket type used for */
++short+pr_family;+/* protocol family */
++short+pr_protocol;+/* protocol # from the database */
++short+pr_flags;+/* status information */
++++/* protocol-protocol hooks */
++int+(*pr_input)();+/* input (from below) */
++int+(*pr_output)();+/* output (from above) */
++int+(*pr_ctlinput)();+/* control input */
++int+(*pr_ctloutput)();+/* control output */
++++/* user-protocol hook */
++int+(*pr_usrreq)();+/* user request: see list below */
++++/* utility hooks */
++int+(*pr_init)();+/* initialization hook */
++int+(*pr_fasttimo)();+/* fast timeout (200ms) */
++int+(*pr_slowtimo)();+/* slow timeout (500ms) */
++int+(*pr_drain)();+/* free some space (not used) */
+}
+.TE
+\fR
+.)b
+.pp
+Associated with each protocol are the types of socket
+abstractions supported by the protocol (\fIpr_type\fR), the
+format of the addresses used by the protocol (\fIpr_family\fR),
+the routines to be called to perform
+a standard set of protocol functions (\fIpr_input\fR,...,\fIpr_drain\fR),
+and some status information (\fIpr_flags\fR).
+The field pr_flags keeps such information as
+SS_ISCONNECTED (this socket has a peer),
+SS_ISCONNECTING	(this socket is in the process of establishing
+a connection),
+SS_ISDISCONNECTING (this socket is in the process of being disconnected),
+SS_CANTSENDMORE (this socket is half-closed and cannot send),
+SS_CANTRCVMORE (this socket is half-closed and cannot receive).
+There are some flags that are specific to the TCP concept
+of out-of-band data.
+A flag SS_OOBAVAIL was added for the ARGO implementation, to support
+the TP concept of out-of-band data (expedited data).
+.sh 3 "Network Interface Drivers" 
+.pp
+The drivers for the devices attaching a Unix machine to a network
+medium share a common interface to the protocol
+software.
+There is a common data structure for managing queues,
+not surprisingly, a chain of mbufs.
+There is a set of macros that are used to enqueue and
+dequeue mbuf chains at high priority.
+A driver 
+delivers an indication to a protocol entity when
+an incoming packet has been placed on a queue by 
+issuing a
+software
+interrupt.
+.sh 3 "Support for individual protocols." 
+.pp
+Each protocol is written as a separate functional unit.
+Because all protocols share the clock and the mbuf pool, they
+are not entirely insulated from each other.
+The details of TP are described in a section that
+follows.
+.\"*****************************************************
+.\" FIGURE
+.so ../wisc/figs/unix_ipc.nr
+.pp
+.CF
+shows the arrangement of the IPC  support.
+.pp
+The AOS
+IPC was designed for DoD Internet protocols, all of
+which run over DoD IP.
+The assumptions that DoD Internet is the domain
+and that DoD IP is the network layer 
+appear in the code and data structures in numerous places.
+An example is that the transport protocols all directly call
+IP routines.
+There are no hooks in the data structures through
+which the transport layer can choose a network level protocol.
+Another example is that headers are assumed to
+fit in one small mbuf (112 bytes for data in AOS).
+Another example is this:
+It is assumed in many places that buffer space is managed
+in units of characters or octets.
+The user data are copied from user address space into the kernel mbufs
+amorphously
+by the socket code, a protocol-independent part of the kernel.
+This is fine for a stream protocol, but it means that a
+packet protocol, in order to \*(lqpacketize\*(rq the data,
+must perform a memory-to-memory copy
+that might have been avoided had the protocol layer done the original
+copy from user address space.
+Furthermore, protocols that count credit in terms of packets or
+buffers rather than characters do not work efficiently because
+the computation of buffer space is not in the protocol module,
+but rather it is in the socket code module.
+This list of examples is not complete.
+.pp
+To summarize, adding a new transport protocol to the kernel consists of
+adding entries to the tables in the protocol management
+unit, 
+modifying the network interface driver(s) to recognize
+new network protocol identifiers, 
+adding the
+new system calls to the kernel and to the user library,
+and
+adding code modules for each of the protocols,
+and correcting deficiencies in the socket code,
+where the assumptions made about the nature of 
+transport protocols do not apply. 
+.i
+(Touchy touchy, aren't we!?! -- Sklower)
diff --git a/share/doc/iso/ucb/macros.nr b/share/doc/iso/ucb/macros.nr
new file mode 100644
index 0000000..88ec2d3
--- /dev/null
+++ b/share/doc/iso/ucb/macros.nr
@@ -0,0 +1,50 @@
+.\"	
+.\" Macro to initialize chapter macros
+.\"	
+.de IC
+.nr CN 0 1
+..
+.\"	
+.\" Macro to begin new chapter
+.\"	
+.de NC
+.he 'ARGO user\'s Guide, Berkeley Hack Job''Chapter \\n+(CN'
+.bp
+.sh 0 "_" 1 1 1 1 1 1
+.sz +2
+.(l C
+CHAPTER \\n(CN
+
+\fB\\$1\fR
+.)l
+.sp 1
+.(x
+Chapter \\n(CN     \\$1
+.)x
+.sz -2
+..
+.\"	
+.\"	Figure conventions:
+.\"	1) do .so of figure source - figure reg incremented here
+.\"	2) make references to figure via CF
+.\"	
+.\"	
+.\"	Macro to initialize figure register
+.\"	
+.de IF
+.nr FG 0 1
+..
+.\"	
+.\"	Macro for current figure number
+.\"	
+.de CF
+Figure \\n(FG
+..
+.\"
+.\"	Define this macro to include section headings in table of contents
+.\"
+.de $0
+.(x
+Section \\$2 \\$1
+.)x
+..
diff --git a/share/doc/iso/ucb/net_serv.nr b/share/doc/iso/ucb/net_serv.nr
new file mode 100644
index 0000000..c24eebd
--- /dev/null
+++ b/share/doc/iso/ucb/net_serv.nr
@@ -0,0 +1,163 @@
+.NC "Network Service Interface"
+.sh 1 "Connectionless Network Service"
+.pp
+This section describes the interface to the ISO connectionless network service.
+There are really two interfaces to the CLNS: the internal interface
+and the IPC interface.
+The internal interface is based on
+procedure calls. It is used only within the kernel. The IPC interface
+allows a user process to access the CLNS directly. This is used only
+for testing and debugging purposes.
+.sh 2 "Primitives"
+.pp
+The CLNS is, by definition, connectionless. Therefore, there are no 
+primitives associated with connection establishment or connection release.
+There is one primitive associated with data transfer: N-UNITDATA.
+The parameters to a N-UNITDATA request are: source NSAP address,
+destination NSAP address, quality of service, and user data. 
+The parameters of a N-UNITDATA indication are identical to those of the
+request.
+In this implementation, the quality of service parameter is not supported.
+.sh 2 "Internal Interface"
+.pp
+Within the kernel, an N-UNITDATA request is effected by the procedure
+\fIclnp_output()\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+clnp_output(m0, isop, datalen, flags)
+.T&
+l l l.
+ +struct mbuf+*m0;+/* data */
+ +struct isopcb+*isop;+/* ISO protocol control block */
+ +int+datalen;+
+ +int+flags;+/* flags */
+.TE
+\fR
+.)b
+This procedure will construct a DT NPDU, route it, and transmit it on
+the appropriate subnetwork. \fIM0\fR is an mbuf chain containing the 
+user data portion of the N-UNITDATA request. \fIIsopcb\fR is the iso protocol
+control block previously allocated. \fIClnp_output\fR will use the following
+fields: \fIisop_laddr\fR, isop_faddr, isop_route, isop_options,
+isop_optindex, \fI and \fRisop_clnpcache\fR.
+\fIDatalen\fR specifies the number of bytes of user data.
+The \fIflags\fR parameter will be discussed in a subsequent chapter.
+.pp
+A N-UNITDATA indication occurs when a DT NPDU arrives. The indication is
+generated by calling the appropriate upper layer protocol input routine. 
+In the case of TP, the procedure \fItpclnp_input()\fR is called:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+tpclnp_input(m, src, dst, len)
+.T&
+l l l.
+ +struct mbuf+*m;+/* DT NPDU */
+ +struct iso_addr+*src;+/* source of packet */
+ +struct iso_addr+*dst;+/* destination of packet */
+ +int+len;+/* length of clnp header */
+.TE
+\fR
+.)b
+\fIM\fR contains the entire DT NPDU packet. \fILen\fR indicates the size
+of the CLNP header. In other words, the user data of the DT NPDU begins
+\fIlen\fR bytes into \fIm\fR. \fISrc\fR and \fIdst\fR indicate the
+source and destination NSAP addresses of the packet.
+.sh 3 "CLNP/Subnetwork Interface"
+.pp
+The design of the interface between the subnetwork and the CLNP is 
+determined by the design of the Unix network interface drivers. CLNP
+follows the conventional mechanisms for exchanging packets with a network
+interface. See the section on Network Interface Drivers in Chapter Five
+for more information on these conventions.
+.sh 2 "IPC (\*(lqRaw\*(rq) Interface"
+.pp
+The IPC interface to the CLNS allows direct (called \*(lqraw\*(rq) 
+access to CLNP. 
+This interface is intended for testing and debugging only. 
+Its use results in the
+transmission of CLNP datagrams with nonstandard identification fields.
+These raw packets may be rejected by a system not employing the same
+convention. See the section on network implementation for more information
+about the conventions.
+.pp
+In order to gain access to the raw interface
+a \fIsocket\fR, with address family AF_ISO and type SOCK_RAW must be created.
+With this socket in hand,
+the system calls \fIsendto()\fR and \fIrecvfrom()\fR can be used to 
+transmit and receive raw CLNP datagrams. 
+.sh 3 "Sending raw datagrams"
+.pp
+The format of the \fIsendto()\fR system call is:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+cc = sendto(s, msg, len, flags, to, tolen)
+.T&
+l l l.
+int+cc,s;
+char+*msg;
+int+len,flags;
+struct sockaddr+*to;
+int+to;
+.TE
+\fR
+.)b
+\f\fIS\fR is the socket previously created. \fIMsg\fR is a pointer to
+the data for the NPDU. CLNP will prepend a header to this data before
+transmission. \fILen\fR specifies the number of bytes of data. The
+\fIflags\fR parameter is unused and should be zero. \fITo\fR specifies the
+NSAP address to be used as the destination address. The size (in bytes)
+of \fIto\fR is given in \fItolen\fR. CLNP will automatically insert
+the source address based upon the route taken by the packet. The number of
+user data bytes transmitted is returned as \fIcc\fR. See \fIsendto(2)\fR
+for more information on this system call.
+.sh 3 "Receiving raw datagrams"
+.pp
+The format of the \fIrecvfrom()\fR system call is:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+cc = recvfrom(s, buf, len, flags, from, fromlen)
+.T&
+l l l.
+int+cc,s;
+char+*buf;
+int+len,flags;
+struct sockaddr+*from;
+int+*fromlen;
+.TE
+\fR
+.)b
+When used with a CLNP raw socket \fIs\fR, \fIrecvfrom()\fR will read a 
+NPDU from the CLNS. If no packet is available, the call will block.
+\fIBuf\fR specifies a buffer of \fIlen\fR bytes into which the NPDU will
+be read. The entire packet, including the header, will be read into the
+buffer. The \fIflags\fR parameter is unused, and should be zero. If 
+\fIfrom\fR is non-zero, the source address of the NPDU is filled in.
+\fIFromlen\fR is a value-result parameter, initialized to the size of
+the buffer associated with \fIfrom\fR, and modified on return to
+indicate the actual size of the address stored there. The total number
+of bytes received (header and data) is returned as \fIcc\fR.
+See \fIrecvfrom(2)\fR for more information about this system call.
+.sh 1 "Connection Oriented Network Service"
+.pp
+The ARGO Connection Oriented Network Service (CONS) is not a complete
+implementation of the
+OSI network service.
+It is that subset of the OSI network service that is used
+by ARGO Transport and by ARGO CLNP.
+.\" FIGURE
+.so ../wisc/figs/NS_primitives.nr
+.pp
+.CF
+shows which CONS service elements are provided.
diff --git a/share/doc/iso/ucb/program.nr b/share/doc/iso/ucb/program.nr
new file mode 100644
index 0000000..a431661
--- /dev/null
+++ b/share/doc/iso/ucb/program.nr
@@ -0,0 +1,42 @@
+.\"$Header: program.nr,v 1.1 88/12/05 18:10:57 nhall Exp $
+.\"$Source: /usr/argo/doc/kernel/RCS/program.nr,v $
+.\"
+.\"
+.\" FONT CONVENTIONS
+.\"
+.\" \fIprocedure()\fR
+.\" \fIsyscall()\fR
+.\" \fImanpage(3)\fR
+.\" \fIdata_structure_name\fR
+.\" \fC/file/or/directory/name\fR
+.\" \fC
+.\"    section of code
+.\" \fR
+.\"
+.\"
+.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
+.\" to be sure you've updated everything before distributing this!
+.\"
+.\"This file uses -me and tbl macros.
+.so macros.nr
+.\" .pn 1
+.IC
+.IF
+.\" .(l C
+.\" .sz 16
+.\" Berkeley's Hack at the first 6 chapters of
+.\" Wisconsin ARGO 1.0 Kernel Programmer's Guide for
+.\" Academic Operating Systems 4.3
+.\" .sz 8
+.\" .)l
+.he 'ARGO 1.0 Berkeley Revision User\'s Guide'''
+.fo '%''December 9, 1988'
+.\" .bp
+.so intro.nr
+.so def.nr
+.so trans_serv.nr
+.so net_serv.nr
+.so ipc.nr
+.so addr.nr
+.bp
+.xp
diff --git a/share/doc/iso/ucb/trans_serv.nr b/share/doc/iso/ucb/trans_serv.nr
new file mode 100644
index 0000000..2f6d156
--- /dev/null
+++ b/share/doc/iso/ucb/trans_serv.nr
@@ -0,0 +1,697 @@
+.NC "Transport Service Interface"
+.sh 1 "General"
+.pp
+It is assumed that the reader is acquainted with the
+set of system calls and library routines that
+compose the
+Berkeley
+Unix interprocess communication service (IPC).
+To every extent possible 
+the ARGO transport service is provided by the same IPC mechanisms
+that support
+the transport-level services 
+included in the
+AOS distribution.
+In some instances, the interface
+provided by AOS does not support
+the services required by ISO 8073,
+so system calls were added to support these services.
+It is felt that this is superior to modifying
+existing system calls, in order to avoid the
+recoding of existing Unix utilities. 
+.pp
+What follows is a description of the system calls
+that are used to provide the transport service.
+According to Unix custom,
+the return value of a system call is 0
+if the call succeeds and -1 if
+the call fails for any reason.
+In the latter case,
+the global variable
+\fIerrno\fR contains more information
+about the error that caused the failure.
+In the descriptions of all the system calls for which
+this custom is followed,
+the return value is named
+\fIstatus\fR.
+.sh 1 "Connection establishment"
+.pp
+Establishing a TP connection is similar to
+establishing a connection using any other
+transport protocol supported by Unix.
+The same system calls are used, and the passive open
+is required.  
+Some of the parameters to the system calls differ. 
+.pp
+The following call creates a communication endpoint called a
+\fIsocket\fR.
+It returns
+a positive integer called a
+\fIsocket descriptor\fR, 
+which
+will be a parameter in all communication primitives.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+s = socket( af, type, protocol )
+.T&
+l l l.
+ +int+s,af,type,protocol;
+.TE
+\fR
+.)b
+.pp
+The \fIaf\fR parameter describes the format of addresses
+used in this communication.
+Existing formats include AF_INET (DoD Internet addresses), 
+AF_PUP (Xerox PUP-I Internet addresses), and AF_UNIX
+(addresses are Unix file names, for intra-machine IPC only).
+TP runs in either the Internet domain or the ISO domain (AF_ISO).
+When using the Internet domain, the network layer is the DoD Internet IP 
+with Internet-style addresses. The ISO domain uses the ISO
+network service and ISO-style addresses\**.
+.(f
+\**ISO/DP 8348/DAD2 Addendum to the Network
+Service Definition Covering Network Layer Addressing.
+.)f
+Regardless of the address family used, an address takes the
+general form,
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr {
+.T&
+l l l l.
+ +u_char+sa_len;+/* length of sockaddr */
+ +u_char+sa_family;+/* address family */
+ +char+sa_data[14];+/* space for an address */
+}+
+.TE
+\fR
+.)b
+.lp
+.i
+A sockaddr is no longer required to be precisely 16 bytes long.
+The allocation of 14 bytes for sa_data is intended for backwards
+compatibility.
+.r
+.sp 1
+When viewed as an Internet address, it takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr_in {
+.T&
+l l l l.
+ +u_char+sin_len;+/* address length */
+ +u_char+sin_family;+/* address family */
+ +u_short+sin_port;+/* internet port */
+ +struct in_addr+sin_addr;+/* network addr A.B.C.D */
+ +char+sin_zero[8];+/* unused */
+}
+.TE
+\fR
+.)b
+.sp 1
+When viewed as an ISO address, as supplied by the
+university of wisconsin, it takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr_iso {
+.T&
+l l l l.
+ +u_char+siso_len;+/* address length */
+ +u_char+siso_family;+/* address family */
+ +u_short+siso_tsuffix;+/* transport suffix */
+ +struct iso_addr+siso_addr;+/* ISO NSAP addr */
+ +char+siso_zero[2];+/* unused */
+}
+.TE
+\fR
+.)b
+The address described by a \fIsockaddr_iso\fR structure
+is a TSAP-address (transport service access point address).
+It is made of an NSAP-address (network service access point address)
+and a TSAP selector (also called a transport suffix or
+transport selector, hereafter called a TSEL).
+The structure \fIsockaddr_iso\fR contains a 2-byte TSEL.
+This is for compatibility with Internet addressing.
+ARGO supports
+TSELs of length 1-64 bytes.
+TSELs of any length other than 2
+are called \*(lqextended TSELs\*(rq.
+They are described in detail in the section \fB\*(lqExtended TSELs\*(rq\fR.
+If extended TSELs are not requested, 2-byte TSELs are used by default.
+.pp
+Refer to Chapter Five for more information about ISO NSAP-addresses.
+.pp
+.i
+It is our intent at Berkeley to revamp the sockaddr_iso
+to use a more natural and uniform model, for ISO addresses.
+We cannot guarantee this modification to be complete by the
+time we are ready to have something for NIST to test.
+We hope to remove this notion of extended TSEL's as soon as
+possible, certainly by formal beta testing of 4.4.
+.r
+Since sockaddr can be 108 bytes long without breaking anything
+in the current Berkeley kernel, we should be able to eliminate
+extended TSEL's entirely by
+providing a sockaddr_iso along the lines of:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr_iso {
+.T&
+l l l l.
+ +u_char+siso_len;+/* address length */
+ +u_char+siso_family;+/* address family */
+ +u_char+siso_slen;+/* session suffix length */
+ +u_char+siso_tlen;+/* transport suffix length */
+ +u_char+siso_nlen;+/* nsap length */
+ +char+siso_data[22];+/* minimum nsap + tsel */
+}
+.TE
+\fR
+.)b
+.pp
+The \fItype\fR parameter in the \fIsocket()\fR call
+distinguishes 
+datagram protocols, stream protocols, sequenced
+packet protocols, reliable datagram protocols, and
+"raw" protocols (in other words, the absence of a transport protocol).
+Unix provides manifest named constants for each of these types.
+TP supports the sequenced packet protocol abstraction, to which
+the manifest constant SOCK_SEQPACKET applies.
+.pp
+The \fIprotocol\fR
+parameter is an integer that identifies the protocol to be used.
+Unix provides a database of protocol names  and their associated
+protocol numbers.
+Unix also provides user-level tools
+for searching the database.
+The tools take the form of library routines.
+A protocol number for TP has been chosen
+by the Internet NIC to allow TP to run in the Internet domain, and this
+has been added to the Unix network protocol database.
+The standard Internet database tools that serve TCP users
+can
+also serve user of TP
+in the Internet domain, if the TP protocol number is added to the
+proper Internet database file, 
+\fC/etc/protocols\fR.
+This change must be made for TP to run in either the Internet or
+in the ISO domain.
+The ARGO package contains a set of tools and a database
+for use with TP in the ISO domain.
+This set of tools is described in the manual pages
+\fIisodir(5)\fR and
+\fIisodir(3)\fR.
+.pp
+When a socket is created, it is not given an address.
+Since a socket cannot be reached by a remote entity unless it has an address, 
+the user must request that a socket be given an address by
+using the \fIbind()\fR system call:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = bind( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The address is expected to be in the format specified by the
+\fIaf\fR parameter to the \fIsocket()\fR
+call that yielded the socket descriptor \fIs\fR.
+If the user 
+passes an address parameter with a zero-valued transport suffix,
+the transport layer 
+assigns an unused 2-byte transport selector.
+This is a 4.3 Unix convention; it is not part of any ISO standard.
+.pp
+The \fIconnect()\fR system call effects an active open.
+It is used to establish a connection with an entity that is
+passively waiting for connection requests, and whose
+transport address is known.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = connect( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The first parameter is a socket descriptor.
+The \fIaddr\fR parameter is a transport address in the format
+specified by the \fIaf\fR parameter to the \fIsocket()\fR
+call that yielded the socket descriptor \fIs\fR.
+.pp
+A passive open is accomplished with two system calls,
+\fIlisten()\fR followed by \fIaccept()\fR.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = listen( s, queuelen )
+.T&
+l l l.
+ +int+s;
+ +int+queuelen;
+.TE
+\fR
+.)b
+.pp
+The \fIqueuelen\fR argument specifies the maximum
+number of pending connection
+requests that will be queued for acceptance by this user.
+Connections are then accepted by the
+system call \fIaccept()\fR.  
+There is no way to refuse connections.
+The functional equivalent of connection
+refusal is accomplished by accepting a connection and immediately
+disconnecting.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+new_s = accept( s, addr, addrlen )
+.T&
+l l l.
+ +int+new_s, s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The \fIaccept()\fR call completes the connection
+establishment. If a connection request from a prospective peer
+is pending on the socket described by \fIs\fR, it is removed and
+a new socket is created for use with this connection.
+A socket descriptor for the new socket is returned by the
+system call.
+If no connection requests are pending, this call blocks.
+If the \fIaccept()\fR call fails, -1 is returned.
+The transport address of the entity requesting the connection
+is returned in the \fIaddr\fR parameter, and the length
+of the address is returned in the \fIaddrlen\fR parameter.
+The address associated with the new socket is inherited
+from the socket on which the \fIlisten()\fR and \fIaccept()\fR were performed.
+.pp
+It is possible for the \fIaccept()\fR call to be interrupted
+by an asynchronous event such as the arrival of expedited
+data.
+When system calls are interrupted, Unix returns the value -1
+to the caller and puts the constant
+EINTR in the global variable \fIerrno\fR.
+This can create problems with the system call \fIaccept()\fR.
+In the case of incoming expedited data, the interruption does
+not indicate a problem, but the data may have arrived before
+the caller has received the new socket descriptor, which is the
+socket descriptor on which the expedited data are to be received.
+In order to prevent this problem from occurring, the caller must
+prevent the issuance of asynchronous indications until the
+\fIaccept()\fR
+call has returned.
+Asynchronous indications are discussed below, in 
+the section titled
+"Indications from the transport layer to the transport user".
+.pp
+It is possible to discover the 
+address bound to a 
+socket with the 
+\fIgetsockname()\fR system call.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getsockname( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+If the socket has a peer, that is, it is connected,
+the system call
+\fIgetpeername()\fR
+is used to discover the peer's address.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getpeername( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.lp
+The names returned by 
+\fIgetsockname()\fR and \fIgetpeername()\fR 
+do not contain extended TSELs.
+Extended TSELs can be retrieved with 
+the \fIgetsockopt()\fR and 
+\fIsetsockopt()\fR system calls, described below.
+.pp
+Unix supports several protocol-independent options
+and protocol-specific options
+associated with sockets.
+These options can be inspected and changed by using
+the \fIgetsockopt()\fR and 
+\fIsetsockopt()\fR system calls.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getsockopt( s, level, option, value, valuelen )
+.T&
+l l l.
+ +int+s, level, option;
+ +char+*value;
+ +int+*valuelen;
+.TE
+\fR
+.)b
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = setsockopt( s, level, option, value, valuelen )
+.T&
+l l l.
+ +int+s, level, option;
+ +char+*value;
+ +int+valuelen;
+.TE
+\fR
+.)b
+.pp
+The \fIlevel\fR argument may indicate
+either
+that this option applies to sockets or that it applies to
+a specific protocol.
+The constants SOL_SOCKET, SOL_TRANSPORT, and SOL_NETWORK
+are possible values for the \fIlevel\fR argument.
+The \fIoption\fR argument is an integer that identifies
+the option chosen.
+.\" LIST THE OPTIONS HERE
+The options available to TP users provide the 
+user with the ability to control various TP protocol options
+including but not limited to
+TP class, TPDU size negotiated, TPDU format used,
+acknowledgment and retransmission strategies.
+For a detail list of the options, see the manual page \fItp(4p)\fR.
+.sh 1 "Extended TSELs"
+.pp
+ARGO supports TSELs
+of length 1 byte - 64 bytes for sockets bound to addresses in the
+AF_ISO address family.
+The ARGO user program uses the
+\fIgetsockopt()\fR
+and 
+\fIsetsockopt()\fR
+system calls to 
+discover and assign extended TSELs.
+.pp
+To create a socket with an extended TSEL,
+the process 
+.ip \(bu 5
+opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
+.ip \(bu 5
+binds an NSAP-address to the socket with \fIbind()\fR.
+The address bound may contain a 2-byte selector (\fIiso_tsuffix\fR).
+.ip \(bu 5
+uses \fIsetsockopt()\fR with the command TPOPT_MY_TSEL,
+to assign a TSEL to the socket.
+.ip \(bu 5
+calls \fIlisten(), connect()\fR, or any other appopriate system calls
+to use the socket as desired.
+.lp
+To connect to a transport entity that is bound to a TSAP-address with
+an extended TSEL, the
+process 
+.ip \(bu 5
+opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
+.ip \(bu 5
+uses \fIsetsockopt()\fR, with the command TPOPT_PEER_TSEL,
+to assign a PEER TSEL to the socket.
+This TSEL is used by the transport entity 
+for all subsequent connect requests made on this socket, 
+unless the peer TSEL is changed by another call to
+\fIsetsockopt()\fR employing the command TPOPT_PEER_TSEL.
+.lp
+To discover the TSEL of the peer of a connected socket,
+the process 
+.ip \(bu 5
+uses \fIgetsockopt()\fR with the command TPOPT_PEER_TSEL.
+.lp
+To discover the TSEL of socket's own address,
+the process 
+.ip \(bu 5
+uses \fIgetsockopt()\fR with the command TPOPT_MY_TSEL.
+.sh 1 "Data transfer"
+.pp
+Earlier BSD-based systems have provided system calls for data transfer
+having bugs and semantics that are problematic for TP.
+These should be correct as presented in the test system.
+The problem was in the manner in which the kernel
+handled interrupted system calls.
+The send and receive primitives
+may be interrupted by signals.
+A signal is the mechanism used to indicate
+the presence of expedited data or out-of-band data.
+If the send primitive as interrupted before completion,
+the user could not determine how many octets of data were sent.
+All forms of the existing interface 
+(\fIsend()\fR, 
+\fIrecv()\fR, 
+\fIsendmsg()\fR, 
+\fIrecvmsg()\fR, 
+\fIsendto()\fR, 
+\fIrecvfrom()\fR, 
+\fIwrite()\fR, 
+\fIread\fR, 
+\fIwritev()\fR, 
+and \fIreadv()\fR system calls)
+return an octet count
+when the system call completes, and to return a short count
+if the system call is interrupted. 
+.pp
+The system calls sendmsg and recvmsg 
+have been revised to make them more convenient for receipt of
+out of band data.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+cc = sendmsg( s, msg, flags )
+.T&
+l l l.
+ +int+s;
+ +istruct msghdr+msg;
+ +unsigned int+flags;
+.TE
+\fR
+.)b
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+cc = recvmsg( s, msg, flags )
+.T&
+l l l.
+ +int+s;
+ +istruct msghdr+msg;
+ +unsigned int+flags;
+.TE
+\fR
+.)b
+.pp
+The reader should now consult the manual page for recvmsg
+for an explanation of the elements of the msghdr structure,
+and how the calls may be used to glean user-connection-request data.
+.pp
+The \fIflags\fR parameter serves several purposes.
+The TP specification requires that TSDUs be unlimited in size.
+System calls cannot pass unlimited amounts of data between the user
+and the kernel, so
+there cannot be a one-to-one correspondence between TSDUs and
+system calls. 
+The \fIflags\fR
+parameter is used to mark the end-of-TSDU on sending data.
+When receiving, 
+TP sets this bit 
+in the flags element of the msghdr structure
+when the end of a TSDU is consumed.
+This way one TSDU can span several system calls.
+It is possible for the peer to send an empty TPDU with the end-of-TSDU
+flag set, in which case the transport user
+may receive zero octets with the end-of-TSDU flag set.
+.pp
+The \fIflags\fR parameter also serves to distinguish data transfer primitives
+from expedited data transfer primitives.
+The flag bit MSG_OOB is provided for "out of band data" in the
+DoD Internet protocols.  It is also used to provide the expedited data service
+of the ISO protocols.
+The transport layer will deliver one expedited datum (there will be a
+one-to-one correspondence between expedited TSDUs and XPD TPDUs)
+at a time.  
+The user must receive the datum before the transport
+layer will accept more expedited data.
+Each expedited datum my contain up to 16 octets.
+.pp
+.sh 1 "Disconnection"
+.pp
+The \fIclose\fR system call will disconnect any association
+between two TP entities.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = close( s )
+.T&
+l l l.
+ +int+s;
+.TE
+\fR
+.)b
+.pp
+The argument \fIs\fR is a socket descriptor.
+If a Unix user process terminates, Unix will close all files and
+sockets associated with the process, which means all transport
+connections associated with the process will be disconnected.
+.sh 1 "Indications from the transport layer to the transport user"
+.pp
+The above set of system calls allows you to establish
+a connection, transfer data, and disconnect. 
+The
+presence or reception of expedited data is indicated
+by TP setting the MSG_OOB bit in the flags element of the msg structure.
+A disconnection initiated by the peer or by one of the
+cooperating TP entities can be signalled by a control message,
+although we have not yet implemented this.
+.pp
+The Unix signal mechanism may be used to provide these
+service elements, as well.
+When an expedited data TSDU arrives, the TP may interrupt
+the user with a SIGURG signal ("urgent condition present on socket").
+The user must have previously registered a procedure to handle
+the signal by using the \fIsigvec()\fR system call or the
+\fIsignal()\fR library routine provided for that purpose.
+The signal handler takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+int  sighandler( signal_number)
+.T&
+l l l.
+ +int+signal_number;
+.TE
+\fR
+.)b
+.pp
+The \fIsignal_number\fR argument will be the well-known constant SIGURG.
+There are two reasons for 
+the transport layer to issue
+a SIGURG:  
+expedited data
+are present or
+disconnection was initiated by a transport entity or by the peer.
+Should the user have more than one transport connection open,
+another system call is used to determine to which socket(s)
+the urgent condition applies.
+This is the \fIselect()\fR system call, described below.
+.pp
+When the SIGURG indicates a disconnection, there may be
+user data from the peer present.
+TP saves the disconnect data for the user to receive via the
+\fIgetsockopt()\fR system call, or through the
+.IR recvmsg ()
+ancillary data mechanism.
+.\"
+.\"If the user does not receive the disconnect data before the
+.\"reference timer expires, the data will be discarded and the
+.\"socket will be closed.
+.pp
+Transport service users may use more than one transport
+connection at a time.
+The \fIselect()\fR system call facilitates this.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+#include <sys/types.h>
++
+nfound = select( num_to_scan, recvmask, sendmask, 
++exceptmask, timeout )
+.T&
+l l l.
+ +int+nfound, num_to_scan;
+ +fd_set+*recvmask, *sendmask, *exceptmask;
+ +time+timeout;
+.TE
+\fR
+.)b
+.pp
+This system call takes as parameters a set of masks 
+that specify a subset of the socket descriptors that are in
+use by the user program.
+\fISelect()\fR inspects the sockets to see if they have data
+to be received, can service a send without blocking, or
+have an exceptional condition pending, respectively.
+The masks will be set upon return to indicate the socket descriptors
+for which the respective conditions exist.
+The \fInum_to_scan\fR argument limits the number of sockets that are
+inspected.
+The call will return within the amount of time given in the
+\fItimeout\fR parameter, or, if the parameter is zero, \fIselect()\fR
+will block indefinitely.
+.\" FIGURE
+.so ../wisc/figs/TS_primitives.nr
+.pp
+.CF
+summarizes the mapping of the transport service primitives
+to Unix facilities.
diff --git a/share/doc/iso/wisc/Makefile b/share/doc/iso/wisc/Makefile
new file mode 100644
index 0000000..7d9aa87
--- /dev/null
+++ b/share/doc/iso/wisc/Makefile
@@ -0,0 +1,73 @@
+#
+#	Makefile for the tp documents:
+#   design: TP design/source guide
+#   appendix_a: index of tp kernel routines & macros by macro/routine name
+#   appendix_b: index of tp kernel routines & macros by file name
+#
+PRINTER = 3a
+TAGS	= ../../sys/tags
+SRCS	= ../../sys/netargo/tp_*.c ../../sys/netargo/tp_*.h ../../sys/netargo/tp*.trans
+TROFF = /usr/local/lib/troff
+
+#
+#	Print via speedy for cycles sake...
+#	(assumes postscript printer...)
+#
+program: 
+	@echo printer is $(PRINTER)
+	(cd figs; make)
+	format -P$(PRINTER) -t program.nr | rsh speedy psdit \| lpr -P$(PRINTER)
+
+parts:
+	@echo printer is $(PRINTER)
+	(cd figs; make)
+	format -P$(PRINTER) -t parts.nr   | rsh speedy psdit \| lpr -P$(PRINTER)
+#	format -P$(PRINTER) -t parts.nr > /dev/null
+#	soelim parts.nr | grn -P$(PRINTER) |\
+#		$(TROFF) -Tpsc | rsh speedy psdit \> /tmp/test
+#	soelim parts.nr | tbl > /tmp/parts.nr
+
+clean:
+	/bin/rm -f core junk* a.out *.o spell_errs made
+	touch spell_errs
+
+spell:
+	(cd figs; make)
+	(cd ../icon; make)
+	/usr/ucb/soelim program.nr | /usr/bin/spell -d hlista > spell_errs
+
+newdict:
+	cat spell_errs | spellin /usr/dict/hlista > hlista
+
+all: program appendix_a appendix_b appendix_c
+
+
+appendix_c:
+	format -P$(PRINTER) appendix_c.nr
+	tbl ../man/man4/table1.src > ../man/man4/table1.nr
+	tbl ../man/man4/table2.src > ../man/man4/table2.nr
+	tbl ../man/man4/table3.src > ../man/man4/table3.nr
+	soelim ../man/man4/tp.4p.src > ../man/man4/tp.4p
+	ditroff -man -P$(PRINTER) ../man/man1/xebec.1
+	ditroff -man -P$(PRINTER) ../man/man2/sendv.2
+	ditroff -man -P$(PRINTER) ../man/man2/recvv.2
+	ditroff -man -P$(PRINTER) ../man/man3/libtp.3
+	ditroff -man -P$(PRINTER) ../man/man4/tp.4p
+	ditroff -man -P$(PRINTER) ../man/man8/tppt.8
+	ditroff -man -P$(PRINTER) ../man/man8/tpdebug.8
+	ditroff -man -P$(PRINTER) ../man/man8/tpstat.8
+
+appendix_a:
+	ctags -x $(SRCS) | awk '{printf("%s	%s	%s\n",  $$1, $$3, $$2)}'\
+		| sed -e 's-../../sys/netargo/--' > index_by_func.nr
+	format -P$(PRINTER) appendix_a.nr
+
+appendix_b:
+	ctags -x $(SRCS) | awk '{printf("%s	%s	%s\n",  $$3, $$1, $$2)}'\
+		| sed -e 's-../../sys/netargo/--' \
+		| sort \
+		| fmtxref -w 80 \
+		| sed	-e 's/					/		/' \
+				-e 's/			/	/' \
+		> index_by_file.nr
+	format -P$(PRINTER) appendix_b.nr
diff --git a/share/doc/iso/wisc/Outline b/share/doc/iso/wisc/Outline
new file mode 100644
index 0000000..30ea7b8
--- /dev/null
+++ b/share/doc/iso/wisc/Outline
@@ -0,0 +1,18 @@
+Ch 1 Intro
+Ch 2 Definitions
+Ch 3 Transport Service Interface
+Ch 4 Network Service Interface
+	- user interface
+	- kernel interface
+Ch 5 Addressing
+Ch 6 Design of Transport
+Ch 7 Design of Network
+Ch 8 Error Handling
+	- transport
+	- network
+Ch 9 Guide to Transport Source Code
+Ch 10 Guide to Network Source Code
+Ch 11 Guide to Common Source Code
+Ch 12 Testing & Debugging
+ 	- transport
+	- network
diff --git a/share/doc/iso/wisc/TODO b/share/doc/iso/wisc/TODO
new file mode 100644
index 0000000..8e7bf64
--- /dev/null
+++ b/share/doc/iso/wisc/TODO
@@ -0,0 +1,2 @@
+update clnp echo doc
+add esis
diff --git a/share/doc/iso/wisc/addr.nr b/share/doc/iso/wisc/addr.nr
new file mode 100644
index 0000000..1133422
--- /dev/null
+++ b/share/doc/iso/wisc/addr.nr
@@ -0,0 +1,155 @@
+.NC "NSAP Addresses & Routing"
+.sh 1 "OSI Address Formats"
+.pp
+ARGO supports an ISO address family, AF_ISO, in addition to the
+DoD Internet address family, AF_INET.
+Addresses in the family AF_ISO 
+take the form described by ISO 8348/DAD2, which is an addendum to the
+OSI network service standard that describes network layer addressing.
+.sh 2 "ISO 8348/DAD2 Tutorial"
+.pp
+.\" FIGURE
+.\".so figs/osi_addr.nr
+.so figs/addrfmt.nr
+.CF
+shows the
+format of an OSI NSAP-address.
+The address has two major parts: the initial domain part
+(IDP) and the domain specific part (DSP). The IDP is further divided into
+two parts: the authority and format identifier (AFI) and the
+initial domain identifier (IDI). The AFI specifies the format of the
+IDI, the authority responsible for allocating values of the IDI, and
+the syntax of the DSP. The IDI specifies the network addressing domain
+from which DSP values are allocated, and the authority responsible for
+allocating DSP values.
+.sh 2 "Supported Formats"
+.pp
+ARGO supports three types of ISO NSAP-addresses:
+one type with AFI 37(hex) and two types with AFI 47(hex).
+.sh 3 "AFI 37"
+.pp
+This value of the AFI defines the IDI to be an X.121 address or DTE
+address. 
+The DTE address is encoded in binary coded decimal.  
+The DSP syntax is binary.
+This form is intended to be used when communicating 
+across a public data network (PDN). 
+The ARGO software and documentation
+refer to this type of NSAP-address as a
+\*(lqtype 37.\*(rq
+address.
+.sh 3 "AFI 47"
+.pp
+The value of 47 for the AFI defines the IDI to be a 4 digit International
+Code Designator (ICD) allocated according to ISO 6523. 
+ARGO support two
+ICD values.
+.sh 4 "ICD 0004"
+.pp
+The ICD value of 0004 is assigned to OSINET,
+an experimental OSI network overseen by 
+National Institute of Science and Technology.\**
+.(f
+\** formerly the National Bureau of Standards
+.)f
+When this style of NSAP-address
+is used, 
+the DSP is divided into four parts: an organization identifier (2 bytes),
+a subnet identifier (2 bytes), 
+an SNPA-part (4-8 bytes), and
+an NSAP selector (1 byte). 
+The use of these fields is defined by the OSINET steering committee.
+This type of address is known as an
+\*(lqOSINET\*(rq
+address.
+.sh 4 "ICD 0006"
+.pp
+The ICD value of 0006 is assigned to the Department of Defense (DoD).
+In ARGO, NSAP-addresses with an ICD value of 0006 
+are of the format defined in RFC 986, a proposal for embedding DARPA Internet
+addresses within an OSI NSAP-address. 
+In this case, the DSP takes the form:
+version (1 byte), DARPA Internet Address (4 bytes), upper layer protocol
+identifier (1 byte).
+This is called an
+\*(lqrfc986\*(rq
+address.
+.sh 1 "Internal Representation"
+.pp
+Internally, an NSAP address takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s s.
+struct iso_addr {
+.T&
+l l l l l.
++u_char+isoa_afi;+/* authority &
++++format id */
++union+{+ 
+++struct addr_37+addr_37;+/* x.121 */
+++struct addr_osinet+addr_osinet;+/* OSINET */
+++struct addr_rfc986+addr_rfc986;+/* Internet*/
++}+isoa_u;
++u_char+isoa_len;+/* length */
+}
+.TE
+\fR
+.)b
+The field \fIisoa_afi\fR contains the AFI for the address. 
+The union
+\fIisoa_u\fR contains the remainder of the address. 
+The length of the entire address (the AFI, IDI, and DSP) is 
+stored in \fIisoa_len\fR.
+.sh 1 "Network Layer Routing"
+.pp
+Routing at the network layer is performed by the 
+routing procedure \fIrtalloc()\fR as described in Chapter 5. 
+\fIRtalloc()\fR was designed for used in the DoD Internet
+domain.
+An unfortunate
+effect of this is that routing decisions are based upon either the
+entire NSAP address or the network portion of the address. 
+The problem is defining the network portion of an NSAP address. 
+The location and extent of the 
+network portion of an NSAP address depends on the
+style of NSAP address. 
+This decision is made by the function \fIiso_netof()\fR.
+.sh 2 "Network Portion of Type 37 Addresses"
+.pp
+There is no network portion of an X.121 address. 
+In ARGO, the network portion of a type 37 address 
+is defined to be just the AFI. 
+The obvious consequence of this is that all type 37 addresses will 
+match all other type 37 addresses
+in a network-portion comparison.
+.sh 2 "Network Portion of OSINET Addresses"
+.pp
+The network portion of an OSINET address is the organization identifier and
+the subnet identifier.
+.sh 2 "Network Portion of RFC986 Addresses"
+.pp
+The network portion of an RFC986 address is the network portion of the
+embedded DARPA Internet address. 
+ARGO does not support subnetting, a method of subdividing Internet addresses.
+.sh 1 "NSAP Address / Subnetwork Point of Attachment Mapping"
+.pp
+In order to transmit a packet on a real subnetwork, the destination
+NSAP address
+must be mapped to an SNPA address. 
+An SNPA address is the real, "hardware" address
+of a system on a network. 
+This address corresponds to the 6 byte Ethernet or Token Ring
+Adapter address, 
+or to the DTE address, which may be up to 7 bytes
+long (14 decimal digits).
+.pp
+A table, \fIsnpa_cache\fR is kept in the kernel which contains the 
+translation between NSAP-addresses and SNPA-addresses. 
+This table is used by \fIiso_snparesolve()\fR whenever a 
+datagram must be dispatched.
+The table is maintained by the the ISO ES-IS protocol entity.
+Entries can be added and deleted
+by the user program \fIclnlutil(8)\fR and
+by the CONS entity.
diff --git a/share/doc/iso/wisc/appendix_a.nr b/share/doc/iso/wisc/appendix_a.nr
new file mode 100644
index 0000000..2522854
--- /dev/null
+++ b/share/doc/iso/wisc/appendix_a.nr
@@ -0,0 +1,51 @@
+.\" $Header: appendix_a.nr,v 1.3 88/12/07 10:42:12 nhall Exp $
+.(x
+Appendix A
+.)x
+.bp
+.sz +2
+.ce 3
+Appendix A
+
+\fBStandards Documents\fR
+.sz -2
+.lp
+The following appendix lists many of the standards documents which were
+consumed during development.
+.ip "\fBNetwork Layer\fR"
+.ip "ISO 8348" 15
+Network Service Definition
+.ip "ISO 8348/AD1" 15
+Connectionless-mode Transmission
+.ip "ISO 8348/AD2" 15
+Network Layer Addressing
+.ip "ISO 8648" 15
+Internal Organization of the Network layer
+.ip "ISO 8473" 15
+Protocol for Providing the Connectionless Network Service
+.ip "ISO 8473/DAD1" 15
+Provision of the Underlying Service Assumed by ISO 8473
+.ip "ISO 8473/DAD2" 15
+Formal Description of ISO 8473
+.ip "ISO 9542" 15
+End System to Intermediate System Routing Exchange Protocol
+for use in conjuction with the Protocol providing the Connectionless-mode
+Network Service
+.ip "ISO 8208" 15
+X.25 packet level protocol for data terminal equipment
+.ip "ISO 8878" 15
+Use of X.25 to Provide the Connection-mode Network Service
+.ip "\fBTransport Layer\fR"
+.ip "ISO 8072" 15
+Transport Service
+.ip "ISO 8073" 15
+Transport Protocol
+.ip "ISO 8073/PDAD2" 15
+Class 4 over Connectionless Network
+.ip "\fBFunctional Standards Profiles\fI"
+.ip "OSINET" 15
+Implementation Agreements Among Participants of OSINET, December 1987
+.ip "NBS" 15
+Implementors's Agreements
+.ip "GOSIP" 15
+Government OSI Profile
diff --git a/share/doc/iso/wisc/appendix_b.nr b/share/doc/iso/wisc/appendix_b.nr
new file mode 100644
index 0000000..01ade55
--- /dev/null
+++ b/share/doc/iso/wisc/appendix_b.nr
@@ -0,0 +1,10 @@
+.\" $Header: appendix_b.nr,v 1.1 88/12/05 18:08:02 nhall Exp $
+.(x
+Appendix B
+.)x
+.bp
+.sz +2
+.ce 3
+Appendix B
+
+\fBManual Pages\fR
diff --git a/share/doc/iso/wisc/debug.nr b/share/doc/iso/wisc/debug.nr
new file mode 100644
index 0000000..352eeee
--- /dev/null
+++ b/share/doc/iso/wisc/debug.nr
@@ -0,0 +1,1043 @@
+.\"$Header: debug.nr,v 1.4 88/12/06 16:05:36 nhall Exp $
+.\"$Source: /usr/argo/doc/kernel/RCS/debug.nr,v $
+.\"
+.\"	Program names should be in italics
+.\"
+.NC "Debugging, Testing, and Statistics"
+.sh 1 "Introduction"
+.pp
+This section describes the methods used 
+to test and debug the ARGO kernel.
+Three facilities are used in combination: 
+debug options,
+simple statistics gathering, 
+and
+protocol event tracing.
+Many of the debug options
+simply cause information to be printed on the console, but
+several of these options cause
+TP to behave pathologically
+so that errors are be introduced in desirable ways.
+.pp
+TP and CLNP keep simple statistics.
+These statistics include such things as the total
+number of PDUs that are sent and received, 
+a count of various types of errors
+that can be encountered when parsing an incoming PDU,
+and the average and standard deviation of round trip times for 
+transport PDUs.
+These statistics are useful for debugging.
+For example,
+if an incoming CC TPDU is rejected because one of the optional
+parameters is faulty, this are noted in the statistics.
+The statistics are kept on a system-wide basis rather than
+on a per-connection basis.
+They can be printed or cleared by user-level utility programs.
+.pp
+The tracing facility allows selective tracing of events.
+Events are grouped into categories relating to different
+functions of TP.
+For example, it is possible to 
+trace only the events that pertain to acknowledgments.
+.pp
+At run time the debugging and tracing options can
+be set and cleared by privileged utility programs.
+Each of these facilities is described in more
+detail below.
+.sh 1 "Debugging"
+.pp
+Most of the debugging options
+print messages on the console.
+Kernel printing is done by busy-waiting at high priority,
+so debugging options should be used very sparingly.
+A sample of the code is:
+.(b
+.nf
+\fC
+IFDEBUG(D_TPINPUT)
+     printf("tp_input m 0x%x tpdu_len 0x%x\n", m, tpdu_len);
+ENDDEBUG
+\fR
+.fi
+.)b
+.sp 1
+.lp
+IFDEBUG and ENDDEBUG are macros that are defined in one of two ways.
+If the system is configured with the ARGO_DEBUG
+option, an array 
+\fCargo_debug[128]\fR
+is declared, and
+IFDEBUG and ENDDEBUG are defined thus:
+.(b 
+.nf
+\fC
+#define IFDEBUG(option) if(argo_debug[option]) {
+#define ENDDEBUG  ; }
+\fR
+.fi
+.)b
+.lp
+If the system is configured without the ARGO_DEBUG option, these
+two macros resolve to the C comment delimiters, \fC/*\fR and \fC*/\fR,
+causing all the debugging code lying between the macros
+to be elided.
+.pp
+TP, CLNP, and CONS debugging can be enabled independently. 
+All debugging requires that the code be compiled with the 
+option ARGO_DEBUG. 
+The \fIconfig(8)\fR option CLNP_DEBUG will include debugging printfs for CLNP. 
+TP_DEBUG has the same effect for TP.
+.pp
+The array elements of \fCargo_debug[]\fR are set by
+the utility program
+\fIbark\fR, 
+which reads and writes
+\fC/dev/kmem\fIN\fR.
+See the manual page \fIbark(8)\fR.
+.pp
+Several debugging options cause TP to behave pathologically,
+for the purpose of reproducing difficult-to-reproduce
+error conditions that the protocol must correct.
+For example, the 
+\fID_DROP\fR, or \fIbark -on T.drop\fR
+option causes 
+\fItp_input()\fR
+to discard TPDUs on a pseudo-random basis.
+These will be described below.
+.sh 1 "Statistics"
+.pp
+.sh 2 "CLNP Statistics"
+.pp
+CLNP keeps a set of statistics related to its operation. 
+Statistics include such things as NPDUs sent, received, and dropped. 
+These statistics are stored in the global structure \fIclnp_stat\fR.
+The utility program \fInetstat(8)\fR may be used to print these statistics.
+.sh 2 "TP Statistics"
+.pp
+TP keeps a set of running counts of certain events.
+The statistics include such things as the numbers 
+of each type of TPDU sent and received, TPDUs dropped,
+and the numbers of occurrences of certain types of errors.
+The statistics are stored in the global structure \fItp_stat\fR.
+The utility programs 
+\fItpstat\fR and
+\fItpmon\fR
+read \fC/dev/kmem\fIN\fR
+and prints the contents of the statistics structure
+in a human-readable form.
+\fITpstat\fR prints the statistics on any ascii screen or printer.
+\fITpmon\fR uses the \fIcurses\fR library and assumes that is has
+a screen or window of size 53(long) X 80(wide), and it updates the
+screen every 30 seconds.
+.pp
+\fITpstat\fR and \fItpmon\fR can be used to clear the statistics (set them
+all to zero); the \fB-c\fR option causes the statistics to be cleared.
+.pp
+Statistics are observed using \fItpstat(8)\fR
+to clear statistics before a test, and to print
+the statistics after the test.
+See the manual pages \fItpstat(8)\fR and \fItpmon(8)\fR.
+.sh 1 "Tracing"
+.pp
+.sh 2 "CLNP Tracing"
+.pp
+CLNP does not support event tracing.
+.sh 2 "TP Tracing" 
+.pp
+The tracing facility consists of a circular buffer (an array)
+of structures that are written by the kernel at various times, 
+and a utility program that reads \fC/dev/kmem\fIN\fR
+to interpret the contents of the buffer.
+The trace structure is a union of the structures that
+will be interpreted by the utility program.
+A trace event consists of a call to the trace routine \fItpTrace\fR
+with a set of arguments containing the information relevant to the
+event being traced.
+The procedure tpTrace is actually called through a macro \fItptrace\fR.
+For example,
+.(b
+.nf
+\fC
+IFTRACE(D_INPUT)
+     tptrace(TPPTtpduin, h->tpdu_type, h, h->tpdu_li+1, 0, 0);
+ENDTRACE
+\fR
+.fi
+.)b
+.pp
+The tracing macros are defined in the same manner as the 
+debugging macros:
+.(b
+.nf
+\fC
+#define IFTRACE(option) if(tp_traceflags[option]) {
+#define ENDTRACE  }
+\fR
+.fi
+.)b
+.lp
+If the kernel is configured with the option TPPT, these macros
+are defined as shown above, but if the TPPT option is not
+used, these macros become C-style comment delimiters.
+.pp
+The tracing procedure copies \fIh->tpdu_li + 1\fR bytes beginning at
+location \fIh\fR into a trace structure in the circular buffer.
+The utility program \fItppt\fR
+reads the trace structure, 
+interprets the data as a TPDU header,  
+and prints the header in hexadecimal form, with a banner identifying
+the event as an incoming TPDU:
+.(b
+.nf
+\fC
+1a: Ref 22 	arg 14(0xe), 	@ 91990 : 0000.453125  	tpdu
+INPUT  total len 22
+HDRLEN:  21+1 	CR_TPDU_type 	cdt 0(0x0) 	dref 0x0
+		 + 0: 0x15 0xe0 0x00 0x00   4: 0x00 0x03 0x00 0xc1 
+		 + 8: 0x06 0x74 0x70 0x70  12: 0x69 0x6e 0x67 0xc2 
+		 +16: 0x02 0x00 0x07 0xc0  20: 0x01 0x08 0x00 0x00 
+
+\fR
+.fi
+.)b
+.pp
+In addition to the data copied from the arguments to tpTrace(), 
+each trace structure contains
+a time stamp and an event sequence number, and in many cases, the
+connection reference to which the traced event applies.
+The utility program \fItppt\fR is be used to turn on and off the
+tracing options.
+.pp
+This facility can be used for debugging the source
+code as well as for studying the behavior of the protocol.
+For example, by adding the appropriate trace events,
+it is possible to "see" the resequencing function of TP
+working when a debug option is used to cause
+TPDUs to be dropped occasionally.
+.pp
+See the manual page \fItppt(8)\fR. 
+.sh 1 "Testing"
+.pp
+.sh 2 "CLNP Testing"
+.pp
+CLNP was tested in two rather different ways. 
+The first method of testing used the
+raw CLNP interface with the program \fIclnptest\fR.
+\fIclnptest\fR allows a user to send or receive CLNP NSDUs. 
+With \fIclnptest\fR, a user can send CLNP NSDUs with various
+combinations of options and observe the result.
+.pp
+The second method of testing CLNP was to have TP use CLNP as its network
+layer protocol. 
+This method provides a good stress test for CLNP. 
+Unfortunately, TP generally calls CLNP in the same manner, so that not all
+of the CLNP options are exercised.
+.sh 3 "Clnptest"
+.pp
+The program \fIclnptest\fR can be invoked as either 
+a reader or as a writer:
+.(b
+\fC
+clnptest <options>
+\fR
+.)b
+The \fI-r\fR option invokes \fIclnptest\fR as a reader, the
+\fI-w\fR option invokes it as a writer. 
+Other options allow the user to indicate the destination, number of NSDUs, 
+size of NSDUs,
+and NSDUs options. 
+See \fIclnptest(8)\fR for more information.
+.pp
+\fIclnptest\fR is normally used in the following manner. 
+On one machine, invoke \fIclnptest\fR as a reader:
+.(b
+\fC
+clnptest -r
+\fR
+.)b
+On a different machine, transmit an NSDU.
+For example, to test the source route function, one invokes:
+.(b
+\fC
+clnptest -w -h a -oR "b, c, d"
+\fR
+.)b
+This sends an NSDU to host 'a', source routing it via
+hosts 'b', 'c', and 'd'.
+.sh 3 "The Troll"
+In order to test CLNP reassembly certain errors must be generated. 
+The mechanism used has two parts, 
+the user program \fIclnptroll\fR, which enables and disables
+the generation of these errors, and the 
+kernel resident error-creation routines.
+.pp
+Troll options allow one to duplicate an NSDU with a specified frequency. 
+The kernel must be compiled with the \fIconfig\fR option \fITROLL\fR
+in order to include troll code.
+See \fIclnptroll(8)\fR for more information.
+.sh 3 "Debugging CLNP"
+.pp
+The following sections describe the \fIbark\fR options 
+appropriate for testing parts of CLNP. 
+Refer to \fIbark(8)\fR for more information about debugging
+using \fIbark\fR..
+.sh 4 "Sending NSDUs"
+.pp
+Turning on the \fIbark\fR
+option \fIC.output\fR causes information to be
+printed whenever an NSDU is transmitted. 
+Translation of NSAP addresses to SNPA can be monitored by turning on 
+the \fIC.un\fR, or \fIC.lan\fR options. 
+Parts of outgoing NSDUs can be dumped when the \fIC.dumpout\fR
+option is on.
+Routing activity can be watched by turning on \fIC.route\fR and \fIC.iso\fR.
+Information about CLNP option processing is available with \fIC.options\fR.
+.sh 4 "Forwarding NSDUs"
+.pp
+The \fIforward\fR switch will cause debugging information to be displayed
+whenever NSDUs are forwarded.
+.sh 4 "Receiving NSDUs"
+.pp
+Information is displayed about incoming NSDUs when the \fIC.input\fR
+option is enabled. 
+A portion of incoming NSDUs can be dumped by turning on the 
+\fIC.dumpin\fR option.
+.sh 4 "Fragmentation and Reassembly"
+.pp
+The options \fIC.frag\fR and \fIC.reass\fR turn on debugging for the 
+CLNP fragmentation and reassembly functions.
+.sh 2 "TP Testing"
+.pp
+Five services were used for most of the testing:
+the \fIdiscard\fR service,
+the \fIecho\fR service, 
+the \fIremote login\fR service, 
+the \fIremote shell\fR service, 
+and
+the \fIsimple file transfer\fR service.\**
+.(f
+\** In fact, ancestors of these services were used for testing the
+ARGO transport implementation during development.
+These programs in their original forms were very cumbersome to use;
+consequently they evolved to become the services described here.
+.)f
+Each service consists of a daemon process or server that listens
+on a well-known transport selector (which is listed in the 
+ARGO directory service), and an active process that contacts the
+server.
+Four of these services,  
+discard, echo, remote login, and remote shell,
+are supported by the
+\fIisod\fR suite of daemons, which is a
+version of the \fIinetd\fR programs that uses
+the ISO protocol suite.
+.sh 3 "The Discard Service"
+The discard server listens on the transport selector
+registered in the ARGO directory service for the application
+"discard".
+The server accepts incoming connection requests, 
+receives TSDUs, and throws away the TSDUs.
+It never initiates a disconnect, but expects its peer
+to disconnect the transport connection.
+.PP
+The program \fItpdiscard\fR connects to the
+discard server.
+The transport service and protocol options it uses are those
+indicated in the ARGO directory service.
+By changing the directory service entry for the 
+discard service, each of the transport service options and
+protocol options can be demonstrated.
+See the manual pages
+\fItpdiscard(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 3 "The Echo Service"
+The echo server listens on the transport selector
+registered in the ARGO directory service for the application
+"echo".
+The server accepts incoming connection requests, 
+receives TSDUs, and returns the TSDUs to the sender.
+It never initiates a disconnect, but expects its peer
+to disconnect the transport connection.
+.pp
+The 
+program \fItpping\fR connects to the
+echo server.
+The transport service and protocol options it uses are those
+indicated in the ARGO directory service.
+By changing the directory service entry for the 
+echo service, each of the transport service options and
+protocol options can be demonstrated.
+See the manual pages
+\fItpping(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 3 "The Remote Login Service"
+The remote login server listens on the transport selector
+registered in the ARGO directory service for the application
+"login".
+The server accepts incoming connection requests,
+implements the BSD remote login protocol, checks permissions using
+the \fC~/.rhosts\fR, and \fC/etc/passwd\fR files, and
+uses the ARGO directory service to discover name-to-NSAP-address
+mappings.
+If the remote user is authorized to log in to the end system on which
+the server runs, a login is started.
+.pp
+The program \fIrlogin.iso\fR connects to the remote login server.
+The transport service and protocol options it uses are those
+indicated in the ARGO directory service.
+By changing the directory service entry for the 
+login service, each of the transport service options and
+protocol options can be demonstrated.
+See the manual pages
+\fIrlogin.iso(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 3 "The Remote Shell Service"
+The remote shell server listens on the transport selector
+registered in the ARGO directory service for the application
+"shell".
+The server accepts incoming connection requests,
+implements the BSD remote command authorization protocol, 
+checks permissions using
+the \fC~/.rhosts\fR, and \fC/etc/passwd\fR files, and
+uses the ARGO directory service to discover name-to-NSAP-address
+mappings.
+If the remote user is authorized to execute a shell on
+the end system on which
+the server runs, a shell is started.
+.pp
+The program \fIrcp.iso\fR connects to the remote shell server to 
+effect a remote copy.
+The transport service and protocol options it uses are those
+indicated in the ARGO directory service.
+By changing the directory service entry for the 
+shell service, each of the transport service options and
+protocol options can be demonstrated.
+See the manual pages
+\fIrcp.iso(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 3 "The Simple File Transfer Service"
+.pp
+The last service consists of a pair of programs,
+\fItpfileget\fR and
+\fItpfileput\fR,
+which cooperate to transfer one file.
+The passive program, \fItpfileget\fR,
+listens on the transport selector registered in the ARGO directory service
+to support the application named "tptestsel".
+The sending program, \fItpfileput\fR, 
+connects to the passive program, transfers in one TSDU
+the file named on the \fItpfileput\fR command line, and waits for the
+passive end to close the connection.
+\fITpfileget\fR 
+opens a file of the name given on its command line,
+accepts one connection request, receives 
+one TSDU, writes the contents of that TSDU to the opened file,
+and when it receives the end-of-TSDU indication,
+\fItpfileget\fR closes the transport connection.
+The transport service options and protocol options used by
+\fItpfileput\fR are determined by the ARGO directory service
+record that describes the applicaition "tptestsel".
+See the manual pages
+\fItpfileget(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 3 "Internal TP Testing"
+.pp
+The methods used to test each of the various functions
+of TP are described in this section.
+One or more of the services described above were used, while
+the TP activity was observed with tracing or debugging or both.
+The statistics were cleared before each test and inspected
+after each test.
+Each test can be run with different protocol and service options,
+by changing the transport parameters in records
+in the ARGO directory service file.
+See the manual pages
+\fItpstat(8)\fR,
+\fItpmon(8)\fR,
+\fItppt(8)\fR,
+\fIbark(8)\fR,
+\fItp(4p)\fR,
+and 
+\fIisodir(5)\fR
+for more information.
+.sh 4 "Normal and Expedited Data Transfer:"
+.pp
+TSDUs are 
+distinguished by the presence or absence of the
+EOTSDU bit in the \fIflags\fR parameter of the
+\fIsendv()\fR system call.
+The data of a TSDU are copied into chains of \fImbufs\fR
+in the kernel so that the end of a TSDU lies in an mbuf
+with the \fIm_act\fR field non-zero.
+The end of a TSDU never lies in the middle of an
+mbuf.
+This is true on the receiving side as well.
+On output, the segmenting function,
+the function that copies user data into mbuf chains
+reorganizes mbuf chains into TPDUs,
+is observed using several debug options
+and trace options
+in the routines \fIsosend()\fR 
+and \fItp_sbsend()\fR.
+On input, the reassembling mechanism
+is observed in the routine \fItp_stash()\fR.
+The debug options 
+\fBT.ndata\fR, 
+\fBT.sb\fR, and 
+\fBT.xpd\fR
+print information 
+pertinent to this function.
+.pp
+Expedited data complicates the matter of segmenting
+because markers must be kept in the chains of outgoing
+TPDUs to indicate the precedence of expedited data TPDUs
+over normal data TPDUs.
+The pertinent trace options are \fBT.sb\fR and \fBT.ndata\fR.
+With the trace and (or) debugging options on,
+and with \fItpdiscard\fR running, one can observe the segmentation
+and reassembly of TPDUs.
+.pp
+Using the file transfer programs to transfer a file,
+then transferring it back with \fIrcp\fR (the TCP version) if necessary, and
+using
+\fIdiff\fR, one can see that data are transferred correctly.
+The \fBT.input\fR trace option creates a readable hexadecimal dump of incoming TPDUs.
+The 
+\fBT.emit\fR
+trace option creates the same sort of dump for outgoing
+TPDUs in \fItp_emit()\fR.
+Sequencing
+can be observed by using the 
+\fBT.ndata\fR
+and 
+\fBT.input\fR
+or 
+\fBT.emit\fR
+trace options
+to see the sequence numbers assigned to TPDUs.
+.pp
+The
+\fBT.drop\fR
+debug option causes \fItp_input()\fR
+to throw away occasional TPDUs.
+(The formula for determining when to discard a TPDU
+is ad hoc and simplistic.  It causes TPDUs to be
+discarded frequently but not so frequently that the 
+receiving side has no chance to recover.)
+With tracing on and the file transfer programs running,
+resequencing can be observed
+and the correctness of the transferred data
+can be verified with \fIdiff(1)\fR.
+.pp
+The use of both normal and extended formats
+can be observed with the \fBT.input\fR and \fBT.emit\fR trace options.
+.pp
+The following statistics are of interest:
+.(b
+.nf
+\fIn\fR connections used extended format
+\fIn\fR connections allowed transport expedited data
+\fIn\fR connections turned off checksumming
+\fIn\fR connections dropped due to retrans limit
+\fIn\fR EOT bits on incoming TPDUs
+\fIn\fR EOT bits on outgoing TPDUs
+\fIn\fR XPD marks discarded
+\fIn\fR XPD stopped data flow \fIm\fR times
+\fIn\fR DTs out of order
+\fIn\fR DTs not in window 
+\fIn\fR duplicate DTs
+\fIn\fR XPDs not in window
+\fIn\fR XPDs w/o credit to stash
+\fIn\fR DT (sent)
+\fIn\fR DT (received)
+\fIn\fR DT (retransmitted)
+\fIn\fR XPD (sent)
+\fIn\fR XPD (received)
+\fIn\fR random DTs dropped
+.fi
+.)b
+.sh 4 "Checksumming, use and non-use:"
+.pp
+The checksum generation and checking
+routines were first written and debugged as user-level
+routines before they were modified for kernel use.
+The kernel routines may be observed with the 
+\fBT.chksum\fR
+debug option.
+Various sizes of mbufs can be created by creative use of the
+ARGO directory service, particularly by changing the value of the
+attribute \fItp.tpdusize\fR.
+There is no trace option for checksumming.
+Checksumming has been used with transfers to and from at least
+one other TP implementation.
+.pp
+The statistics that are pertinent to checksumming are:
+.(b
+.nf
+\fIn\fR connections turned off checksumming
+\fIn\fR invalid checksums
+.fi
+.)b
+.sh 4 "Acknowledgment:"
+.pp
+Acknowledgment can be observed by using the 
+debug and trace options
+\fBT.aks\fR,
+\fBT.akr\fR,
+\fBT.input\fR,
+\fBT.emit\fR,
+and
+\fBT.driver\fR.
+The transport driver (finite state machine) and the routine 
+\fItp_goodack()\fR dump information appropriate to acknowledgments.
+If the \fBT.ndata\fR, and \fBT.emit\fR or \fBT.input\fR trace options are used 
+along with the \fBT.aks\fR and \fBT.akr\fR trace options,
+a complete picture of the data transfer and acknowledgment
+activity can be created.
+The acknowledgments for expedited data are traced with
+the 
+\fBT.xpd\fR
+trace option.
+The routine \fItp_goodXack()\fR and the finite state
+machine dump information when the
+\fBT.xpd\fR
+debug and trace options are used.
+To cause expedited data to be generated,
+the -e or -E option on the discard programs or the file
+transfer programs are used.
+To observe the different acknowledgment strategies,
+the protocol options were changed in the ARGO directory service.
+.pp
+The pertinent statistics are:
+.(b
+.nf
+\fIn\fR AK (received)
+\fIn\fR AK (sent)
+ACK reasons:
+\fIn\fR not acked immediately
+\fIn\fR strategy==each
+\fIn\fR strategy==fullwindow
+\fIn\fR duplicate DT
+\fIn\fR EOTSDU
+\fIn\fR reordered
+\fIn\fR user rcvd
+\fIn\fR fcc reqd
+.fi
+.)b
+.pp
+The smoothed average round trip time is kept
+for outgoing TPDUs for each transport connection 
+and for the entire TP entity.
+The time each TPDU is transmitted is recorded, and when an acknowledgment
+arrives, the round trip time is computed for the lowest
+sequence number that this AK TPDU acknowledges.
+The computation of round trip times can be observed
+in a trace with the
+\fBT.rtt\fR
+option.
+.pp
+In addition to average round trip times, the kernel
+maintains the standard deviation of the round trip times.
+This statistic is kept for each connection and for the entire
+TP entity.
+In fact, four such sets of statistics are kept for the TP entity:
+.np
+for traffic not on a public data network (PDN) and on the same network as this end system,
+.np
+for traffic not on a public data network (PDN) and on not the same network as this end system,
+.np
+for traffic on a public data network (PDN) and on the same network as this end system,
+and
+.np
+for traffic on a public data network (PDN) and not on the same network as this end system.
+The determination of whether traffic is on the same network as this end system
+is based on the "network portion" of the peer's NSAP-address.
+For more information about this, see the section of this document titled
+\fB"Network Layer Routing"\fR.
+.pp
+The smoothed average round trip time statistics for a given
+can be observed with the -t option to
+\fItpstat(8)\fR.
+The global round trip statistics can be observed with  the -s option to
+\fItpmon(8)\fR.
+.sh 4 "Flow Control:"
+.pp
+Flow control activity is the transfer of credit information
+from end to end and the proper use of that information.
+To see that it works properly, one must observe three
+things:
+the receiving window must shut down and reopen, 
+the sender must transmit enough TPDUs to fill the receiver's window 
+but no more, and the receiver must renege previously advertised credit.
+These three behaviors have been observed as follows.
+.pp
+Tracing with the 
+\fBT.ndata\fR, 
+\fBT.aks, \fR
+\fBT.akr, \fR
+\fBT.emit\fR 
+and 
+\fBT.input\fR 
+trace options
+are used.
+The program \fItpdiscard\fR or a simple file transfer
+is run with various window
+and maximum TPDU sizes, various acknoledgment strategies, and
+various retransmission strategies,
+and the activity is observed with the trace.
+The debug option
+\fBT.reneg\fR
+must be used to fake a reneging of credit, since
+the ARGO transport entity does not renege its advertised credit
+under normal operation.
+At the beginning of a connection a closed window may almost always
+be observed.
+The receiving user process may be stopped 
+to force a window to shut down.
+The interesting statistics are
+.(b
+.nf
+\fIn\fR times local cdt reneged (receiving)
+\fIn\fR foreign window closed (sending)
+\fIn\fR faked reneging of cdt
+\fIn\fR DT TPDUs (sent)
+\fIn\fR DT TPDUs (received)
+\fIn\fR AK TPDUs (sent)
+\fIn\fR AK TPDUs (received)
+ACK reasons:
+\fIn\fR not acked immediately
+\fIn\fR strategy==each
+\fIn\fR strategy==fullwindow
+\fIn\fR duplicate DT
+\fIn\fR EOTSDU
+\fIn\fR reordered
+\fIn\fR user rcvd
+\fIn\fR fcc reqd
+.fi
+.)b
+.sh 4 "Retransmission and retention until acknowledgment:"
+.pp
+To observe that the sender retains TPDUs until they are
+acknowledged, one needs only to use the
+\fBT.drop\fR
+debug option to cause TPDUs to be dropped by the receiving side.
+They are then retransmitted by the sender
+and finally dropped when the acknowledgment arrives.
+That the buffers used to hold retained TPDUs are freed 
+can be observed by 
+running \fInetstat(8)\fR with the -m option
+on a quiescent system to observe the number of mbufs in use,
+then
+running a test with the 
+\fBT.drop\fR debug option on to cause retransmission,
+and 
+finally
+running netstat -m again after the test is over,
+to see that all the mbufs have been freed by TP.
+The actual retransmission activity can be observed in a trace
+with the
+\fBT.ndata, \fR
+\fBT.emit\fR and 
+\fBT.input\fR trace options.
+The retransmission strategy to be used is controlled by the
+ARGO directory service.
+The statistics
+.(b
+.nf
+\fIn\fR DT (retransmissions)
+\fIn\fR XPD (retransmissions)
+\fIn\fR CR (retransmissions)
+\fIn\fR CC (retransmissions)
+\fIn\fR DR (retransmissions)
+.fi
+.)b
+.lp
+indicate the number of retransmissions that actually occurred.
+.sh 4 "Timers:"
+.pp
+The debug and trace option
+\fBT.timer\fR
+dumps information about the timers as they are set,
+as they are cancelled, and as they expire.
+The statistics
+.(b
+.nf
+\fIn\fR ticks 
+\fIn\fR timers set 
+\fIn\fR timers expired 
+\fIn\fR timers cancelled
+\fIn\fR inactive timers cancelled
+\fIn\fR connections dropped due to retrans limit
+\fIn\fR CCs sent to zero dref
+.fi
+.)b
+.lp
+are printed for both the E-type timers and for the C-type timers.
+The effect of timers can be seen by observing retransmissions.
+Two simple ways to force retransmissions are:
+.np
+to use the \fBT.zdref\fR debug option,
+which causes CCs to contain a zero destination reference,
+so that connection establishment will time out, and
+.np
+to attempt to open a connection to a transport selector on which
+no process is listening.
+Either of these actions, along with the 
+\fBT.connect\fR
+trace or debug option will permit
+observation of the timeout facilities.
+.sh 4 "TPDU creation and parsing:"
+.pp
+TPDUs are created for output in 
+\fItp_emit()\fR.
+The 
+\fBT.emit\fR
+trace
+option dumps TPDUs as they are transmitted.
+\fITp_input()\fR parses TPDUs on input.
+The 
+\fBT.input\fR
+trace
+option dumps TPDUs as they are received.
+The debug options \fBT.emit\fR and \fBT.input\fR dump a lot of excess information
+to the console, and are used primarily for debugging
+extremely pathological behavior.
+.pp
+By tracing the execution of 
+\fItpdiscard\fR or a simple file transfer,
+with a variety protocol and service options,
+using the 
+\fBT.connect,\fR
+\fBT.emit,\fR
+\fBT.input,\fR
+\fBT.ndata,\fR
+\fBT.aks,\fR
+\fBT.akr,\fR
+and 
+\fBT.xpd\fR
+options,
+one can verify the correct placement of TPDU options
+on all types of TPDUs.
+The interesting statistics are
+.(b
+.nf
+\fIn\fR variable parameters ignored 
+\fIn\fR invalid parameter codes
+\fIn\fR invalid parameter values
+\fIn\fR invalid dutypes
+\fIn\fR invalid negotiation failures
+\fIn\fR invalid destinagion referencess
+\fIn\fR invalid suffix parameters
+\fIn\fR invalid checksums
+\fIn\fR connections used extended format
+\fIn\fR connections allowed transport XPD
+\fIn\fR connections turned off checksumming
+\fIn\fR TP 4 connections 
+\fIn\fR TP 0 connections 
+.fi
+.)b
+.sh 4 "Separation and concatenation:"
+.pp
+Concatenation is not supported by this implementation.
+Separation is supported, however, and to test separation,
+some sort of concatenated TPDUs had to be created.
+The code for this is no longer supported.
+After testing locally with some temporary code to create concatenated
+TPDUs,
+the ARGO transport implementation was tested with another transport
+implementation that does generate concatenated TPDUs.
+The interesting statistics are:
+.(b
+.nf
+\fIn\fR concatenated TPDUs
+\fIn\fR TPDUs input
+.fi
+.)b
+.sh 4 "Length limits for TPDUs:"
+.pp
+Some TPDUs may take user data:
+the CR, CC, DR, DT, and XPD.
+All of these but the DT TPDU have limits to the amount
+of data they may carry.
+The limits are enforced for CR, CC, and DR TPDUs by
+\fItp_ctloutput()\fR,
+the routine that accepts data from the user.
+The limit for XPD TPDUs is enforced by
+\fItp_usrreq()\fR, which accepts expedited
+data from the user.
+To test the effectiveness of the checks on output, one may attempt
+to send expedited data with amounts larger than the limit (16 bytes).
+.pp
+On input the limits are checked in
+\fItp_input()\fR.
+To test the effectiveness of the checks on input, it was necessary
+to create an illegally large TPDU.
+The
+\fBT.badsize\fR
+debug option
+does this - it will turn a legitimate
+XPD TPDU into a XPD TPDU with 18 bytes
+of expedited data.
+The interesting statistics are:
+.(b
+.nf
+\fIn\fR illegally large XPD TPDU
+\fIn\fR invalid length
+.fi
+.)b
+.sh 4 "Frozen References:"
+.pp
+The key issue here is to see that references are not reassigned
+until the reference timer expires.
+This can be observed by watching the timer activity as described
+above and by observing the reference numbers chosen for sockets
+with the \fBT.emit\fR
+or \fBT.input\fR trace options, which trace the TPDU headers.
+.sh 4 "Inactivity Control:"
+.pp
+Inactivity control can be observed by turning on the trace options
+\fBT.aks\fR, \fBT.akr\fR and \fBT.emit\fR
+during a simple file transfer.
+In the middle of the transfer, if the sender process
+is stopped, both TP entities continue
+to send acknowledgments. 
+This can be observed in the trace.
+If the file tranfer is between machines, taking down one of the machines
+will cause the inactivity timer on the other machine to expire.
+The TP entity will respond to this by sending a DR TPDU
+to close the connection, which can be observed in the trace.
+The expiration of the timer can be observed in a trace if the
+\fBT.driver\fR option is used.
+This option traces all events and state changes in the 
+TP
+finite state machine.
+.sh 4 "Connection establishment:"
+.pp
+The process of connection establishment can be observed with the
+\fBT.connect\fR
+trace and debug options, and
+the 
+\fBT.driver \fR
+trace option.
+Various states of the connection establishment state machine
+may be observed with the
+the debug option
+\fBT.zdref\fR.
+This option
+causes \fItp_input()\fR
+to change the foreign reference on an incoming CC TPDU to zero,
+eventually causing the CC TPDU to be dropped,
+retransmissions of the CC to occur,
+and the connection to time out before being established.
+The statistics of interest are:
+.(b
+.nf
+\fIn\fR CCs sent to zero dref
+\fIn\fR invalid dest refs
+\fIn\fR CC (received)
+\fIn\fR CC (sent)
+\fIn\fR CC (retransmitted)
+\fIn\fR (connections) timed out on retrans
+.fi
+.)b
+.sh 4 "Disconnection:"
+.pp
+Various states of the connection breakdown part of the state machine
+may be observed with the
+the trace options
+\fBT.input\fR
+or
+\fBT.emit\fR, 
+\fBT.driver\fR
+and
+running the
+discard or file transfer programs.
+.sh 4 "Association of TPDUs with Transport Connection:"
+.pp
+The problem of locating a transport connection
+given a TPDU is handled in 
+\fItp_input()\fR in one of two ways.
+For an incoming CR TPDU, the transport suffix
+is used to locate a transport protocol
+control block (PCB), to which a transport
+connection is made by creating a new socket and PCB.
+For all other TPDU types, the destination reference is used
+to locate the appropriate transport connection.
+This is done by scanning the list of reference blocks.
+Debug and trace options
+were used to debug these sections of code but have since been
+removed due to their effect on the readability 
+and maintainability of this code.
+The trace options
+\fBT.connect\fR
+and
+\fBT.newsock\fR
+creates trace records that contain the address of the
+socket as well as that of the PCB
+when a socket is opened.
+When a TPDU arrives for a given socket,
+the trace records created by the
+\fBT.input \fR
+option will also contain the address of the PCB that is found
+in 
+\fItp_input()\fR.
+These two addresses can be compared in the trace output to observe
+that the proper association is made.
+.sh 4 "Protocol Errors and the ER TPDU:"
+.pp
+Certain types of errors are intended to evoke the response
+from the TP entity of sending an ER or a DR TPDU.
+The routine
+\fItp_error_emit()\fR
+creates ER and DR TPDUs for this purpose.
+The debug and trace option
+\fBT.erroremit\fR
+dumps information about the activity of this routine.
+Since ER TPDUs are not generated under normal circumstances,
+the parsing of ER TPDUs was tested in this
+implementation by code that generated (illegitimate) ER TPDUs,
+This code was removed because it significantly complicated code maintenance.
+.sh 4 "User Interface:"
+.pp
+The debug and trace options
+\fBT.request\fR, 
+\fBT.params,\fR
+\fBT.indication\fR 
+and
+\fBT.syscall\fR and
+dump information about the user interface.
+Most of the debugging code added to the socket-layer
+routines for debugging has since been removed so that
+the source (which is functionally unchanged from the 4.3 release)
+would not unnecessarily be changed.
+\fIRlogin.iso\fR, the TP version of remote login,
+exercises some of the original BSD data transfer system calls 
+(\fIread()\fR and \fIwrite()\fR)
+rather than \fIsendv()\fR and \fIrecv()\fR.
+The interesting statistics are
+.(b
+.nf
+\fIn\fR EOT indications
+\fIn\fR user rcvd
+\fIn\fR connections used extended format
+\fIn\fR connections allowed transport XPD
+\fIn\fR connections turned off checksumming
+\fIn\fR TP 4 connections 
+\fIn\fR TP 0 connections 
+.fi
+.)b
diff --git a/share/doc/iso/wisc/def.nr b/share/doc/iso/wisc/def.nr
new file mode 100644
index 0000000..1e691bf
--- /dev/null
+++ b/share/doc/iso/wisc/def.nr
@@ -0,0 +1,144 @@
+.NC "Definitions"
+.sh 1 "General Terms"
+.ip "Kernel" 5
+The source code or binary module for the Acis Operating System 
+(also know as AOS and IBM/4.3).
+.ip "User process" 5
+An instance of a program that is 
+running in unprivileged mode, in the unprivileged address space 
+commonly know as "user address space", in other words, not
+part of the kernel.
+.ip "IPC" 5
+Interprocess communication, the mechanism by which two different
+user processes send messages to each other.
+.ip "Unix, AOS" 5
+ACIS Operating System, the IBM ACIS port of Berkeley Unix 4.3BSD.
+.ip "PCB, pcb" 5
+Protocol control block.  Each instance of a protocol machine
+keeps status information, addresses, and in some cases queues
+in a pcb for each connection or socket.
+.ip "Domain" 5
+In the Berkeley Unix environment, a domain is an abstract entity which
+comprises a network architecture, addressing scheme, address format, 
+network protocols, and transport protocols.
+.sh 1 "Transport Layer Terms"
+.ip "ISO 8073"
+ISO Draft International Standard 8073, Transport Protocol Specification
+.ip "TP" 5 
+The collection of transport
+classes that have been implemented in ARGO, classes 0 and 4.
+Also means the ARGO implementation of TP. 
+.ip "TP 0" 5 
+Transport class 0.
+.ip "TP 4" 5 
+Transport class 4.
+.ip "Transport entity" 5
+Software or hardware that implements the elements of procedure
+described in ISO 8073.
+.ip "Transport user" 5
+User process that make use of the services
+provided by a transport entity.
+.ip "Transport service interface" 5
+The syntax and semantics of the set of procedures, functions, and system calls
+that are invoked by a transport user, 
+through which the services of the transport entity are delivered.
+.ip "TPDU" 5
+Transport protocol data unit, a packet that is
+passed from one transport entity to another.
+.ip "TSDU" 5
+Transport service data unit, the logical unit of data that is
+passed from a transport entity to a transport user, or from
+a transport user to a transport entity.
+.ip "CR TPDU" 5
+Connection request TPDU. 
+.ip "CC TPDU" 5
+Connection confirm TPDU.
+.ip "DR TPDU" 5
+Disconnect request TPDU.
+.ip "DC TPDU" 5
+Disconnect confirm TPDU.
+.ip "DT TPDU" 5
+Normal data TPDU.
+.ip "XPD TPDU" 5
+Expedited data TPDU.
+.ip "AK TPDU" 5
+Normal data acknowledgment TPDU.
+.ip "XAK TPDU" 5
+Expedited data acknowledgment TPDU.
+.ip "ER TPDU" 5
+Error TPDU.
+.sh 1 "Network Layer Terms"
+.ip "ISO 8473"
+ISO Draft International Standard 8473, connectionless network protocol.
+.ip "CONS"
+Connection Oriented Network Service.
+.ip "COSNS"
+Connection Oriented Sub-Network Service.
+.ip "CLNS"
+Connectionless Network Service.
+.ip "CLNP"
+Connectionless Network Protocol, or ISO 8473.
+.ip "Network Entity"
+Software or hardware that implements the elements of procedure described
+in ISO 8473.
+.ip "Network Service User"
+Software components that make use of the services provided by a network
+entity.
+.ip "Network Service Provider"
+Software components that provide the services of a network entity.
+.ip "NSAP"
+Network Service Access Point. The point at which the OSI network service
+is made available to the network service user by the network service
+provider.
+.ip "NSAP address"
+Information that the network service provider needs to identify an
+NSAP. The source and destination address fields of a CLNP packet
+are NSAP addresses.
+.ip "ES"
+End system. A system running the complete suite of OSI protocols which can
+act as an end point for communication.
+.ip "IS"
+Intermediate system. A system running the OSI layers 1, 2, and 3 which
+can act only a packet router.
+.ip "SNPA"
+The Subnetwork Point of Attachement is the point where a \fIreal\fR 
+end or intermediate system is attached to a \fIreal\fR subnetwork.
+.ip "SNPA address"
+Information that a \fIreal\fR subnetwork need to identify a \fIreal\fR end 
+or intermediate system. This is commonly referred to as the hardware address.
+.ip "NPDU"
+Network Protocol Data Unit. The unit of data which is exchanged between
+network entities.
+.ip "DT NPDU"
+Normal data NPDU.
+.ip "ER NPDU"
+Error report NPDU.
+.ip "Initial NPDU"
+A NPDU carrying the whole of the user data from an N-UNITDATA request.
+.ip "Derived NPDU"
+a NPDU whose field ar identical to those of an initial NPDU, except that it
+carries only a segment of the user data from an N-UNITDATA request.
+.ip "Segment"
+A distinct unit of data consisting of part or all of the user data provided
+in the N-UNITDATA request and delivered in the N-UNITDATA indication.
+.ip "Segmentation"
+The act of generation two or more derived NPDUs from an initial or derived
+NPDU.
+.ip "Fragment"
+A DoD Internet Protocol term with the same meaning as "segment". Used
+synonymously with "segment."
+.ip "Fragmentation"
+A DoD Internet Protocol term with the same meaning as "segmentation". Used
+synonymously with "segmentation."
+.ip "Reassembly"
+The act of regenerating an initial NPDU from two ore more derived NPDUs.
+.ip "MTU"
+Maximum transmission unit.  The maximum size of a packet that can be
+transmitted on a medium or through a protocol.
+For example, the MTU of the TP protocol is 8192 bytes, the MTU
+of and Ethernet device is 1500 bytes, and the MTU of the OSI Network
+service is 512 bytes.
+.ip "Network interface"
+The device used to attach a computer to a network, for example,
+an Ethernet adapter, or a Token Ring adapter.
+This unfortunate terminology is inherited from BSD Unix.
diff --git a/share/doc/iso/wisc/dogrn b/share/doc/iso/wisc/dogrn
new file mode 100755
index 0000000..83964ae
--- /dev/null
+++ b/share/doc/iso/wisc/dogrn
@@ -0,0 +1,6 @@
+#! /bin/csh -f
+set dev=fa
+foreach m ($argv)
+	echo grn -P$dev $m.grn ">" $m.nr
+	grn -P$dev $m.grn > $m.nr
+end
diff --git a/share/doc/iso/wisc/eicon.nr b/share/doc/iso/wisc/eicon.nr
new file mode 100644
index 0000000..64db4aa
--- /dev/null
+++ b/share/doc/iso/wisc/eicon.nr
@@ -0,0 +1,729 @@
+.sh 2 "X.25 Public Data Network Support"
+.pp
+This ARGO release includes support for an X.25 Public Data Network (PDN)
+in the form of a device driver for the Eicon Technology
+Network Adapter \**.
+.(f
+This adapter, its software, and its documentation are
+available from Eicon Technology Corporation, 3452 Ashby Street, Montreal,
+Quebec, Canada H4R 2C1.
+.)f
+The adapter and its software, together with
+the ARGO \fIecn(4)\fR driver, implement
+the X.25 packet layer protocol as required to support the OSI connection
+oriented network service.
+The remainder of this section of this manual
+destribes the ARGO device driver (hereinafter called "the driver")
+for the Eicon Technology Network Adapter (hereinafter called "the adapter"),
+the interface between the driver
+and the CONS software described above, and the interface
+between the driver and the software on the adapter.
+.sh 3 "Software Modules"
+.lp
+The modules relevant to the design of the driver are listed below.
+.ip "\fICONS -\fR"
+The Connection Oriented Network Service (CONS) provides the upper ISO layers
+with an interface to the PDN. 
+In this release,
+the PDN is 1980 X.25, although support for 1984 X.25 is included.
+CONS can receive requests
+from the CLNP entity and
+from the OSI transport entity.
+In addition, the CONS module 
+supports \fIioctl()\fR commands used by 
+\fIifconfig(8)\fR to configure 
+the X.25 network address and to
+declare the adapter to be up or down. 
+See \fIcons(4p)\fR.
+.ip "\fIDriver -\fR"
+The driver accepts commands from CONS, formats these commands 
+for the adapter, and interprets error indications delivered by the adapter.  
+This driver supports all the UNIX configuration device structures. 
+See \fIecn(4)\fR.
+.ip "\fIEcnconf -\fR"
+\fIEcnconf\fR is a program that allows the privileged user to
+reconfigure
+the options offered by the software on the adapter. 
+\fIEcnconf\fR can be run at any time. 
+See \fIecnconf(8)\fR.
+.ip "\fIEcnload -\fR"
+\fIEcnload\fR is a program that downloads Eicon Technology software
+to the adapter and passes the configuration changes made 
+with the \fIecnconf\fR program to the driver. 
+\fIEcnload must be run only when the X.25 link is considered down\fR.
+See \fIecnload(8)\fR. 
+.ip "\fIEcnstat -\fR"
+\fIEcnstat\fR is a program that
+prints the connection state information and counters kept by
+the adapter and by the driver.
+The statistics include the number of sends and receives,
+active connections, and errors.
+For more information, see \fI ecnstat(8)\fR.
+.ip "\fIAdapter -\fR"
+The adapter's interface to the driver is the Network Control
+Block and Request Vector that exist within the adapter's shared memory (often
+called the "Common Data Area").
+This is described in detail below.
+.sh 3 "Interactions Among the Modules"
+.lp
+The commands
+passed between CONS and the driver can be any one of the \fIECN\fR
+commands outlined in the
+sections "ECN Requests" and "ECN Replies", below.
+CONS uses the \fCecnrestart()\fR procedure for restart requests,
+\fCecnshutdown()\fR procedure for shutdown requests, and 
+\fCecnoutput()\fR procedure for all
+normal data transfer requests. 
+CONS uses the \fCecnioctl()\fR procedure call for
+servicing adapter status requests from the X.25 statistics program \fIecnstat\fR.
+.lp
+Commands passed between the driver and the adapter can
+be any one of the network control block (\fINCB\fR)
+commands described in the section "NCB Commands", below.
+All commands to and from the adapter are
+communicated in the Network Control Block and Request Vector within
+the adapter's Common Data Area.
+.lp
+\fIEcnload\fR starts the 
+Eicon Technology Network Adapter software on the adapter
+and downloads the validated configuration
+to the driver.
+.sh 3 "ECN Requests"
+.lp
+The \fIECN\fR request types that CONS can pass to the driver are listed below.
+.ip "\fIECN_STOP - (by calling ecnshutdown())\fR"
+This request instructs the driver to restart the network but not to listen for 
+any incoming calls. 
+CONS issues this request in response to an \fIioctl()\fR command
+issued by the utility program \fIifconfig\fR, when
+\fIifconfig\fR is used to bring down the adapter.
+.ip "\fIECN_RESTART - (by calling ecnrestart())\fR"
+This request instructs the driver to restart the network \fIand\fR to listen 
+and accept any incoming calls. 
+CONS issues this request in response to an \fIioctl()\fR command
+issued by the utility program \fIifconfig\fR, when
+\fIifconfig\fR is used to bring the adapter up.
+.ip "\fIECN_CALL - 0x90\fR"
+This request instructs the driver to place
+a call request
+to the specified DTE.
+.ip "\fIECN_CLEAR - 0x92\fR"
+This request instructs the driver to clear a given virtual circuit. 
+All outbound data are acknowledged by the remote DTE
+before the circuit is cleared.
+.ip "\fIECN_SEND - 0x94\fR"
+This request instructs the driver to transmit a data buffer across a given 
+virtual circuit.
+.ip "\fIECN_RESET - 0x04\fR"
+This request instructs the driver to reset the given virtual circuit and
+clear out all outstanding requests
+associated with that virtual circuit.
+.ip "\fIECN_STATUS - 0xb4 (exclusively through ecnioctl())\fR"
+This requests instructs the driver to 
+solicit the adapter's current connection state information and
+counters.
+.sh 3 "ECN Replies"
+.lp
+The \fIECN\fR responses
+the driver can give
+to CONS are listed below.
+.ip "\fIECN_CONNECT - 0x01\fR"
+This reply notifies CONS that the driver has established a virtual circuit
+connection initiated by the remote DTE.
+.ip "\fIECN_ACCEPT - 0x03\fR"
+This reply notifies CONS that an ECN_CALL request has succeeded. The
+reply contains a pointer to a protocol control block.
+.ip "\fIECN_REFUSE - 0x02\fR"
+This reply notifies CONS that a previous \fIECN_CALL\fR request has failed.
+The reply contains a pointer to a protocol control block.
+.ip "\fIECN_CLEAR - 0x92\fR"
+This reply notifies CONS that a given virtual circuit has been cleared
+either by the DCE or by the remote DTE.
+.ip "\fIECN_RECEIVE - 0x95\fR"
+This reply notifies CONS that the driver has received a data packet from
+the remote DTE.
+.ip "\fIECN_RESET - 0x04\fR"
+This reply notifies CONS that the virtual circuit has been reset either
+by the DCE or by the remote DTE.
+.ip "\fIECN_ACK - 0x05\fR"
+This reply tells CONS that the associated ECN_SEND request has been been
+completed by the adapter.
+.sh 3 "NCB Commands"
+.lp
+The driver hides from the CONS module
+many of the idiosyncrasies of the adapter's 
+software interface
+by mapping many of the above \fIECN\fR requests into corresponding
+\fINCB\fR commands. Below is a list of requests that the driver can place to
+the adapter. For each request that the driver places to the adapter, the adapter
+returns with a command completion.
+.ip "\fINCB_CALL - 0x90\fR"
+This command creates a virtual circuit. 
+.ip "\fINCB_LISTEN - 0x91\fR"
+This command tells the adapter that our host is
+willing to accept incoming calls. 
+.ip "\fINCB_CLEAR (and NCB_ABORT) - 0x92\fR"
+This command clears a virtual circuit. An option exists to clear the circuit
+immediately, without waiting first for outstanding acknowledgments.
+.ip "\fINCB_SEND (and NCB_RESET) - 0x94\fR"
+This command sends data to the remote DTE. An option is
+available for resetting the
+virtual circuit. This command can return a status indicating that the
+circuit has been cleared by the DCE or the remote DTE.
+.ip "\fINCB_RECEIVE - 0x95\fR"
+This command tells the adapter that our host is
+willing to receive data on a given virtual circuit. This command can return
+received data, a reset circuit, M-, D-, and Q-bits, interrupt packets,
+or a cleared circuit.
+.ip "\fINCB_STATUS - 0xb4\fR"
+This command queries the adapter about 
+the status of a virtual circuit.
+The driver uses this command to support the ECN_STATUS request.
+.ip "\fINCB_RESTART - 0xb2\fR"
+This command restarts the network. This command requires that a corresponding
+configuration file be passed down to the adapter.
+.bp
+.sh 3 "ECN Request and Reply Structure"
+.lp
+Below is
+the data structure used in CONS-driver 
+communications.
+This data structure is a parameter to the 
+\fIecnoutput()\fR procedure.
+\fC
+.nf
+/* Eicon Driver Request Structure -- used between CONS and the driver */
+
+struct eicon_request {
+    struct ecn_ncb  eicon_req_ncb;   /* the network control block       */
+    caddr_t         eicon_req_pcb;   /* CONS pcb used on CALL requests  */
+    int             eicon_req_state; /* used internally by the driver   */
+    int             eicon_retry_cnt; /* used internally by the driver   */
+    int             eicon_more;      /* used internally by the driver   */
+    u_char          eicon_reason;    /* source of CLEAR requests        */
+};
+\fR
+.lp
+The \fCeicon_req_ncb\fR field in the eicon request structure is of
+type \fCecn_ncb\fR, defined in the following section. This structure stores 
+the command block
+that the driver uses in communicating with the adapter. 
+The command block contains a \fIlogical session number\fR (LSN),
+which identifies a virtual circuit.
+Requests such as ECN_CALL are made without an LSN to identify
+a circuit.
+When an LSN is not available, the request is identified by
+the field
+\fCeicon_req_pcb\fR, which is a pointer to a CONS protocol control block. 
+The \fCeicon_req_state\fR field is used by the driver to keep track 
+of the status of the given request. 
+The following list defines the various values for this field:
+.ip "\fIREQ_NEW\fR"
+The driver recognizes a new request, has placed the request into the driver's 
+own request queue, but has yet to interrupt the
+adapter. (The driver maintains a pointer \fCecn_pending_req\fR that indicates
+whether an interrupt to the adapter is outstanding. If one is outstanding, the
+driver places any new requests in this \fIREQ_NEW\fR state. If an interrupt 
+is not
+outstanding, the driver places the request immediately in the 
+\fIREQ_INTERRUPT\fR state defined below.)
+.ip "\fIREQ_INTERRUPT\fR"
+The driver has dequeued the CONS request, assigned \fCecn_pending_req\fR to
+point to the request, and
+interrupted the adapter for a chance to post this request.
+.ip "\fIREQ_POSTED\fR"
+The driver has sent the request to the adapter.
+.ip "\fIREQ_COMPLETE\fR"
+The driver has just completed the request, and if necessary, is now posting 
+it to CONS.
+.lp
+The \fCeicon_retry_cnt\fR field in the eicon request structure keeps track
+of how many times the driver has tried posting this command to the adapter.
+After the second retry, the driver gives up and performs the appropriate
+error routine. 
+The \fCeicon_more\fR field defines a \fIRECEIVE\fR request that
+has been re-posted to the adapter to take care of m-bit transfers.
+The \fCeicon_reason\fR field quantifies the reason for a connection being
+cleared. These reasons are defined in the include file \fCiso_errno.h\fR.
+.lp
+Any data associated with the request are linked to the request through the
+request mbuf's \fCm_next\fR field. 
+This is done so that when
+the driver calls the \fIMFREE_M\fR deallocation routine, both the request 
+and the data are freed together.
+.lp
+The following chart defines those fields within the eicon request structure
+that are relevant in any CONS request
+to the driver via the \fIecnoutput()\fR call. 
+.sp
+.sz 8
+.TS
+center,box,tab(:);
+c s s s s
+c||c s s s
+c||c|c|c|c
+l||l|l|l|l.
+\fBField Definitions for CONS \(-> Driver Requests\fR
+_
+\fI:Request Types (CONS \(-> Driver)\fR
+\fIField:ECN_CALL:ECN_CLEAR:ECN_SEND:ECN_RESET\fR
+=
+\fIncb\(->command\fR:0x90:0x92:0x94:0x04 
+_
+\fIncb\(->loc_ses_num\fR:T{
+.na
+leave as zero
+T}:VC #:VC #:VC #
+_
+\fIncb\(->info\fR:0x0:0x0:0x0:0x2
+_
+\fIeicon_req_pcb\fR:T{
+.na
+address of CONS' protocol control block
+T}:NULL:NULL:NULL
+_
+\fIeicon_req_data\fR:T{
+.na
+address of mbuf containing contents of Call Request packet (including DTE address, facilities, and call user data)
+T}:T{
+.na
+NULL or address of mbuf containing contents of Clear Request packet
+T}:T{
+.na
+address of mbuf containing contents of user data
+T}:T{
+.na
+NULL or the address of mbuf containing a one byte Reset Diagnostic code
+T}
+.TE
+.sz 10
+.sh 3 "Structure of the Network Control Block (NCB)"
+.lp
+The \fCecn_ncb\fR structure is used by the driver to
+make requests of the adapter. 
+\fC
+.nf
+/* Network Control Block -- used between the driver and the Eicon adapter */
+
+struct ecn_ncb {
+    u_char      command;        /* command field                         */
+    u_char      retcode;        /* return code field                     */
+    u_char      lsn;            /* local session number                  */
+    u_char      info;           /* additional information                */
+    caddr_t     buffer;         /* pointer to data buffer's mbuf         */
+    u_short     length;         /* buffer length                         */
+    u_char      callname[16];   /* module name on NA "X25"               */
+    u_char      appl_name[16];  /* application name                      */
+    u_char      rxto;           /* receive timeout in secs               */
+    u_char      txto;           /* send(tx) timeout in secs              */
+    caddr_t     post;           /* NULL                                  */
+    u_char      lana_num;       /* specifies Eicon Tech NA               */
+    u_char      cmd_cplt;       /* command status                        */
+    u_char      reserve[14];    /* reserved area                         */
+};
+\fR
+.sp
+.lp
+The chart below defines those fields that are relevant in any
+reply passed by the driver back up to CONS.
+.sp
+.sz 7
+.TS
+center,box,tab(:);
+c s s s s s s
+c||c s s s s s 
+c||c|c|c|c|c|c
+l||l|l|l|l|l|l.
+\fBField Definitions for Driver \(-> CONS Replies\fR
+_
+\fI:Reply Types (Driver \(-> CONS)\fR
+\fIField:ECN_CONNECT:ECN_ACCEPT:ECN_REFUSE:ECN_CLEAR:ECN_RECEIVE:ECN_RESET\fR
+=
+\fIncb\(->command\fR:0x01:0x03:0x02:0x92:0x95:0x04
+_
+\fIncb\(->loc_ses_num\fR:VC #:VC #:ignore:VC #:VC #:VC #
+_
+\fIncb\(->info\fR:ignore:ignore:ignore:ignore:T{
+.na
+Interrupt received (bit 0), D-bit set (bit 6), and/or Q-bit set (bit 7). Zero
+info field implies a normal receive.
+T}:ignore
+_
+\fIeicon_req_pcb\fR:NULL:T{
+.na
+address of CONS's protocol control block
+T}:T{
+.na
+address of CONS's protocol control block
+T}:ignore:ignore:ignore
+_
+\fIeicon_req_data\fR:T{
+.na
+NULL or address of mbuf containing contents of Call Indication packet 
+T}:T{
+.na
+NULL or address of mbuf containing contents of Call Connected data 
+T}:T{
+.na
+NULL or address of mbuf containing contents of Call Cleared data
+T}:T{
+.na
+NULL or address of mbuf containing contents of Call Cleared data
+T}:T{
+.na
+address of mbuf containing contents of user data
+T}:T{
+.na
+NULL or address of mbuf containing one byte Reset Diagnostic code
+T}
+_
+\fIeicon_reason\fR:ignore:ignore:T{
+.na
+reason for refusal
+T}:T{
+.na
+reason for clear
+.T}:ignore:T{
+.na
+reason for reset
+T}
+.TE
+.sz 10
+.bp
+.sh 3 "Internal Driver Data Sructures"
+.lp
+The main driver data structure
+is the \fIecn_softc\fR structure.
+This structure keeps track of the interface request queue 
+(\fCecn_if\fR and \fCecn_pending_req\fR), 
+magic addresses on the adapter (\fCecn_iom_base, ecn_mem_base,\fR and 
+\fCecn_data_base\fR), 
+error statistics (\fCecn_errors\fR), the state
+of each virtual circuit (\fCecn_vc_state\fR), the state of the \fILISTEN\fR
+request (\fCecn_listen_pending\fR), and the current caller (\fCecn_cause\fR).
+\fC
+.nf
+struct ecn_softc {
+    int             ecn_errors[NCB_MAX][ST_MAX]; 
+    int             ecn_cause[CAUSE_MAX];  /* ecn_work() causes              */
+    struct mbuf     *ecn_pending_req;      /* waiting for command req        */
+    char            ecn_listen_pending;    /* boolean = listen req pending?  */
+    char            ecn_vc_state[LSN_MAX]; /* the current state of each vc   */
+    struct ecn_device      
+                    *ecn_iom_base;         /* base address of io map         */
+    struct ecn_request_vector
+                    *ecn_mem_base;         /* base address of memory map     */
+    caddr_t         ecn_data_base;         /* base address for data area     */
+    struct ifnet    ecn_if;                /* queue of new requests          */
+}
+\fR
+.so figs/ecn_queue.nr
+.sh 2 "Queueing in the Driver"
+.lp
+.CF
+illustrates the queueing mechanism used by the driver.
+.lp
+CONS queues its data transfer requests at the end of the queue managed by
+\fCecn_if\fR field in the \fCecn_softc\fR structure. 
+At this point, each request has the state value of 
+\fIREQ_NEW\fR. 
+Once the driver notifies the adapter that it has a command to post,
+the driver dequeues the first request from the \fCecn_if\fR queue 
+and sets the pointer
+\fCecn_pending_req\fR to point to the request. 
+At this point, the request is in the \fIREQ_INTERRUPT\fR state.
+.lp
+Once the driver posts the request to the adapter, it 
+dequeues the next request in the \fCecn_if\fR queue, reassigns the 
+\fCecn_pending_req\fR pointer, and then indicates to the adapter 
+that it is ready to post another request. 
+The driver no longer has to keep track of the previous request, 
+because for every reply, the adapter includes the associated 
+mbuf pointer. 
+While the request is outstanding, the request is in the \fIREQ_POSTED\fR state.
+.so figs/ecn_vc.nr
+.lp
+After the adapter completes the command, the driver may want to reply to CONS.
+It does this by placing its reply in CONS's \fCconsintrq\fR queue, defined as
+an external \fCifqueue\fR in the driver code.
+.sh 2 "Virtual Circuit States"
+.lp
+The \fCecn_vc_state\fR array in the \fCecn_softc\fR structure above keeps track
+of the state of each virtual circuit (VC).
+This is necessary to avoid handing
+the adapter any commands that may not apply during a given state. 
+This mechanism
+is especially useful in dealing with unexpected aborts or clears where there
+is the potential for all outstanding commands to complete with errors. 
+By changing
+states, the driver can prevent redundant commands (like clears and aborts)
+from being passed either to the adapter or to CONS. 
+.lp
+The driver only keeps track of four different states, as illustrated in 
+.CF
+.
+These states are:
+.ip "\fIVC_NO_CONNECTION\fR"
+When a virtual circuit is in this state, the virtual circuit does not exits.
+Only \fICALL\fR and \fILISTEN\fR commands are valid.
+.ip "\fIVC_DATA_XFER\fR"
+All commands, except \fICALL\fR and \fILISTEN\fR commands are valid once the
+connection exists.
+.ip "\fIVC_RESET_IN_PROGRESS\fR"
+In this state, either the driver has issued an \fINCB_RESET\fR or it has 
+received a reset error code on the completion of a command. 
+Only reissued \fIRESET\fR commands and \fIRECEIVE\fRs are
+valid. 
+\fIRECEIVE\fR is valid in this state because the adapter uses the
+completion of this command to hand back the cause of the reset (the RESET
+INDICATION packet).
+.ip "\fIVC_CLEAR_IN_PROGRESS\fR"
+The driver has either issued an \fINCB_CLEAR\fR command or has just
+received a clear error code on the completion of a command. 
+Within this state, only reissued
+\fICLEAR\fR and \fIABORT\fR commands are valid.
+.sh 2 "Error Statistics"
+.lp
+With the \fCecn_errors\fR field in the \fCecn_softc\fR structure,
+the driver maintains a two dimensional array of counters
+if the frequencies of errors.
+In order to inspect this array easily with
+the kernel debugger, the first index to every command ( <command, 0> ) is
+reserved for a four character ASCII command identifier.
+.bp
+.sh 3 "The Driver State Machine"
+.sh 2 "Handling of Normal Command Completions"
+.lp
+The chart below lists
+all the available adapter request types, at what level each of
+these requests can be used, options, and the driver's action after a normal
+completion of the command.
+.sp
+.sz 7
+.TS
+center,box,tab(:);
+c s s s
+c|c s|c
+c|c|c|c
+l|l|l|l.
+\fBNormal Completion Handling\fR
+_
+\fINCB:Options:Action Based on Normal Competion of\fR
+\fICommand:To Adapter:From Adapter:Driver\(->Adapter Command\fR
+=
+\fINCB_RESTART\fR:none:none:T{
+.na
+dequeue the request, and issue an NCB_LISTEN request to the adapter.
+T}
+_
+\fINCB_CALL\fR:none:connected:T{
+.na
+dequeue the request, pass an ECN_ACCEPT reply to CONS, and issue a RECEIVE to
+the adapter.
+T}
+_
+\fINCB_LISTEN\fR:T{
+.na
+use zero-length Call User Data and a zero-length Calling DTE address
+T}:none:T{
+.na
+dequeue the request, pass an ECN_CONNECT to CONS, and issue a RECEIVE to the
+adapter. Re-issue another NCB_LISTEN
+for another possible virtual circuit connection.
+T}
+_
+\fINCB_CLEAR\fR:T{
+.na
+normal clearing with all outstanding ACKs returned 
+T}:none:T{
+.na
+dequeue the request.
+T}
+:_:_:_
+:T{
+.na
+immediate clearing 
+T}:none:T{
+.na
+dequeue the request.
+T}
+_
+\fINCB_SEND\fR:T{
+.na
+normal send
+T}:none:T{
+.na
+dequeue the request and reply to CONS with an ECN_ACK.
+T}
+:_:_:_
+:T{
+.na
+reset the virtual circuit
+T}:none:T{
+dequeue the request.
+T}
+_
+\fINCB_RECEIVE\fR:none:T{
+.na
+normal, uncomplicated receive
+T}:T{
+.na
+dequeue the request and bcopy the data into the request's associated mbuf. Ship to CONS. Re-issue another NCB_RECEIVE.
+T}
+:_:_:_
+:none:T{
+.na
+m-bit set
+T}:T{
+.na
+same as above (adapter does the resegmentation automatically).
+T}
+:_:_:_
+:none:T{
+.na
+d-bit set
+T}:T{
+.na
+same as above.
+T}
+:_:_:_
+:none:T{
+.na
+q-bit set
+T}:T{
+.na
+same as above.
+T}
+:_:_:_
+:none:T{
+.na
+interrupt received
+T}:T{
+.na
+same as above.
+T}
+:_:_:_
+:none:T{
+.na
+reset received
+T}:T{
+dequeue the request, send an ECN_RESET back up to CONS, and issue another 
+receive.
+T}
+.TE
+.sz 10
+.sp
+.uh "CONS \(-> Driver"
+.lp
+All entries in this column indicate that the CONS module can send this request 
+down to the driver.  Command names in parenthesis define the mapping between
+the \fIECN\fR and \fINCB\fR commands.
+.uh "Driver \(-> Adapter"
+.lp
+All checks in this column indicate that the driver can send this request
+to the adapter. The last column in the above table defines what the driver must
+do upon normal completion of the command from the adapter. 
+Note that not all driver-to-adapter
+commands have a CONS-to-driver equivalent. 
+This shows that this 
+command request is generated within the driver, rather than originating from
+the CONS driver.
+.uh "Driver \(-> CONS"
+.lp
+All entries in this column indicate that the driver can send this reply  
+back to CONS. Command names in parenthesis define  the mapping between 
+the \fIECN\fR and \fINCB\fR commands.
+.bp
+.sh 3 "Handling of Errors upon Command Completion"
+.lp
+Below is listed all the driver request and pseudo request types, along with the
+actions the driver must perform given a command completion error delivered by
+the Eicon Network Adapter.
+.sp
+.sz 7
+.TS
+center,box,tab(:);
+c  s s s s s s s
+c||c s s s s s s
+c||c|c|c|c|c|c|c
+c||c|c|c|c|c|c|c
+l||l|l|l|l|l|l|l.
+\fBError Completion Handling\fR
+_
+:\fIAction Based on Error Completion of Driver \(-> Adapter Command\fR
+\fIError Returned\fR:_:_:_:_:_:_:_
+\fI:NCB_CALL:NCB_LISTEN:NCB_CLEAR:NCB_ABORT:NCB_RESET:NCB_SEND:NCB_RECEIVE\fR
+=
+\fIST_BAD_LEN\fR:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>
+_
+\fIST_INVALID\fR:<soft-error>:<soft-error>:<dequeue>:<dequeue>:<dequeue>:<dequeue>:<dequeue>
+_
+\fIST_COMMAND_TO\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
+_
+\fIST_ISSUE_ANOTHER_RCV\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:T{
+.na
+requeue request and increment "more" count
+T}
+_
+\fIST_BAD_LSN\fR:<soft-error>:<soft-error>:<dequeue>:<dequeue>:<dequeue>:<dequeue>:<dequeue>
+_
+\fIST_NO_RESOURCES\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
+_
+\fIST_CALL_CLEARED\fR:<refuse>:<retry>:<retry>:<retry>:<clear>:<clear>:<clear>
+_
+\fIST_COMMAND_CANCELLED\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>:
+_
+\fIST_NO_CIRCUITS\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
+_
+\fIST_CALL_UNSUCCESSFUL\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
+_
+\fIST_INCORRECT_CALLNAME\fR:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>
+_
+\fIST_X25_RESET\fR:<refuse>:<retry>:<retry>:<retry>:<dequeue>:<dequeue>:<retry>
+_
+\fIST_TOO_MANY_COMMANDS\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
+_
+\fIST_L1_NO_DATA_SET_READY\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
+_
+\fIST_L1_NO_CLEAR_TO_SEND\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
+_
+\fIST_L1_NO_CLOCK\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
+.TE
+.sz 10
+.sp
+.lp
+Each of the actions from the above chart are defined as follows.
+.ip "\fI<abort>\fR -"
+The driver should clear the connection by issuing an \fINCB_ABORT\fR 
+to the adapter and sending an \fIECN_CLEAR\fR to CONS.
+.ip "\fI<refuse>\fR -"
+The driver should send an \fIECN_REFUSE\fR back to CONS.
+.ip "\fI<dequeue>\fR -"
+The driver should simply dequeue the request. Usually these errors occur when a
+reset or clear occurs on the adapter while the driver is in the midst of
+issuing the command which subsequently completes with an error status.
+.ip "\fI<clear>\fR -"
+The driver should send an \fIECN_CLEAR\fR back up to CONS.
+.ip "\fI<retry>\fR -"
+The driver should requeue the request if and only if the 
+\fCecn_retry_cnt\fR field in the request structure does not exceed the
+retry maximum. 
+.ip "\fI<soft-error>\fR -"
+This action only takes place when a software error has occurred. The driver 
+should
+print the error to the console in big bold letters and then panic.
+.bp
+.sh 3 "The IFP Flags"
+.lp
+The IFP flags in the standard \fCifnet\fR structure
+should be used in the following way.
+.ip "\fIIFF_UP on -\fR"
+This flag is set by the driver only after the procedure \fIecnrestart()\fR
+successfully completes.
+.ip "\fIIFF_UP off -\fR"
+This flag is set immediately upon entry into the procedure \fIecnshutdown()\fR.
+.ip "\fIIFF_RUNNING on -\fR"
+This flag is set on whenever the \fIecnwork()\fR procedure is active, eg. the
+driver is actually doing something.
+.ip "\fIIFF_RUNNING off -\fR"
+This flag is turned off upon exit from the \fIecnwork()\fR procedure.
diff --git a/share/doc/iso/wisc/eicon.table5.1.orig.nr b/share/doc/iso/wisc/eicon.table5.1.orig.nr
new file mode 100644
index 0000000..78bda62
--- /dev/null
+++ b/share/doc/iso/wisc/eicon.table5.1.orig.nr
@@ -0,0 +1,126 @@
+.TS
+center,box,tab(:);
+c s s s s s s
+c|c s s|c s|c
+c|c|c|c|c|c|c
+l|c|c|c|l|l|l.
+\fBNormal Completion Handling\fR
+_
+\fINCB:Usage:Options:Action Based on Normal Competion of\fR
+\fICommand:CONS\(->Driver:Driver\(->Board:Driver\(->CONS:To Board:From Board:Driver\(->Board Command\fR
+=
+\fINCB_RESTART\fR:T{
+.na
+(ECN_RESTART) 
+T}:\(sr::none:none:T{
+.na
+dequeue the request, and issue an NCB_LISTEN request to the board.
+T}
+_
+\fINCB_CALL\fR:(ECN_CALL):\(sr:T{
+.na  
+(ECN_ACCEPT) 
+T}:none:connected:T{
+.na
+dequeue the request, pass an ECN_ACCEPT reply to CONS, and issue a RECEIVE to
+the board.
+T}
+_
+\fINCB_LISTEN\fR::\(sr:T{
+.na  
+(ECN_CONNECT)
+T}:T{
+.na
+use zero-length Call User Data and a zero-length Calling DTE address
+T}:none:T{
+.na
+dequeue the request, pass an ECN_CONNECT to CONS, and issue a RECEIVE to the
+board. Re-issue another NCB_LISTEN
+for another possible virtual circuit connection.
+T}
+_
+\fINCB_CLEAR\fR:(ECN_CLEAR):\(sr:(ECN_CLEAR):T{
+.na
+normal clearing with all outstanding ACKs returned 
+T}:none:T{
+.na
+dequeue the request.
+T}
+:_:_:_:_:_:_
+::\(sr::T{
+.na
+immediate clearing 
+T}:none:T{
+.na
+dequeue the request.
+T}
+_
+\fINCB_SEND\fR:(ECN_SEND):\(sr::T{
+.na
+normal send
+T}:none:T{
+.na
+dequeue the request and reply to CONS with an ECN_ACK.
+T}
+:_:_:_:_:_:_
+:T{
+.na  
+(ECN_RESET)
+T}:\(sr::T{
+.na
+reset the virtual circuit
+T}:none:T{
+dequeue the request.
+T}
+_
+\fINCB_RECEIVE\fR::\(sr:(ECN_RECEIVE):none:T{
+.na
+normal, uncomplicated receive
+T}:T{
+.na
+dequeue the request and bcopy the data into the request's associated mbuf. Ship to CONS. Re-issue another NCB_RECEIVE.
+T}
+:_:_:_:_:_:_
+:::(ECN_RECEIVE):none:T{
+.na
+m-bit set
+T}:T{
+.na
+same as above (board does the resegmentation automatically).
+T}
+:_:_:_:_:_:_
+:::(ECN_RECEIVE):none:T{
+.na
+d-bit set
+T}:T{
+.na
+same as above.
+T}
+:_:_:_:_:_:_
+:::(ECN_RECEIVE):none:T{
+.na
+q-bit set
+T}:T{
+.na
+same as above.
+T}
+:_:_:_:_:_:_
+:::(ECN_RECEIVE):none:T{
+.na
+interrupt received
+T}:T{
+.na
+same as above.
+T}
+:_:_:_:_:_:_
+:::T{
+.na   
+(ECN_RESET)
+T}:none:T{
+.na
+reset received
+T}:T{
+dequeue the request, send an ECN_RESET back up to CONS, and issue another 
+receive.
+T}
+.TE
diff --git a/share/doc/iso/wisc/errors.nr b/share/doc/iso/wisc/errors.nr
new file mode 100644
index 0000000..51b5eb5
--- /dev/null
+++ b/share/doc/iso/wisc/errors.nr
@@ -0,0 +1,363 @@
+.\"$Header: errors.nr,v 1.2 88/12/06 16:06:07 nhall Exp $
+.\"$Source: /usr/argo/doc/kernel/RCS/errors.nr,v $
+.NC "Error Handling"
+This section describes the various ways that the ARGO kernel 
+handles errors.
+For the purpose of this description,
+errors are divided into
+three classes : user errors, remote-end errors, and internal errors.
+These three classes of errors and the way 
+the ARGO kernel handles them are described below.
+.sh 1 "Network Layer Errors"
+.pp
+The following section describes how errors are handled by CLNP.
+.sh 2 "User Errors"
+.pp
+User errors occur when attempting to send a CLNP packet. These errors
+are reflected back to the caller of \fIclnp_output()\fR as the return value
+of the function. The following table indicates the types of errors possible
+and their associated return codes:
+.(b L
+.TS
+tab(+), expand box;
+l l.
+Problem+Return Code
+=
+Unsupported option selected+EINVAL
+Incorrect address+ENAMETOOLONG
+Insufficient \fImbufs\fR+ENOBUFS
+Can't route packet+ENETUNREACH,EHOSTUNREACH
+Insufficient \fImbufs\fR+ENOBUFS
+.TE
+.)b
+.sh 2 "Remote-end Errors"
+.pp
+An error that occurs as the result of incoming NPDU
+is a remote-end error.  
+.pp
+In the case of CONS, 
+the majority of these are addressing problems,
+PDN-generated errors (network or gateway congestion, number busy),
+or higher layer negotiation problems.
+All ISO 8208 diagnostic codes that may appear in a call clearing packet
+are passed up to the higher layer.
+Some of the higher layer protocols pass this error indication to the
+user level program as well.
+The CONS statistics that are maintained by the "glue" module
+include counters for each of the possible
+ISO 8208 diagnostic codes seen on incoming packets.
+In addition to these error codes, there are some codes that may appear
+due to device driver problems when an NPDU arrives, for example,
+the driver may run out of buffers.
+All possible errors that may occur in the CONS module are listed
+in the file
+\fC<netargo/iso_errno.h>\fR,
+and the values listed in this file are passed to the user level
+program in the global integer variable \fIerrno\fR.
+The ARGO library
+\fClibisodir.a\fR
+includes an expanded version of
+\fIperror()\fR that interprets these extra values.
+.pp
+In the case of CLNP,
+the most remote-end errors are parsing errors.
+When a remote-end error is discovered, processing of the NPDU stops. The
+NPDU is discarded, and if error reporting is not disabled, and ER NPDU
+is sent back to the source of the offending packet. The following
+tables show the errors that may occur, and the error reason 
+that will specified when the ER NPDU is returned.
+.pp
+The following general errors may occur while parsing an NPDU:
+.(b L
+.TS
+tab(+), box, expand;
+l l.
+Problem+Error Reason
+=
+NPDU arrives before interface is configured+ADDR_DESTUNREACH
+Packet too short or too big+GEN_INCOMPLETE
+Protocol identification wrong+GEN_HDRSYNTAX
+Version wrong+DISC_UNSUPPVERS
+Lifetime expired+TTL_EXPTRANSIT
+Incorrect checksum+GEN_BADCSUM
+Address section too short+GEN_INCOMPLETE
+Segment section too short+GEN_INCOMPLETE
+Options section too short+GEN_INCOMPLETE
+Unknown packet type+GEN_HDRSYNTAX
+Can't route packet (forwarding)+ADDR_DESTUNREACH
+.TE
+.)b
+The following errors are related to options processing:
+.(b L
+.TS
+tab(+), box, expand;
+l l.
+Problem+Error Reason
+=
+Duplicate option+GEN_DUPOPT
+Unknown option+DISC_UNSUPPTOPT
+Security format bad+GEN_HDRSYNTAX
+Security option present+DISC_UNSUPPSECURE
+Source route format bad+SRCRT_SYNTAX
+Record route too short+GEN_INCOMPLETE
+Record route format bad+GEN_HDRSYNTAX
+QOS format bad+GEN_HDRSYNTAX
+Priority format bad+GEN_HDRSYNTAX
+Error reason format bad+GEN_HDRSYNTAX
+Error reason on non-ER NPDU+DISC_UNSUPPOPT
+Error reason absent from ER NPDU+GEN_HDRSYNTAX
+.TE
+.)b
+.sh 2 "Internal Errors"
+.pp
+Internal errors occur as a result of a programmer error. These errors
+will result in a kernel \fIpanic()\fR. The following panics have been
+coded into CLNP:
+.(b L
+.TS
+tab(+), box, expand;
+l l.
+\fIPanic()\fR message+Reason
+=
+clnp_init: no raw clnp+The raw clnp protocol is not
++configured into the kernel.
+_
+clnp_srcaddr: ifp does not match interface+The ifp
++passed to \fIclnp_srcaddr()\fR is invalid.
+.TE
+.)b
+.sh 1 "Transport Layer Errors"
+.pp
+.sh 2 "User Errors"
+.pp
+TP handles these errors in the "standard"
+way for 4.3BSD:
+it causes an E\fIxxx\fR error constant (from the
+list in /sys/h/errno.h)
+to be put into the user program's
+global variable \fIerrno\fR.
+In most routines, in particular
+those routines called directly or indirectly
+the by system-call routines,
+this is done
+by simply returning
+this integer value. 
+The errors that fall into this category are described
+in the following table:
+.(b L
+.TS
+expand box tab(+);
+l l.
+Error+Meaning
+=
+EAFNOSUPPORT+Attempting to use an address family
+ +other than AF_ISO and AF_INET.
+_
+ENOPROTOOPT+TP was not configured at boot time.
+_
+ESOCKTNOSUPPORT+The given socket type is not supported.
+_
+EPROTOTYPE+Attempting to use an inappropriate transport
+ +class for the network service. (e.g. class 0 over CLNS)
+ +or attempting to use an unknown network service.
+_
+EISCONN+Attempting to perform on a connected socket an action 
+ +that is permitted only on unconnected sockets.
+_
+ENOTCONN+Attempting to perform on an unconnected socket an
+ +action that is permitted only on connected sockets.
+_
+EMSGSIZE+Trying to send more data than are permitted on 
+ +connect, disconnect, or expedited data PDUs.
+_
+ENOTSOCK+The integer argument passed in the system
+ +call is not a socket descriptor or is a socket but
+ +has no transport pcb.
+_
+EINVAL+Some argument to the system call is invalid.
+_
+EOPNOTSUPP+Some command argument to the system call is invalid
+ +or the operation is not supported.
+_
+EACCES+An unprivileged user tried to use a privileged command.
+_
+ETOOMANYREFS+TP ran out of reference blocks.
+_
+ENOBUFS+TP ran out of memory (mbufs).
+.TE
+.)b
+Errors that should be reported to the user
+by \fIerrno\fR but which occur asynchronously
+are detected by the socket layer when the value
+of the field \fIso_error\fR in the socket
+structure is non-zero.
+This is used to report such errors as 
+ECONNRESET,
+ECONNABORTED, and
+ECONNTIMEDOUT, which are really remote-end errors.
+.sh 2 "Remote-end Errors"
+.pp
+An error that occurs is the result of a timer
+or is a result of an 
+incoming TPDU
+is a remote-end error.
+The majority of these errors are parsing errors.
+They also include some protocol errors.
+Some of these errors cause the connection to be
+closed locally.
+It is unfortunate that when a connection is closed,
+the kernel will not permit the user program to perform
+anything on the socket in question, so the user cannot
+inquire about the reason for disconnection.
+There is no clean way to pass this information to a
+signal handler either, since the process being signalled
+may be swapped out at the time.
+Some of these errors cause TP to return an ER TPDU
+or a DR TPDU to the sending site.
+Some have no effect on the connection locally.
+These errors and their effects are described below.
+.(b L
+.TS
+expand box tab(+);
+l l l.
+Error+Meaning+Return code or action taken
+=
+Retransmission+The remote end has not responded +ETIMEDOUT
+timeout+to repeated attempts to send.+ 
+ +This can occur during connection+ 
+ +or after connection establishment.+ 
+_
+Inactivity+The remote end has not sent anything +ETIMEDOUT
+timeout+within the last \fIx\fR time, where+
++\fIx\fR is a locally defined+
++large value.+ 
+_
+Unacceptable+An unacceptable TPDU has arrived, and the+TPDU dropped
+TPDU +remote end can be identified.+possibly DR/ER returned
+_
+DR TPDU+A DR TPDU arrived, with any+Disconnect indication,
+arrived+value in the reason field.+so_error == ECONNRESET
+_
+ER TPDU+An ER TPDU arrived, with any+Disconnect indication,
+arrived+anything in the reason field.+so_error == ECONNABORTED
+.TE
+.)b
+TPDUs may be unacceptable for a variety of reasons:
+.(b L
+.TS
+expand box tab(+);
+l l.
+Problem+Action taken by TP
+=
+No connection at destination+Respond with DR, reason: session entity
+reference or reference frozen+not attached to TSAP
+_
+Invalid destination reference+Respond with DR, reason: mismatched 
++references
+_
+Invalid parameter code+Respond with ER, cause: inval. param. code
+_
+Invalid DU type+Respond with ER, cause: invalid TPDU type
+_
+Invalid version number+ Respond with ER, cause: inval. param. code
+_
+Invalid suffix value+Respond with ER, cause: inval. param. value
+_
+Suffix missing or is of+Respond with DR, reason:
+invalid length+header or parameter length invalid
+_
+Invalid checksum+packet discarded
+_
+Can't find a connection+Respond with DR, reason:
+for (dest ref, src ref) pair+mismatched references
+_
+Old ACK TPDU+packet discarded, possibly send ACK w/ FCC
+_
+Class requested isn't supported+Respond with DR, reason: +negotiation failed
+_
+Invalid TPDU size parameter+Respond with ER, cause: inval. param. value
+_
+Illegal amount of data+Respond with DR, reason:
+on CR, CC, DR, or XPD+header or parameter length invalid
+_
+Header length and length+Respond with DR, reason:
+indicator field of TPDU don't agree+header or parameter length invalid
+.TE
+.)b
+.lp
+The file \fC<argo/iso_errno.h>\fR is a list
+of the error codes and diagnostic that can be returned
+from the peer transport entity in a DR TPDU or an ER TPDU,
+and those that can be returned from the CONS, initiated by the DCE,
+the remote DTE, or by the local network adapter.
+These error values are too numerous to list here.
+Most of them are taken from the ISO 8208 standard and the ISO 8073 standard.
+The ARGO distribution contains an expanded form of the BSD library
+routine \fIperror()\fR that prints an error messages for a given
+\fIerrno\fR value.
+.sh 2 "Internal Errors"
+.pp
+Some internal errors are the result of 
+a lack of resources such as buffers.
+These are reported to the user with the
+global variable
+\fIerrno\fR
+set to a value from
+\fC<errno.h>\fR.
+The errors that fall into this category are described
+in the following table:
+.(b L
+.TS
+expand box tab(+);
+l l.
+Return code+Problem
+=
+ENOBUFS+TP ran out of mbufs.
+_
+EPROTONOOPT+TP hasn't been configured.
+_
+ETOOMANYREFS+TP ran out of (unfrozen) reference numbers.
+.TE
+.)b
+.pp
+Other
+internal errors are coding errors
+or errors of misinterpretation of a specification.
+They result in the printing of a message on the 
+console followed by a system panic.
+The following panics have been coded into TP:
+.(b L
+.TS
+expand box tab(+);
+l l.
+\fIPanic()\fR message+Problem
+=
+tp_emit CR/CC+The length indicator field of a TPDU is longer than the
+ +amount of space in an mbuf; TP is attempting to send a
+ +CR TPDU that is too large (perhaps legal but too large for 
+ +this implementation to manage).
+_
+tp_rcvoob: unexpected cluster+An incoming XPD TPDU was put into a cluster 
+ +mbuf by a lower layer.
+_
+tp timeout table overflow+The system ran out of structures for TP timers.
+_
+tp: T_DETACH+The connected socket that is being detached has 
+ +no parent socket.
+_
+tp_soisdisconnected+The socket head queue is 
+ +corrupted.
+_
+tp_soisdisconnecting+The socket head queue is 
+ +corrupted.
+_
+tpclnp_input: bad clnp_len +The length parameter passed by clnp
+ +is bad.
+_
+iso_control: SIOCDIFADDR+ioctl() system call passed down
+iso_control: SIOCSIFADDR+a null interface pointer
+_
+sofree dq+The list of socket structures is
+ +is inconsistent.
+.TE
+.)b
diff --git a/share/doc/iso/wisc/esis_design.nr b/share/doc/iso/wisc/esis_design.nr
new file mode 100644
index 0000000..437f3ee
--- /dev/null
+++ b/share/doc/iso/wisc/esis_design.nr
@@ -0,0 +1,114 @@
+.NC "The Design of the ARGO Network Layer"
+.sh 1 "End System to Intermediate System Routing Protocol"
+.pp
+The following sections describe the design of the End System to Intermediate
+System (ES-IS) Routing Exchange Protocol.
+.sh 2 "Overview"
+.nf
+- protocol involves sending/receiving hello pdus.
+- timers determine
+	- when to send information
+	- when to discard information
+- want to keep as much of the work outside of kernel
+- only put functions and tables in kernel when necessary
+.sh 2 "Supported Features (brief overview of each)"
+- report configuration (both ES and IS)
+- record configuration (both ES and IS)
+- flush configuration (both ES and IS)
+- query configuration (ES only)
+- configuration response (ES only)
+- request redirect (IS only)
+- record redirect (ES only)
+- flush old redirect (ES only)
+- multicast vs. broadcast (using broadcast only)
+.sh 2 "Kernel Resident Features"
+.sh 3 "Support for PDU Transmission"
+- need mechanism to send/receive PDUs
+- utilize ES-IS socket (like raw socket)
+- socket(AF_ISO, SOCK_DGRAM, ISOPROTO_ESIS)
+.sh 4 "Sending PDUs"
+- sendmsg() used for transmitting PDUS
+- data will be pre-formed ES-IS PDU
+- no checks will be made on the pdu format
+- addr_snpa is the destination (to)
+- before sending, socket must be associated with a particular interface
+	this is done via setsockopt():
+		ESISOPT_SETIF - option
+		buffer is name of interface, ie. "un0"
+.sh 4 "Receiving PDUs"
+- recvmsg() used for receiving PDUs
+- data will be:
+	#define	ESIS_PDU
+	#define ESIS_CONFIG_RESP
+	#define ESIS_REDIR_REQ
+	struct esis_indication {
+		short	ei_type;		/* type of indication */
+		union {
+			struct ? config_resp
+			struct ? redir_req
+			char	 pdu[0]
+		} ei_u;
+	}
+- no checks will be made on the pdu format
+- addr_snpa is the source (from)
+.sh 4 "Addressing"
+- ES-IS PDUs are sent to SNPA.
+- addresses used are SN addresses, not NSAP addresses
+- format of msg_name (part of msghdr) struct sockaddr_iso
+	afi = 0	/* means special snpa address */
+	isoa_u is struct addr_snpa
+		struct addr_snpa {
+			char	sn_addr[7];	/* snpa addr */
+		}
+	isoa_len is number of bytes of sn_addr that are valid
+
+- sn_addr may be a unicast or multicast address
+- multicast addresses will be faked via broadcast addresses
+.sh 3 "NSAP to SNPA translation"
+- translation from NSAP to SNAP required for every CLNP PDU sent
+- function provided by iso_nsap_to_snpa
+
+	iso_nsap_to_snpa(ifp, m, nsap, snpa)
+	struct ifnet		*ifp;	/* outgoing interface */
+	struct mbuf			*m;		/* pkt */
+	struct sockaddr_iso	*nsap;	/* destination address */
+	char				*snpa;	/* RESULT: snpa address */
+	{
+		if (nsap.afi == AFI_SNPAADDR) {
+			copy snpa addr from nsap into snpa
+			return SUCCESS
+		} else {
+			scan RIB for (RIB.nsap == nsap)
+			if (found) {
+				copy RIB.snpa into snpa
+				return SUCCESS
+			}
+			scan RIB for (RIB.type == IS) && (RIB.ifp = ifp)
+			if (found) {
+				copy RIB.snpa into snpa
+				return SUCCESS
+			}
+			if (ifp allows multicast) {
+				/* invoke query configuration function */
+				copy ifp.ifaddr.ifa_all_es into snpa
+				return SUCCESS
+			}
+
+			return FAILURE
+		}
+	}
+
+- NSAP to SNPA table resides in kernel so CLNP has quick access
+- entries added/timed-out of table via user level ES-IS daemon
+.sh 3 "Query Configuration Functon"
+- invoked when iso_nsap_to_snpa
+	- requires snpa, but
+	- does not find a match for dest nsap, and
+	- does not find a match for Any IS.
+- clnp packet is sent to address "all ES" as specified in ifnet structure
+	(for now, this is just the broadcast address)
+.sh 3 "Configuration Response Function"
+- invoked by clnp_input(), after determining that the packet received is
+	destined for one of its NSAPs
+- checks if sn_dst == "all ES" (for now, this is all hex ffs)
+- if true, a copy of packet is made, and passed up to esis_input()
diff --git a/share/doc/iso/wisc/figs/CONS_primitives.nr b/share/doc/iso/wisc/figs/CONS_primitives.nr
new file mode 100644
index 0000000..16dc3e0
--- /dev/null
+++ b/share/doc/iso/wisc/figs/CONS_primitives.nr
@@ -0,0 +1,77 @@
+.(b
+.TS
+tab(+) center expand box;
+c c 
+a | a .
+service primitive & arguments+provided by
+=
+N_CONNECT.request+cons_openvc(... faddr, ...)
+called address+argument faddr
+calling address+not implemented
+receipt confirmation+not implemented
+expedited data+not implemented
+quality of service+not implemented
+NS-user data+not implemented
+_
+N_CONNECT.indication+not implemented
+_
+N_CONNECT.response+cons_netcmd( CONN_REFUSE )
++ or cons_netcmd( CONN_CONFIRM )
++ however, net connection has already
++ been accepted.  If REFUSE, it will
++ be cleared with E_CO_HLI_REJT
++ (higher layer rejects connection)
+responding address+not implemented
+receipt confirmation+not implemented
+expedited data+not implemented
+quality of service+not implemented
+NS-user data+not implemented
+_
+N_CONNECT.confirm+not implemented
+=
+N_DATA.request+cons_output(... m, ...) 
++and cosns_output(... m, ...)
+confirmation+not implemented
+data+mbuf chain m
+_
+N_DATA.indication+pr_input( m, ... )
++or software interrupt
+confirmation+not implemented
+data+mbuf chain
+_
+N_DATA_ACKNOWLEDGE.request+not implemented
+_
+N_DATA_ACKNOWLEDGE.indication+not implemented
+_
+N_EXPEDITED_DATA.request+not implemented
+_
+N_EXPEDITED_DATA.indication+not implemented
+=
+N_RESET.request+not implemented
+N_RESET.indication+socket->so_error = reason
++or pr_ctlinput( PRC_ROUTEDEAD )
+originator+not implemented
+reason+from X.25 packet or ecn driver
+N_RESET.response+not implemented
+N_RESET.confirm+not implemented
+=
+N_DISCONNECT.request+cons_netcmd( CONN_CLOSE )
+reason+uses E_CO_HLI_DISCN (normal 
++disconnect from higher layer)
+responding address+not implemented
+NS_user data+not implemented
+_
+N_DISCONNECT.indication+socket->so_error = reason
++or pr_ctlinput( PRC_ROUTEDEAD )
+originator+not implemented
+reason+from X.25 packet or ecn driver
+responding address+not implemented
+NS_user data+not implemented
+.TE
+.(c
+\fBFigure \n+(FG\fR: Transport Service Primitives
+.)c
+.)b
+.(f
+\** data on disconnect is not supported at this time.
+.)f
diff --git a/share/doc/iso/wisc/figs/Makefile b/share/doc/iso/wisc/figs/Makefile
new file mode 100644
index 0000000..72aa29a
--- /dev/null
+++ b/share/doc/iso/wisc/figs/Makefile
@@ -0,0 +1,18 @@
+#
+#
+.SUFFIXES: .nr .grn
+
+PRINTER = ba
+
+ALL = \
+	func_units.nr unix_ipc.nr osi_addr.nr trans_flow.nr clnp_output.nr\
+	clnp_input.nr mbufsnd.nr mbufrcv.nr\
+	ecn_vc.nr ecn_network.nr ecn_queue.nr tppt.nr
+
+all: $(ALL)
+
+clean:
+	rm  $(ALL)
+
+.grn.nr:
+	grn -P$(PRINTER) $*.grn > $*.nr
diff --git a/share/doc/iso/wisc/figs/NS_primitives.nr b/share/doc/iso/wisc/figs/NS_primitives.nr
new file mode 100644
index 0000000..20dc226
--- /dev/null
+++ b/share/doc/iso/wisc/figs/NS_primitives.nr
@@ -0,0 +1,69 @@
+.(b
+.TS
+tab(+) center box;
+c c 
+a | a .
+service primitive & arguments+kernel procedure call & arguments
+=
+N_CONNECT.request+\fIcons_openvc(copcb,dstaddr,so)\fR
+called address+argument \fIdstaddr\fR
+calling address, expedited data selection+not implemented
+receipt confirmation selection+not implemented
+quality of service, NS-user data+not implemented
+_
+N_CONNECT.indication+not implemented
+_
+N_CONNECT.response+not implemented
+_
+N_CONNECT.confirm+return from \fIcons_openvc()\fR
+responding address, quality of service+not implemented
+receipt confirmation selection+not implemented
+expedited data selection, NS-user data+not implemented
+=
+N_DATA.request+\fIcons_output(isop,m,len,isdgm)\fR, and
+ +\fIcosns_output(ifp,m,dstaddr)\fR
+NS-user data+argument m (mbuf chain)
+confirmation request+not implemented
+_
+N_DATA.indication+software interrupt (CLNP), procedure
++call to \fItp_input()\fR
+NS-user data+mbuf chain on \fIclnlintrq\fR or
++argument to \fItp_input()\fR
+confirmation request+not implemented
+=
+N_DATA_ACKNOWLEDGE.request+not implemented
+_
+N_DATA_ACKNOWLEDGE.indication+not implemented
+=
+N_EXPEDITED_DATA.request+not implemented
+_
+N_EXPEDITED_DATA.indication+not implemented
+=
+N_RESET.request+not implemented
+_
+N_RESET.response+not implemented
+_
+N_RESET.indication+higher layer \fIpr_ctlinput(
++PRC_ROUTEDEAD, faddr, copcb)\fR
+originator+argument \fIfaddr\fR
+reason+implemented with so->so_errno for sockets
++that are attached to CONS PCBs
+_
+N_RESET.confirm+not implemented
+=
+N_DISCONNECT.request+\fIcons_netcmd(CONN_CLOSE,
++isop, channel, isdgm)\fR
+reason, NS-user data, responding address+not implemented
+_
+N_DISCONNECT.indication+higher layer \fIpr_ctlinput(
++PRC_ROUTEDEAD, faddr, copcb)\fR
+originator+argument \fIfaddr\fR
+reason+implemented with so->so_errno for sockets
++that are attached to CONS PCBs
+NS-user data, responding address+not implemented
+.TE
+.(c
+\fBFigure \n+(FG\fR: Network Service Primitives
+.\")
+.)c
+.)b
diff --git a/share/doc/iso/wisc/figs/TS_primitives.nr b/share/doc/iso/wisc/figs/TS_primitives.nr
new file mode 100644
index 0000000..3d27df3
--- /dev/null
+++ b/share/doc/iso/wisc/figs/TS_primitives.nr
@@ -0,0 +1,60 @@
+.(b
+.TS
+center expand box;
+c c 
+a | a .
+service primitive & arguments	Unix system calls & arguments
+=
+T_CONNECT.request	\fIsocket(), connect(), setsockopt()\fR
+called address	\fIconnect()\fR argument
+calling address	\fIconnect()\fR argument
+quality of service	not implemented
+buffer management	\fIsetsockopt()\fR argument 
+security	not implemented
+data	\fIsetsockopt(), getsockopt()\fR
+_
+T_CONNECT.indication	return from \fIaccept(); getsockopt()\fR
+called address	\fIaccept()\fR argument
+calling address	\fIaccept()\fR argument
+quality of service	not implemented
+security	not implemented
+data	\fIsetsockopt(), getsockopt()\fR
+_
+T_CONNECT.response	no applicable system calls
+_
+T_CONNECT.confirm	return from \fIconnect()\fR
+quality of service	\fIgetsockopt()\fR argument
+data	\fIsetsocktopt, getsockopt()\fR
+=
+T_DATA.request	\fIrecvv(), sendv()\fR
+_
+T_DATA.indication	return from \fIrecvv()\fR, \fIsendv()\fR, or \fIselect()\fR; 
+	or signal SIGIO 
+	ioctl(FIONREAD) tells how much has been
+	queued to read
+=
+T_EXPEDITED_DATA.request	\fIsendv()\fR with MSG_OOB flag
+_
+T_EXPEDITED_DATA.indication	SIGURG, \fIgetsockopt()\fR with TPFLAG_XPD,
+	return from \fIselect()\fR with exceptional 
+	conditions mask
+=
+T_DISCONNECT.request	\fIclose()\fR
+data	\fIsetsockopt()\fR
+_
+T_DISCONNECT.indication	SIGURG, 
+	error return on other primitives
+reason	 errno
+data	\fIgetsockopt()\**\fR
+=
+T_STATUS.request	\fIgetsockopt()\fR, \fItpstat\fR utility program
+_
+T_STATUS.indication	\fIgetsockopt()\fR, \fIselect()\fR, \fItpstat\fR 
+.TE
+.(c
+\fBFigure \n+(FG\fR: Transport Service Primitives
+.)c
+.)b
+.(f
+\** data on disconnect is not supported at this time.
+.)f
diff --git a/share/doc/iso/wisc/figs/addrfmt.nr b/share/doc/iso/wisc/figs/addrfmt.nr
new file mode 100644
index 0000000..195a46e
--- /dev/null
+++ b/share/doc/iso/wisc/figs/addrfmt.nr
@@ -0,0 +1,22 @@
+.TS
+center,expand,box,tab(+);
+c s|c
+c|c|c.
+T{
+.na
+IDP: initial domain part
+T}+T{
+.na
+DSP: domain spedific part
+T}
+_+_+
+T{
+.na
+AFI: authority and format identifier
+T}+T{
+.na
+IDI: initial domain identifier
+T}+
+.TE
+.ce
+\fB Figure \n+(FG\fR: Format of OSI addresses
diff --git a/share/doc/iso/wisc/figs/clnp_input.grn b/share/doc/iso/wisc/figs/clnp_input.grn
new file mode 100644
index 0000000..f217b94
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_input.grn
@@ -0,0 +1,18 @@
+.(z
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.4
+narrow 1
+medium 3
+thick 7
+pointscale off
+file clnp_input.gsrc
+.GE
+.ce
+\fB Figure \n+(FG:\fR Flow of control for processing CLNP NPDUs
+.)z
diff --git a/share/doc/iso/wisc/figs/clnp_input.gsrc b/share/doc/iso/wisc/figs/clnp_input.gsrc
new file mode 100644
index 0000000..0c0852e
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_input.gsrc
@@ -0,0 +1,338 @@
+gremlinfile
+0 424.00 24.00
+3
+424.00 696.00
+424.00 704.00
+-1.00 -1.00
+5 0
+0 
+ 3
+312.00 416.00
+560.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 696.00
+125.00 701.00
+128.00 699.00
+131.00 701.00
+128.00 696.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 264.00
+560.00 264.00
+560.00 704.00
+128.00 704.00
+128.00 696.00
+-1.00 -1.00
+5 0
+0 
+ 3
+424.00 648.00
+427.00 643.00
+424.00 645.00
+421.00 643.00
+424.00 648.00
+-1.00 -1.00
+4 0
+0 
+ 3
+232.00 672.00
+288.00 672.00
+288.00 632.00
+424.00 632.00
+-1.00 -1.00
+4 0
+0 
+ 3
+232.00 608.00
+424.00 608.00
+-1.00 -1.00
+4 0
+0 
+ 3
+232.00 544.00
+424.00 544.00
+-1.00 -1.00
+4 0
+0 
+ 3
+232.00 480.00
+424.00 480.00
+-1.00 -1.00
+4 0
+0 
+ 3
+232.00 352.00
+424.00 352.00
+424.00 648.00
+-1.00 -1.00
+4 0
+0 
+ 3
+351.00 689.00
+351.00 656.00
+528.00 656.00
+528.00 689.00
+351.00 689.00
+-1.00 -1.00
+5 0
+0 
+ 0
+360.00 664.00
+360.00 679.00
+360.00 679.00
+360.00 679.00
+-1.00 -1.00
+1 2
+14 Discard Packet
+ 3
+136.00 320.00
+141.00 323.00
+139.00 320.00
+141.00 317.00
+136.00 320.00
+-1.00 -1.00
+5 0
+0 
+ 3
+136.00 384.00
+240.00 384.00
+240.00 320.00
+136.00 320.00
+-1.00 -1.00
+5 0
+0 
+ 0
+56.00 280.00
+56.00 295.00
+56.00 295.00
+56.00 295.00
+-1.00 -1.00
+1 2
+12 Process NPDU
+ 3
+48.00 304.00
+48.00 271.00
+225.00 271.00
+225.00 304.00
+48.00 304.00
+-1.00 -1.00
+5 0
+0 
+ 0
+56.00 600.00
+56.00 615.00
+56.00 615.00
+56.00 615.00
+-1.00 -1.00
+1 2
+18 Consistency Checks
+ 3
+47.00 498.00
+47.00 465.00
+224.00 465.00
+224.00 498.00
+47.00 498.00
+-1.00 -1.00
+5 0
+0 
+ 0
+56.00 344.00
+56.00 359.00
+56.00 359.00
+56.00 359.00
+-1.00 -1.00
+1 2
+20 Reassemble Fragments
+ 3
+168.00 432.00
+168.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 432.00
+48.00 400.00
+304.00 400.00
+304.00 432.00
+48.00 432.00
+-1.00 -1.00
+5 0
+0 
+ 0
+200.00 408.00
+200.00 423.00
+200.00 423.00
+200.00 423.00
+-1.00 -1.00
+1 2
+12 Forward NPDU
+ 0
+56.00 408.00
+56.00 423.00
+56.00 423.00
+56.00 423.00
+-1.00 -1.00
+1 2
+9 Keep NPDU
+ 0
+56.00 472.00
+56.00 487.00
+56.00 487.00
+56.00 487.00
+-1.00 -1.00
+1 2
+15 Process Options
+ 0
+56.00 536.00
+56.00 551.00
+56.00 551.00
+56.00 551.00
+-1.00 -1.00
+1 2
+19 Extract Information
+ 0
+56.00 664.00
+56.00 679.00
+56.00 679.00
+56.00 679.00
+-1.00 -1.00
+1 2
+14 Dequeue Packet
+ 3
+131.00 311.00
+128.00 316.00
+131.00 314.00
+134.00 316.00
+131.00 311.00
+-1.00 -1.00
+5 0
+0 
+ 3
+131.00 329.00
+131.00 310.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 332.00
+130.00 332.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 373.00
+127.00 378.00
+130.00 376.00
+133.00 378.00
+130.00 373.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 394.00
+130.00 373.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 460.00
+130.00 439.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 439.00
+127.00 444.00
+130.00 442.00
+133.00 444.00
+130.00 439.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 501.00
+127.00 506.00
+130.00 504.00
+133.00 506.00
+130.00 501.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 522.00
+130.00 501.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 588.00
+128.00 567.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 567.00
+125.00 572.00
+128.00 570.00
+131.00 572.00
+128.00 567.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 631.00
+125.00 636.00
+128.00 634.00
+131.00 636.00
+128.00 631.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 652.00
+128.00 631.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 368.00
+48.00 335.00
+225.00 335.00
+225.00 368.00
+48.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 562.00
+47.00 529.00
+224.00 529.00
+224.00 562.00
+47.00 562.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 626.00
+47.00 593.00
+224.00 593.00
+224.00 626.00
+47.00 626.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 689.00
+47.00 656.00
+224.00 656.00
+224.00 689.00
+47.00 689.00
+-1.00 -1.00
+5 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/clnp_input.nr b/share/doc/iso/wisc/figs/clnp_input.nr
new file mode 100644
index 0000000..01f6468
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_input.nr
@@ -0,0 +1,188 @@
+.(z
+.br
+.nr g1 3456u
+.nr g2 2964u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D't 1u'
+.sp -1
+.sp 101u
+\D'l 0u 223u'\D'l 1193u 0u'\D'l 0u -223u'\D'l -1193u 0u'
+.sp -1
+.sp 425u
+\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
+.sp -1
+.sp 431u
+\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
+.sp -1
+.sp 1306u
+\h'7u'\D'l 0u 222u'\D'l 1192u 0u'\D'l 0u -222u'\D'l -1192u 0u'
+.sp -1
+.sp -1912u
+\h'546u'\D'l 0u 141u'
+.sp -1
+.sp 141u
+\h'546u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
+.sp -1
+.sp 431u
+\h'546u'\D'l -20u -33u'\D'l 20u 13u'\D'l 20u -13u'\D'l -20u 33u'
+.sp -1
+.sp -141u
+\h'546u'\D'l 0u 141u'
+.sp -1
+.sp 444u
+\h'559u'\D'l 0u 141u'
+.sp -1
+.sp 141u
+\h'559u'\D'l -20u -34u'\D'l 20u 14u'\D'l 21u -14u'\D'l -21u 34u'
+.sp -1
+.sp 418u
+\h'559u'\D'l -20u -34u'\D'l 20u 13u'\D'l 21u -13u'\D'l -21u 34u'
+.sp -1
+.sp -142u
+\h'559u'\D'l 0u 142u'
+.sp -1
+.sp 445u
+\h'559u'\D'l 0u 141u'
+.sp -1
+.sp 141u
+\h'559u'\D'l -20u -33u'\D'l 20u 13u'\D'l 21u -13u'\D'l -21u 33u'
+.sp -1
+.sp 276u
+\h'559u'\D'l 0u 0u'
+.sp -1
+.sp 21u
+\h'566u'\D'l 0u 128u'
+.sp -1
+.sp 121u
+\h'566u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Dequeue Packet
+.sp -2377u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Extract Information
+.sp -1515u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Process Options
+.sp -1085u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Keep NPDU
+.sp -654u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Forward NPDU
+.sp -654u
+\h'1031u'\&\*(g9
+.sp |\n(g8u
+.sp -815u
+\h'7u'\D'l 0u 215u'\D'l 1725u 0u'\D'l 0u -215u'\D'l -1725u 0u'
+.sp -1
+\h'815u'\D'l 0u 215u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Reassemble Fragments
+.sp 593u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.sp -445u
+\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Consistency Checks
+.sp -686u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.sp 1307u
+\h'7u'\D'l 0u 222u'\D'l 1192u 0u'\D'l 0u -222u'\D'l -1192u 0u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Process NPDU
+.sp 162u
+\h'61u'\&\*(g9
+.sp |\n(g8u
+.sp -539u
+\h'600u'\D'l 700u 0u'\D'l 0u 431u'\D'l -700u 0u'
+.sp -1
+.sp 431u
+\h'600u'\D'l 33u -20u'\D'l -13u 20u'\D'l 13u 20u'\D'l -33u -20u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Discard Packet
+.sp -2316u
+\h'2109u'\&\*(g9
+.sp |\n(g8u
+.sp -2485u
+\h'2048u'\D'l 0u 223u'\D'l 1193u 0u'\D'l 0u -223u'\D'l -1193u 0u'
+.sp -1
+\D's 16u'
+.sp -1
+.sp 2270u
+\h'1246u'\D'l 1294u 0u'\D'l 0u -1993u'
+.sp -1
+.sp -863u
+\h'1246u'\D'l 1294u 0u'
+.sp -1
+.sp -430u
+\h'1246u'\D'l 1294u 0u'
+.sp -1
+.sp -431u
+\h'1246u'\D'l 1294u 0u'
+.sp -1
+.sp -431u
+\h'1246u'\D'l 378u 0u'\D'l 0u 269u'\D'l 916u 0u'
+.sp -1
+.sp 162u
+\h'2540u'\D'l 20u 33u'\D'l -20u -13u'\D'l -20u 13u'\D'l 20u -33u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp 2586u
+\h'546u'\D'l 2910u 0u'\D'l 0u -2964u'\D'l -2910u 0u'\D'l 0u 54u'
+.sp -1
+.sp -2910u
+\h'546u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
+.sp -1
+.sp 1886u
+\h'1785u'\D'l 1671u 0u'
+.sp -1
+.sp -1886u
+\h'2540u'\D'l 0u -54u'
+.sp -1
+.sp 2910u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG:\fR Flow of control for processing CLNP NPDUs
+.)z
diff --git a/share/doc/iso/wisc/figs/clnp_output.grn b/share/doc/iso/wisc/figs/clnp_output.grn
new file mode 100644
index 0000000..5025eee
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_output.grn
@@ -0,0 +1,18 @@
+.(z
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.4
+narrow 1
+medium 3
+thick 7
+pointscale off
+file clnp_output.gsrc
+.GE
+.ce
+\fB Figure \n+(FG:\fR Flow of control for emitting CLNP NPDUs
+.)z
diff --git a/share/doc/iso/wisc/figs/clnp_output.gsrc b/share/doc/iso/wisc/figs/clnp_output.gsrc
new file mode 100644
index 0000000..49a0186
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_output.gsrc
@@ -0,0 +1,376 @@
+gremlinfile
+0 528.00 32.00
+3
+528.00 688.00
+531.00 683.00
+528.00 685.00
+525.00 683.00
+528.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 3
+176.00 160.00
+176.00 144.00
+528.00 144.00
+528.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 672.00
+272.00 685.00
+272.00 685.00
+272.00 685.00
+-1.00 -1.00
+2 2
+6 EINVAL
+ 3
+240.00 672.00
+528.00 672.00
+-1.00 -1.00
+4 0
+0 
+ 3
+128.00 652.00
+128.00 631.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 631.00
+125.00 636.00
+128.00 634.00
+131.00 636.00
+128.00 631.00
+-1.00 -1.00
+5 0
+0 
+ 0
+64.00 672.00
+64.00 687.00
+64.00 687.00
+64.00 687.00
+-1.00 -1.00
+1 2
+15 Examine Options
+ 3
+47.00 689.00
+47.00 656.00
+224.00 656.00
+224.00 689.00
+47.00 689.00
+-1.00 -1.00
+5 0
+0 
+ 0
+64.00 608.00
+64.00 623.00
+64.00 623.00
+64.00 623.00
+-1.00 -1.00
+1 2
+15 Check Addresses
+ 0
+64.00 546.00
+64.00 561.00
+64.00 561.00
+64.00 561.00
+-1.00 -1.00
+1 2
+20 Allocate Header mbuf
+ 0
+64.00 481.00
+64.00 496.00
+64.00 496.00
+64.00 496.00
+-1.00 -1.00
+1 2
+17 Create Fixed Part
+ 0
+64.00 417.00
+64.00 432.00
+64.00 432.00
+64.00 432.00
+-1.00 -1.00
+1 2
+12 Route Packet
+ 0
+64.00 352.00
+64.00 367.00
+64.00 367.00
+64.00 367.00
+-1.00 -1.00
+1 2
+19 Append Address Part
+ 0
+64.00 290.00
+64.00 305.00
+64.00 305.00
+64.00 305.00
+-1.00 -1.00
+1 2
+19 Append Options Part
+ 0
+64.00 225.00
+64.00 240.00
+64.00 240.00
+64.00 240.00
+-1.00 -1.00
+1 2
+13 Transmit NPDU
+ 0
+192.00 224.00
+192.00 239.00
+192.00 239.00
+192.00 239.00
+-1.00 -1.00
+1 2
+13 Fragment NPDU
+ 3
+47.00 625.00
+47.00 592.00
+224.00 592.00
+224.00 625.00
+47.00 625.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 562.00
+47.00 529.00
+224.00 529.00
+224.00 562.00
+47.00 562.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 498.00
+47.00 465.00
+224.00 465.00
+224.00 498.00
+47.00 498.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 433.00
+48.00 400.00
+225.00 400.00
+225.00 433.00
+48.00 433.00
+-1.00 -1.00
+5 0
+0 
+ 3
+47.00 368.00
+47.00 335.00
+224.00 335.00
+224.00 368.00
+47.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 304.00
+48.00 271.00
+225.00 271.00
+225.00 304.00
+48.00 304.00
+-1.00 -1.00
+5 0
+0 
+ 3
+49.00 240.00
+49.00 209.00
+306.00 209.00
+306.00 240.00
+49.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 3
+167.00 239.00
+167.00 209.00
+-1.00 -1.00
+1 0
+0 
+ 3
+128.00 588.00
+128.00 567.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 567.00
+125.00 572.00
+128.00 570.00
+131.00 572.00
+128.00 567.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 503.00
+125.00 508.00
+128.00 506.00
+131.00 508.00
+128.00 503.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 524.00
+128.00 503.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 458.00
+130.00 437.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 437.00
+127.00 442.00
+130.00 440.00
+133.00 442.00
+130.00 437.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 375.00
+127.00 380.00
+130.00 378.00
+133.00 380.00
+130.00 375.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 396.00
+130.00 375.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 330.00
+130.00 309.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 309.00
+127.00 314.00
+130.00 312.00
+133.00 314.00
+130.00 309.00
+-1.00 -1.00
+5 0
+0 
+ 3
+130.00 268.00
+130.00 268.00
+-1.00 -1.00
+5 0
+0 
+ 3
+131.00 265.00
+131.00 246.00
+-1.00 -1.00
+5 0
+0 
+ 3
+131.00 247.00
+128.00 252.00
+131.00 250.00
+134.00 252.00
+131.00 247.00
+-1.00 -1.00
+5 0
+0 
+ 3
+146.00 320.00
+242.00 320.00
+242.00 255.00
+146.00 255.00
+-1.00 -1.00
+5 0
+0 
+ 3
+146.00 255.00
+151.00 258.00
+149.00 255.00
+151.00 252.00
+146.00 255.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 608.00
+272.00 621.00
+272.00 621.00
+272.00 621.00
+-1.00 -1.00
+2 2
+12 ENAMETOOLONG
+ 0
+273.00 545.00
+273.00 558.00
+273.00 558.00
+273.00 558.00
+-1.00 -1.00
+2 2
+7 ENOBUFS
+ 0
+272.00 417.00
+272.00 430.00
+272.00 430.00
+272.00 430.00
+-1.00 -1.00
+2 2
+25 ENETUNREACH, EHOSTUNREACH
+ 0
+272.00 289.00
+272.00 302.00
+272.00 302.00
+272.00 302.00
+-1.00 -1.00
+2 2
+7 ENOBUFS
+ 3
+241.00 601.00
+529.00 601.00
+-1.00 -1.00
+4 0
+0 
+ 3
+240.00 536.00
+530.00 536.00
+-1.00 -1.00
+4 0
+0 
+ 3
+241.00 413.00
+527.00 413.00
+-1.00 -1.00
+4 0
+0 
+ 3
+233.00 288.00
+529.00 288.00
+-1.00 -1.00
+4 0
+0 
+ 0
+152.00 175.00
+152.00 190.00
+152.00 190.00
+152.00 190.00
+-1.00 -1.00
+1 2
+7 SUCCESS
+ -1
diff --git a/share/doc/iso/wisc/figs/clnp_output.nr b/share/doc/iso/wisc/figs/clnp_output.nr
new file mode 100644
index 0000000..b11d465
--- /dev/null
+++ b/share/doc/iso/wisc/figs/clnp_output.nr
@@ -0,0 +1,233 @@
+.(z
+.br
+.nr g1 3456u
+.nr g2 3891u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "SUCCESS
+.sp 3670u
+\h'750u'\&\*(g9
+.sp |\n(g8u
+\D's 16u'\D't 1u'
+.sp -1
+.sp 2863u
+\h'1328u'\D'l 2114u 0u'
+.sp -1
+.sp -893u
+\h'1385u'\D'l 2043u 0u'
+.sp -1
+.sp -877u
+\h'1378u'\D'l 2071u 0u'
+.sp -1
+.sp -464u
+\h'1385u'\D'l 2057u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "ENOBUFS
+.sp 2227u
+\h'1607u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "ENETUNREACH, EHOSTUNREACH
+.sp 1313u
+\h'1607u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "ENOBUFS
+.sp 400u
+\h'1614u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "ENAMETOOLONG
+.sp -50u
+\h'1607u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 2469u
+\h'707u'\D'l 36u -21u'\D'l -15u 21u'\D'l 15u 22u'\D'l -36u -22u'
+.sp -1
+.sp -464u
+\h'707u'\D'l 686u 0u'\D'l 0u 464u'\D'l -686u 0u'
+.sp -1
+.sp 522u
+\h'600u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
+.sp -1
+.sp -129u
+\h'600u'\D'l 0u 136u'
+.sp -1
+.sp -21u
+\h'593u'\D'l 0u 0u'
+.sp -1
+.sp -293u
+\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
+.sp -1
+.sp -150u
+\h'593u'\D'l 0u 150u'
+.sp -1
+.sp -471u
+\h'593u'\D'l 0u 150u'
+.sp -1
+.sp 150u
+\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
+.sp -1
+.sp -443u
+\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
+.sp -1
+.sp -150u
+\h'593u'\D'l 0u 150u'
+.sp -1
+.sp -470u
+\h'578u'\D'l 0u 149u'
+.sp -1
+.sp 149u
+\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
+.sp -1
+.sp -456u
+\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
+.sp -1
+.sp -150u
+\h'578u'\D'l 0u 150u'
+.sp -1
+\D's 4u'
+.sp -1
+.sp 2491u
+\h'857u'\D'l 0u 214u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -7u
+\h'14u'\D'l 0u 221u'\D'l 1835u 0u'\D'l 0u -221u'\D'l -1835u 0u'
+.sp -1
+.sp -457u
+\h'7u'\D'l 0u 235u'\D'l 1264u 0u'\D'l 0u -235u'\D'l -1264u 0u'
+.sp -1
+.sp -457u
+\D'l 0u 235u'\D'l 1264u 0u'\D'l 0u -235u'\D'l -1264u 0u'
+.sp -1
+.sp -465u
+\h'7u'\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
+.sp -1
+.sp -464u
+\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
+.sp -1
+.sp -456u
+\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
+.sp -1
+.sp -450u
+\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Fragment NPDU
+.sp 2863u
+\h'1035u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Transmit NPDU
+.sp 2856u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Append Options Part
+.sp 2392u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Append Address Part
+.sp 1949u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Route Packet
+.sp 1485u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Create Fixed Part
+.sp 1028u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Allocate Header mbuf
+.sp 565u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Check Addresses
+.sp 122u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.sp -457u
+\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
+.sp -1
+.ft R
+.ps 10
+.nr g8 \n(.d
+.ds g9 "Examine Options
+.sp 122u
+\h'121u'\&\*(g9
+.sp |\n(g8u
+.sp 415u
+\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
+.sp -1
+.sp -150u
+\h'578u'\D'l 0u 150u'
+.sp -1
+\D's 16u'
+.sp -1
+.sp -143u
+\h'1378u'\D'l 2057u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "EINVAL
+\h'1607u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 3655u
+\h'921u'\D'l 0u 114u'\D'l 2514u 0u'\D'l 0u -3883u'
+.sp -1
+.sp -3769u
+\h'3435u'\D'l 21u 35u'\D'l -21u -14u'\D'l -22u 14u'\D'l 22u -35u'
+.sp -1
+.sp 3883u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG:\fR Flow of control for emitting CLNP NPDUs
+.)z
diff --git a/share/doc/iso/wisc/figs/ecn_network.grn b/share/doc/iso/wisc/figs/ecn_network.grn
new file mode 100644
index 0000000..d58c5d8
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_network.grn
@@ -0,0 +1,19 @@
+.(z
+.hl
+.GS C
+width 6.0
+high 4.0
+1 6
+2 8 
+3 10
+4 12
+sc 0.5
+narrow 1
+medium 3
+thick 7
+pointscale off
+file ecn_network.gsrc
+.GE
+.ce
+\fBFigure \n+(FG:\fR The X.25 Network Interface
+.)z
diff --git a/share/doc/iso/wisc/figs/ecn_network.gsrc b/share/doc/iso/wisc/figs/ecn_network.gsrc
new file mode 100644
index 0000000..1772b1d
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_network.gsrc
@@ -0,0 +1,288 @@
+gremlinfile
+0 370.00 354.00
+0
+370.00 346.00
+370.00 361.00
+370.00 361.00
+370.00 361.00
+-1.00 -1.00
+1 2
+10 (/dev/bus)
+ 0
+360.00 361.00
+360.00 376.00
+360.00 376.00
+360.00 376.00
+-1.00 -1.00
+1 2
+13 X.25 download
+ 0
+558.00 524.00
+558.00 539.00
+558.00 539.00
+558.00 539.00
+-1.00 -1.00
+1 2
+13 configuration
+ 0
+558.00 534.00
+558.00 549.00
+558.00 549.00
+558.00 549.00
+-1.00 -1.00
+1 2
+8 updated 
+ 0
+358.00 459.00
+358.00 474.00
+358.00 474.00
+358.00 474.00
+-1.00 -1.00
+1 2
+12 (/dev/kmem1)
+ 0
+362.00 474.00
+362.00 489.00
+362.00 489.00
+362.00 489.00
+-1.00 -1.00
+1 2
+13 configuration
+ 0
+248.00 399.00
+248.00 414.00
+248.00 414.00
+248.00 414.00
+-1.00 -1.00
+1 2
+22 Data Area on the board
+ 0
+248.00 409.00
+248.00 424.00
+248.00 424.00
+248.00 424.00
+-1.00 -1.00
+1 2
+22 to and from the Common
+ 0
+245.00 507.00
+245.00 522.00
+245.00 522.00
+245.00 522.00
+-1.00 -1.00
+1 2
+10 ecnioctl()
+ 0
+245.00 516.00
+245.00 531.00
+245.00 531.00
+245.00 531.00
+-1.00 -1.00
+1 2
+12 ecnrestart()
+ 0
+245.00 524.00
+245.00 539.00
+245.00 539.00
+245.00 539.00
+-1.00 -1.00
+1 2
+13 ecnshutdown()
+ 0
+176.00 419.00
+176.00 434.00
+176.00 434.00
+176.00 434.00
+-1.00 -1.00
+1 2
+34 INTERFACES: the NCB command loaded
+ 0
+175.00 532.00
+175.00 547.00
+175.00 547.00
+175.00 547.00
+-1.00 -1.00
+1 2
+23 INTERFACES: ecnoutput()
+ 0
+42.00 415.00
+42.00 430.00
+42.00 430.00
+42.00 430.00
+-1.00 -1.00
+1 2
+15 COMMANDS: NCB_*
+ 0
+42.00 527.00
+42.00 542.00
+42.00 542.00
+42.00 542.00
+-1.00 -1.00
+1 2
+15 COMMANDS: ECN_*
+ 3
+546.00 511.00
+553.00 494.00
+560.00 511.00
+-1.00 -1.00
+5 0
+0 
+ 3
+287.00 364.00
+270.00 357.00
+287.00 348.00
+-1.00 -1.00
+5 0
+0 
+ 3
+287.00 477.00
+271.00 469.00
+287.00 461.00
+-1.00 -1.00
+5 0
+0 
+ 3
+151.00 397.00
+159.00 382.00
+167.00 398.00
+-1.00 -1.00
+5 0
+0 
+ 3
+151.00 431.00
+159.00 445.00
+167.00 431.00
+-1.00 -1.00
+5 0
+0 
+ 3
+153.00 510.00
+160.00 494.00
+168.00 510.00
+-1.00 -1.00
+5 0
+0 
+ 3
+152.00 540.00
+160.00 558.00
+167.00 540.00
+-1.00 -1.00
+5 0
+0 
+ 3
+272.00 469.00
+492.00 469.00
+-1.00 -1.00
+5 0
+0 
+ 3
+271.00 357.00
+552.00 357.00
+552.00 446.00
+-1.00 -1.00
+5 0
+0 
+ 3
+553.00 557.00
+553.00 494.00
+-1.00 -1.00
+5 0
+0 
+ 3
+159.00 445.00
+159.00 381.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 557.00
+160.00 494.00
+-1.00 -1.00
+5 0
+0 
+ 0
+517.00 458.00
+517.00 472.00
+517.00 472.00
+517.00 472.00
+-1.00 -1.00
+1 3
+8 %ecnload
+ 0
+514.00 570.00
+514.00 584.00
+514.00 584.00
+514.00 584.00
+-1.00 -1.00
+1 3
+8 %ecnconf
+ 0
+115.00 347.00
+115.00 366.00
+115.00 366.00
+115.00 366.00
+-1.00 -1.00
+1 4
+11 EICON Board
+ 0
+114.00 458.00
+114.00 477.00
+114.00 477.00
+114.00 477.00
+-1.00 -1.00
+1 4
+11 UNIX Driver
+ 0
+133.00 569.00
+133.00 588.00
+133.00 588.00
+133.00 588.00
+-1.00 -1.00
+1 4
+4 CONS
+ 3
+493.00 445.00
+493.00 493.00
+608.00 493.00
+608.00 445.00
+493.00 445.00
+-1.00 -1.00
+5 0
+0 
+ 3
+493.00 557.00
+493.00 605.00
+608.00 605.00
+608.00 557.00
+493.00 557.00
+-1.00 -1.00
+5 0
+0 
+ 3
+63.00 332.00
+63.00 381.00
+272.00 381.00
+272.00 332.00
+63.00 332.00
+-1.00 -1.00
+5 0
+0 
+ 3
+63.00 445.00
+63.00 494.00
+272.00 494.00
+272.00 445.00
+63.00 445.00
+-1.00 -1.00
+5 0
+0 
+ 3
+63.00 557.00
+63.00 606.00
+272.00 606.00
+272.00 557.00
+63.00 557.00
+-1.00 -1.00
+5 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/ecn_network.nr b/share/doc/iso/wisc/figs/ecn_network.nr
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_network.nr
diff --git a/share/doc/iso/wisc/figs/ecn_queue.grn b/share/doc/iso/wisc/figs/ecn_queue.grn
new file mode 100644
index 0000000..5a9824d
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_queue.grn
@@ -0,0 +1,19 @@
+.(z
+.hl
+.GS C
+width 6.0
+high 3.0
+1 5
+2 7 
+3 9 
+4 12
+sc 0.5
+narrow 1
+medium 3
+thick 7
+pointscale off
+file ecn_queue.gsrc
+.GE
+.ce
+\fBFigure \n+(FG:\fR Queue Placement Strategy
+.)z
diff --git a/share/doc/iso/wisc/figs/ecn_queue.gsrc b/share/doc/iso/wisc/figs/ecn_queue.gsrc
new file mode 100644
index 0000000..81e3e07
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_queue.gsrc
@@ -0,0 +1,371 @@
+gremlinfile
+0 98.00 422.00
+3
+98.00 278.00
+562.00 278.00
+-1.00 -1.00
+4 0
+0 
+ 3
+425.00 557.00
+577.00 557.00
+-1.00 -1.00
+4 0
+0 
+ 3
+341.00 528.00
+425.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 0
+457.00 536.00
+457.00 549.00
+457.00 549.00
+457.00 549.00
+-1.00 -1.00
+2 3
+10 ECN driver
+ 0
+321.00 419.00
+321.00 432.00
+321.00 432.00
+321.00 432.00
+-1.00 -1.00
+2 2
+20 Driver->CONS replies
+ 0
+356.00 584.00
+356.00 599.00
+356.00 599.00
+356.00 599.00
+-1.00 -1.00
+1 2
+8 x25intrq
+ 0
+457.00 253.00
+457.00 266.00
+457.00 266.00
+457.00 266.00
+-1.00 -1.00
+2 3
+16 EICON X.25 board
+ 0
+457.00 285.00
+457.00 298.00
+457.00 298.00
+457.00 298.00
+-1.00 -1.00
+2 3
+10 ECN driver
+ 0
+457.00 563.00
+457.00 576.00
+457.00 576.00
+457.00 576.00
+-1.00 -1.00
+2 3
+11 CONS module
+ 3
+217.00 557.00
+340.00 557.00
+-1.00 -1.00
+4 0
+0 
+ 3
+90.00 556.00
+131.00 556.00
+-1.00 -1.00
+4 0
+0 
+ 3
+375.00 222.00
+381.00 209.00
+389.00 222.00
+-1.00 -1.00
+5 0
+0 
+ 3
+168.00 222.00
+174.00 209.00
+182.00 222.00
+-1.00 -1.00
+5 0
+0 
+ 3
+165.00 615.00
+171.00 602.00
+179.00 615.00
+-1.00 -1.00
+5 0
+0 
+ 3
+166.00 421.00
+172.00 408.00
+180.00 421.00
+-1.00 -1.00
+5 0
+0 
+ 3
+173.00 392.00
+189.00 371.00
+-1.00 -1.00
+1 0
+0 
+ 3
+173.00 348.00
+172.00 392.00
+273.00 360.00
+-1.00 -1.00
+1 0
+0 
+ 3
+306.00 361.00
+382.00 414.00
+-1.00 -1.00
+1 0
+0 
+ 3
+266.00 228.00
+273.00 243.00
+280.00 228.00
+-1.00 -1.00
+5 0
+0 
+ 0
+201.00 197.00
+201.00 210.00
+201.00 210.00
+201.00 210.00
+-1.00 -1.00
+2 2
+23 Driver<->Board commands
+ 3
+273.00 246.00
+273.00 214.00
+-1.00 -1.00
+1 0
+0 
+ 0
+223.00 295.00
+223.00 308.00
+223.00 308.00
+223.00 308.00
+-1.00 -1.00
+2 2
+15 posted commands
+ 3
+111.00 402.00
+131.00 402.00
+-1.00 -1.00
+5 0
+0 
+ 3
+376.00 459.00
+383.00 474.00
+390.00 459.00
+-1.00 -1.00
+5 0
+0 
+ 3
+364.00 363.00
+383.00 416.00
+387.00 357.00
+-1.00 -1.00
+1 0
+0 
+ 3
+383.00 437.00
+383.00 473.00
+-1.00 -1.00
+1 0
+0 
+ 3
+172.00 411.00
+172.00 474.00
+-1.00 -1.00
+1 0
+0 
+ 0
+8.00 401.00
+8.00 416.00
+8.00 416.00
+8.00 416.00
+-1.00 -1.00
+1 2
+15 ecn_pending_req
+ 0
+109.00 653.00
+109.00 666.00
+109.00 666.00
+109.00 666.00
+-1.00 -1.00
+2 2
+20 CONS->Driver command
+ 0
+357.00 570.00
+357.00 585.00
+357.00 585.00
+357.00 585.00
+-1.00 -1.00
+1 2
+5 QUEUE
+ 0
+151.00 569.00
+151.00 584.00
+151.00 584.00
+151.00 584.00
+-1.00 -1.00
+1 2
+5 QUEUE
+ 3
+340.00 315.00
+340.00 298.00
+422.00 298.00
+422.00 315.00
+340.00 315.00
+-1.00 -1.00
+6 0
+0 
+ 3
+235.00 347.00
+235.00 330.00
+317.00 330.00
+317.00 347.00
+235.00 347.00
+-1.00 -1.00
+6 0
+0 
+ 3
+232.00 262.00
+232.00 245.00
+314.00 245.00
+314.00 262.00
+232.00 262.00
+-1.00 -1.00
+6 0
+0 
+ 3
+133.00 329.00
+133.00 312.00
+215.00 312.00
+215.00 329.00
+133.00 329.00
+-1.00 -1.00
+6 0
+0 
+ 3
+133.00 409.00
+133.00 392.00
+215.00 392.00
+215.00 409.00
+133.00 409.00
+-1.00 -1.00
+6 0
+0 
+ 3
+340.00 547.00
+426.00 547.00
+-1.00 -1.00
+5 0
+0 
+ 3
+340.00 509.00
+425.00 509.00
+-1.00 -1.00
+5 0
+0 
+ 3
+340.00 491.00
+424.00 491.00
+-1.00 -1.00
+5 0
+0 
+ 3
+340.00 602.00
+340.00 473.00
+425.00 473.00
+425.00 601.00
+-1.00 -1.00
+6 0
+0 
+ 3
+132.00 547.00
+218.00 547.00
+-1.00 -1.00
+5 0
+0 
+ 3
+133.00 528.00
+217.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+132.00 509.00
+217.00 509.00
+-1.00 -1.00
+5 0
+0 
+ 3
+132.00 491.00
+216.00 491.00
+-1.00 -1.00
+5 0
+0 
+ 3
+132.00 602.00
+132.00 473.00
+217.00 473.00
+217.00 601.00
+-1.00 -1.00
+6 0
+0 
+ 3
+125.00 410.00
+132.00 402.00
+125.00 395.00
+-1.00 -1.00
+5 0
+0 
+ 3
+174.00 211.00
+174.00 312.00
+-1.00 -1.00
+1 0
+0 
+ 3
+381.00 210.00
+381.00 298.00
+-1.00 -1.00
+1 0
+0 
+ 3
+374.00 282.00
+381.00 297.00
+388.00 282.00
+-1.00 -1.00
+5 0
+0 
+ 3
+167.00 297.00
+174.00 312.00
+181.00 297.00
+-1.00 -1.00
+5 0
+0 
+ 0
+156.00 583.00
+156.00 598.00
+156.00 598.00
+156.00 598.00
+-1.00 -1.00
+1 2
+6 ecn_if
+ 3
+171.00 604.00
+171.00 648.00
+-1.00 -1.00
+1 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/ecn_queue.nr b/share/doc/iso/wisc/figs/ecn_queue.nr
new file mode 100644
index 0000000..c6c0ce1
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_queue.nr
@@ -0,0 +1,262 @@
+.(z
+.hl
+.br
+.nr g1 2156u
+.nr g2 1727u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D's 4u'\D't 1u'
+.sp -1
+.sp 186u
+\h'617u'\D'l 0u -167u'
+.sp -1
+.ft R
+.ps 7
+.nr g8 \n(.d
+.ds g9 "ecn_if
+.sp 80u
+\h'561u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 1162u
+\h'602u'\D'l 27u -56u'\D'l 26u 56u'
+.sp -1
+.sp 57u
+\h'1387u'\D'l 26u -57u'\D'l 27u 57u'
+.sp -1
+\D's 4u'
+.sp -1
+.sp 273u
+\h'1413u'\D'l 0u -333u'
+.sp -1
+.sp -4u
+\h'629u'\D'l 0u -382u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -754u
+\h'443u'\D'l 27u 31u'\D'l -27u 26u'
+.sp -1
+\D't 3u'
+.sp -1
+.sp -726u
+\h'470u'\D'l 0u 487u'\D'l 322u 0u'\D'l 0u -484u'
+.sp -1
+\D't 1u'
+.sp -1
+.sp 419u
+\h'470u'\D'l 318u 0u'
+.sp -1
+.sp -68u
+\h'470u'\D'l 322u 0u'
+.sp -1
+.sp -71u
+\h'473u'\D'l 319u 0u'
+.sp -1
+.sp -72u
+\h'470u'\D'l 326u 0u'
+.sp -1
+\D't 3u'
+.sp -1
+.sp -208u
+\h'1258u'\D'l 0u 487u'\D'l 322u 0u'\D'l 0u -484u'
+.sp -1
+\D't 1u'
+.sp -1
+.sp 419u
+\h'1258u'\D'l 318u 0u'
+.sp -1
+.sp -68u
+\h'1258u'\D'l 322u 0u'
+.sp -1
+.sp -143u
+\h'1258u'\D'l 326u 0u'
+.sp -1
+\D't 3u'
+.sp -1
+.sp 522u
+\h'473u'\D'l 0u 64u'\D'l 311u 0u'\D'l 0u -64u'\D'l -311u 0u'
+.sp -1
+.sp 303u
+\h'473u'\D'l 0u 65u'\D'l 311u 0u'\D'l 0u -65u'\D'l -311u 0u'
+.sp -1
+.sp 254u
+\h'849u'\D'l 0u 64u'\D'l 310u 0u'\D'l 0u -64u'\D'l -310u 0u'
+.sp -1
+.sp -322u
+\h'860u'\D'l 0u 64u'\D'l 311u 0u'\D'l 0u -64u'\D'l -311u 0u'
+.sp -1
+.sp 121u
+\h'1258u'\D'l 0u 65u'\D'l 311u 0u'\D'l 0u -65u'\D'l -311u 0u'
+.sp -1
+.ft R
+.ps 7
+.nr g8 \n(.d
+.ds g9 "QUEUE
+.sp -961u
+\h'542u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 7
+.nr g8 \n(.d
+.ds g9 "QUEUE
+.sp -965u
+\h'1322u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 7
+.nr g8 \n(.d
+.ds g9 "CONS->Driver command
+.sp -1280u
+\h'383u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 7
+.nr g8 \n(.d
+.ds g9 "ecn_pending_req
+.sp -326u
+\&\*(g9
+.sp |\n(g8u
+\D's 4u'\D't 1u'
+.sp -1
+.sp -364u
+\h'621u'\D'l 0u -238u'
+.sp -1
+.sp -98u
+\h'1421u'\D'l 0u -137u'
+.sp -1
+.sp 280u
+\h'1349u'\D'l 72u -201u'\D'l 15u 224u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -363u
+\h'1394u'\D'l 27u -57u'\D'l 26u 57u'
+.sp -1
+.sp 216u
+\h'390u'\D'l 76u 0u'
+.sp -1
+.ft I
+.ps 7
+.nr g8 \n(.d
+.ds g9 "posted commands
+.sp 405u
+\h'815u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'
+.sp -1
+.sp 591u
+\h'1004u'\D'l 0u 121u'
+.sp -1
+.ft I
+.ps 7
+.nr g8 \n(.d
+.ds g9 "Driver<->Board commands
+.sp 185u
+\h'731u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 68u
+\h'977u'\D'l 27u -57u'\D'l 27u 57u'
+.sp -1
+\D's 4u'
+.sp -1
+.sp -504u
+\h'1129u'\D'l 288u -201u'
+.sp -1
+.sp 49u
+\h'625u'\D'l -4u -167u'\D'l 383u 122u'
+.sp -1
+.sp -167u
+\h'625u'\D'l 61u 80u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -109u
+\h'599u'\D'l 22u 49u'\D'l 31u -49u'
+.sp -1
+.sp -735u
+\h'595u'\D'l 22u 50u'\D'l 31u -50u'
+.sp -1
+.sp 1489u
+\h'606u'\D'l 23u 49u'\D'l 30u -49u'
+.sp -1
+\h'1391u'\D'l 22u 49u'\D'l 31u -49u'
+.sp -1
+\D's 16u'
+.sp -1
+.sp -1265u
+\h'311u'\D'l 155u 0u'
+.sp -1
+.sp -4u
+\h'792u'\D'l 466u 0u'
+.sp -1
+.ft I
+.ps 9
+.nr g8 \n(.d
+.ds g9 "CONS module
+.sp -23u
+\h'1701u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 9
+.nr g8 \n(.d
+.ds g9 "ECN driver
+.sp 1030u
+\h'1701u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 9
+.nr g8 \n(.d
+.ds g9 "EICON X.25 board
+.sp 1151u
+\h'1701u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 7
+.nr g8 \n(.d
+.ds g9 "x25intrq
+.sp -102u
+\h'1319u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 7
+.nr g8 \n(.d
+.ds g9 "Driver->CONS replies
+.sp 522u
+\h'1186u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 9
+.nr g8 \n(.d
+.ds g9 "ECN driver
+.sp 80u
+\h'1701u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 110u
+\h'1262u'\D'l 318u 0u'
+.sp -1
+\D's 16u'
+.sp -1
+.sp -110u
+\h'1580u'\D'l 576u 0u'
+.sp -1
+.sp 1056u
+\h'341u'\D'l 1758u 0u'
+.sp -1
+.sp 307u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fBFigure \n+(FG:\fR Queue Placement Strategy
+.)z
diff --git a/share/doc/iso/wisc/figs/ecn_vc.grn b/share/doc/iso/wisc/figs/ecn_vc.grn
new file mode 100644
index 0000000..b1c93ed
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_vc.grn
@@ -0,0 +1,19 @@
+.(z
+.hl
+.GS C
+width 6.0
+high 4.0
+1 8
+2 10 
+3 12
+4 14
+sc 0.5
+narrow 1
+medium 3
+thick 7
+pointscale off
+file ecn_vc.gsrc
+.GE
+.ce
+\fBFigure \n+(FG:\fR Virtual Circuit State Diagram
+.)z
diff --git a/share/doc/iso/wisc/figs/ecn_vc.gsrc b/share/doc/iso/wisc/figs/ecn_vc.gsrc
new file mode 100644
index 0000000..9364ced
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_vc.gsrc
@@ -0,0 +1,273 @@
+gremlinfile
+0 184.00 269.00
+0
+184.00 431.00
+184.00 441.00
+184.00 441.00
+184.00 441.00
+-1.00 -1.00
+2 1
+23 SEND/RECEIVE completion
+ 0
+110.00 358.00
+110.00 368.00
+110.00 368.00
+110.00 368.00
+-1.00 -1.00
+2 1
+10 completion
+ 0
+99.00 368.00
+99.00 378.00
+99.00 378.00
+99.00 378.00
+-1.00 -1.00
+2 1
+11 CLEAR/ABORT
+ 0
+366.00 360.00
+366.00 370.00
+366.00 370.00
+366.00 370.00
+-1.00 -1.00
+2 1
+6 issued
+ 0
+359.00 373.00
+359.00 383.00
+359.00 383.00
+359.00 383.00
+-1.00 -1.00
+2 1
+11 CLEAR/ABORT
+ 0
+210.00 445.00
+210.00 455.00
+210.00 455.00
+210.00 455.00
+-1.00 -1.00
+2 1
+9 0x0a from
+ 0
+206.00 495.00
+206.00 505.00
+206.00 505.00
+206.00 505.00
+-1.00 -1.00
+2 1
+22 CALL/LISTEN completion
+ 0
+264.00 523.00
+264.00 533.00
+264.00 533.00
+264.00 533.00
+-1.00 -1.00
+2 1
+10 completion
+ 0
+240.00 533.00
+240.00 543.00
+240.00 543.00
+240.00 543.00
+-1.00 -1.00
+2 1
+13 RECEIVE/RESET
+ 0
+379.00 575.00
+379.00 585.00
+379.00 585.00
+379.00 585.00
+-1.00 -1.00
+2 1
+10 completion
+ 0
+345.00 589.00
+345.00 599.00
+345.00 599.00
+345.00 599.00
+-1.00 -1.00
+2 1
+22 0x18 from SEND/RECEIVE
+ 0
+394.00 602.00
+394.00 612.00
+394.00 612.00
+394.00 612.00
+-1.00 -1.00
+2 1
+6 - or -
+ 0
+367.00 613.00
+367.00 623.00
+367.00 623.00
+367.00 623.00
+-1.00 -1.00
+2 1
+12 RESET issued
+ 3
+319.00 359.00
+311.00 340.00
+329.00 349.00
+-1.00 -1.00
+5 0
+0 
+ 3
+361.00 520.00
+367.00 503.00
+351.00 508.00
+-1.00 -1.00
+5 0
+0 
+ 3
+143.00 391.00
+138.00 409.00
+154.00 401.00
+-1.00 -1.00
+5 0
+0 
+ 3
+328.00 582.00
+323.00 600.00
+339.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+163.00 420.00
+152.00 427.00
+163.00 435.00
+-1.00 -1.00
+5 0
+0 
+ 3
+350.00 485.00
+361.00 492.00
+350.00 500.00
+-1.00 -1.00
+5 0
+0 
+ 3
+312.00 341.00
+375.00 407.00
+-1.00 -1.00
+4 0
+0 
+ 3
+135.00 410.00
+202.00 343.00
+-1.00 -1.00
+4 0
+0 
+ 3
+320.00 601.00
+408.00 529.00
+-1.00 -1.00
+4 0
+0 
+ 3
+293.00 563.00
+368.00 503.00
+-1.00 -1.00
+4 0
+0 
+ 3
+150.00 428.00
+358.00 428.00
+-1.00 -1.00
+4 0
+0 
+ 3
+148.00 492.00
+363.00 492.00
+-1.00 -1.00
+4 0
+0 
+ 0
+226.00 309.00
+226.00 319.00
+226.00 319.00
+226.00 319.00
+-1.00 -1.00
+1 1
+8 VC_CLEAR
+ 0
+372.00 455.00
+372.00 465.00
+372.00 465.00
+372.00 465.00
+-1.00 -1.00
+1 1
+12 VC_DATA_XFER
+ 0
+25.00 458.00
+25.00 468.00
+25.00 468.00
+25.00 468.00
+-1.00 -1.00
+1 1
+16 VC_NO_CONNECTION
+ 0
+218.00 293.00
+218.00 303.00
+218.00 303.00
+218.00 303.00
+-1.00 -1.00
+1 1
+11 IN_PROGRESS
+ 0
+222.00 618.00
+222.00 628.00
+222.00 628.00
+222.00 628.00
+-1.00 -1.00
+1 1
+11 IN_PROGRESS
+ 0
+228.00 634.00
+228.00 644.00
+228.00 644.00
+228.00 644.00
+-1.00 -1.00
+1 1
+8 VC_RESET
+ 4
+423.00 459.00
+429.00 390.00
+423.00 528.26
+423.00 389.74
+353.74 459.00
+492.26 459.00
+-1.00 -1.00
+5 0
+0 
+ 4
+89.00 459.00
+83.00 390.00
+89.00 528.26
+89.00 389.74
+158.26 459.00
+19.74 459.00
+-1.00 -1.00
+5 0
+0 
+ 4
+256.00 299.00
+250.00 230.00
+256.00 368.26
+256.00 229.74
+325.26 299.00
+186.74 299.00
+-1.00 -1.00
+5 0
+0 
+ 4
+256.00 621.00
+250.00 690.00
+256.00 551.74
+256.00 690.26
+325.26 621.00
+186.74 621.00
+-1.00 -1.00
+5 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/ecn_vc.nr b/share/doc/iso/wisc/figs/ecn_vc.nr
new file mode 100644
index 0000000..ca2cec5
--- /dev/null
+++ b/share/doc/iso/wisc/figs/ecn_vc.nr
@@ -0,0 +1,205 @@
+.(z
+.hl
+.br
+.nr g1 2364u
+.nr g2 2303u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D't 1u'
+.sp -1
+.sp 346u
+\h'836u'\D'c 693u'
+.sp -1
+.sp 1610u
+\h'836u'\D'c 693u'
+.sp -1
+.sp -800u
+\D'c 693u'
+.sp -1
+\h'1671u'\D'c 693u'
+.sp -1
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "VC_RESET
+.sp -875u
+\h'1042u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "IN_PROGRESS
+.sp -795u
+\h'1012u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "IN_PROGRESS
+.sp 830u
+\h'992u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "VC_NO_CONNECTION
+.sp 5u
+\h'27u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "VC_DATA_XFER
+.sp 20u
+\h'1763u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 8
+.nr g8 \n(.d
+.ds g9 "VC_CLEAR
+.sp 750u
+\h'1032u'\&\*(g9
+.sp |\n(g8u
+\D's 16u'
+.sp -1
+.sp -165u
+\h'642u'\D'l 1076u 0u'
+.sp -1
+.sp 320u
+\h'652u'\D'l 1041u 0u'
+.sp -1
+.sp -675u
+\h'1367u'\D'l 376u 300u'
+.sp -1
+.sp -190u
+\h'1502u'\D'l 441u 360u'
+.sp -1
+.sp 955u
+\h'577u'\D'l 335u 335u'
+.sp -1
+.sp 345u
+\h'1462u'\D'l 316u -330u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -720u
+\h'1653u'\D'l 55u -35u'\D'l -55u -40u'
+.sp -1
+.sp 325u
+\h'717u'\D'l -55u -35u'\D'l 55u -40u'
+.sp -1
+.sp -810u
+\h'1542u'\D'l -25u -90u'\D'l 81u 40u'
+.sp -1
+.sp 955u
+\h'617u'\D'l -25u -90u'\D'l 80u 40u'
+.sp -1
+.sp -645u
+\h'1708u'\D'l 30u 85u'\D'l -80u -25u'
+.sp -1
+.sp 805u
+\h'1497u'\D'l -40u 95u'\D'l 91u -45u'
+.sp -1
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "RESET issued
+.sp -1270u
+\h'1738u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "- or -
+.sp -1215u
+\h'1873u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "0x18 from SEND/RECEIVE
+.sp -1150u
+\h'1628u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "completion
+.sp -1080u
+\h'1798u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "RECEIVE/RESET
+.sp -870u
+\h'1102u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "completion
+.sp -820u
+\h'1222u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "CALL/LISTEN completion
+.sp -680u
+\h'932u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "0x0a from
+.sp -430u
+\h'952u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "CLEAR/ABORT
+.sp -70u
+\h'1698u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "issued
+.sp -5u
+\h'1733u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "CLEAR/ABORT
+.sp -45u
+\h'397u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "completion
+.sp 5u
+\h'452u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 8
+.nr g8 \n(.d
+.ds g9 "SEND/RECEIVE completion
+.sp -360u
+\h'822u'\&\*(g9
+.sp |\n(g8u
+.sp 647u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fBFigure \n+(FG:\fR Virtual Circuit State Diagram
+.)z
diff --git a/share/doc/iso/wisc/figs/func_units.grn b/share/doc/iso/wisc/figs/func_units.grn
new file mode 100644
index 0000000..3c98567
--- /dev/null
+++ b/share/doc/iso/wisc/figs/func_units.grn
@@ -0,0 +1,18 @@
+.(z L
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.3
+narrow 1
+medium 3
+thick 7
+pointscale off
+file func_units.gsrc
+.GE
+.ce
+\fBFigure \n+(FG:\fR  The major functional units of Unix 4.2A
+.)z
diff --git a/share/doc/iso/wisc/figs/func_units.gsrc b/share/doc/iso/wisc/figs/func_units.gsrc
new file mode 100644
index 0000000..29edd83
--- /dev/null
+++ b/share/doc/iso/wisc/figs/func_units.gsrc
@@ -0,0 +1,603 @@
+gremlinfile
+0 80.00 208.00
+0
+80.00 580.00
+80.00 596.00
+80.00 596.00
+80.00 596.00
+-1.00 -1.00
+2 3
+6 kernel
+ 0
+80.00 628.00
+80.00 644.00
+80.00 644.00
+80.00 644.00
+-1.00 -1.00
+2 3
+4 user
+ 3
+144.00 212.00
+141.00 217.00
+144.00 215.00
+147.00 217.00
+144.00 212.00
+-1.00 -1.00
+6 0
+0 
+ 3
+184.00 340.00
+189.66 338.59
+186.12 337.88
+185.41 334.34
+184.00 340.00
+-1.00 -1.00
+6 0
+0 
+ 3
+264.00 284.00
+258.34 285.41
+261.88 286.12
+262.59 289.66
+264.00 284.00
+-1.00 -1.00
+6 0
+0 
+ 3
+320.00 324.00
+317.00 329.00
+320.00 327.00
+323.00 329.00
+320.00 324.00
+-1.00 -1.00
+6 0
+0 
+ 3
+312.00 356.00
+315.00 351.00
+312.00 353.00
+309.00 351.00
+312.00 356.00
+-1.00 -1.00
+6 0
+0 
+ 3
+536.00 548.00
+540.43 544.21
+536.95 545.15
+534.74 542.31
+536.00 548.00
+-1.00 -1.00
+6 0
+0 
+ 3
+576.00 388.00
+573.00 393.00
+576.00 391.00
+579.00 393.00
+576.00 388.00
+-1.00 -1.00
+6 0
+0 
+ 3
+544.00 380.00
+538.34 381.41
+541.88 382.12
+542.59 385.66
+544.00 380.00
+-1.00 -1.00
+6 0
+0 
+ 3
+544.00 380.00
+541.00 385.00
+544.00 383.00
+547.00 385.00
+544.00 380.00
+-1.00 -1.00
+6 0
+0 
+ 3
+560.00 292.00
+563.00 287.00
+560.00 289.00
+557.00 287.00
+560.00 292.00
+-1.00 -1.00
+6 0
+0 
+ 3
+488.00 156.00
+487.55 161.81
+489.34 158.68
+492.92 159.13
+488.00 156.00
+-1.00 -1.00
+6 0
+0 
+ 3
+456.00 164.00
+453.00 169.00
+456.00 167.00
+459.00 169.00
+456.00 164.00
+-1.00 -1.00
+6 0
+0 
+ 3
+384.00 308.00
+385.41 313.66
+386.12 310.12
+389.66 309.41
+384.00 308.00
+-1.00 -1.00
+6 0
+0 
+ 3
+360.00 420.00
+365.00 423.00
+363.00 420.00
+365.00 417.00
+360.00 420.00
+-1.00 -1.00
+6 0
+0 
+ 3
+344.00 444.00
+345.41 449.66
+346.12 446.12
+349.66 445.41
+344.00 444.00
+-1.00 -1.00
+6 0
+0 
+ 3
+456.00 556.00
+456.45 550.19
+454.66 553.32
+451.08 552.87
+456.00 556.00
+-1.00 -1.00
+6 0
+0 
+ 3
+272.00 436.00
+266.34 437.41
+269.88 438.12
+270.59 441.66
+272.00 436.00
+-1.00 -1.00
+6 0
+0 
+ 3
+184.00 404.00
+185.41 409.66
+186.12 406.12
+189.66 405.41
+184.00 404.00
+-1.00 -1.00
+6 0
+0 
+ 3
+432.00 652.00
+427.00 649.00
+429.00 652.00
+427.00 655.00
+432.00 652.00
+-1.00 -1.00
+6 0
+0 
+ 3
+352.00 676.00
+357.81 676.45
+354.68 674.66
+355.13 671.08
+352.00 676.00
+-1.00 -1.00
+6 0
+0 
+ 3
+200.00 500.00
+205.66 498.59
+202.12 497.88
+201.41 494.34
+200.00 500.00
+-1.00 -1.00
+6 0
+0 
+ 3
+208.00 548.00
+213.00 551.00
+211.00 548.00
+213.00 545.00
+208.00 548.00
+-1.00 -1.00
+6 0
+0 
+ 3
+192.00 572.00
+193.41 577.66
+194.12 574.12
+197.66 573.41
+192.00 572.00
+-1.00 -1.00
+6 0
+0 
+ 3
+272.00 660.00
+272.45 654.19
+270.66 657.32
+267.08 656.87
+272.00 660.00
+-1.00 -1.00
+6 0
+0 
+ 3
+456.00 556.00
+344.00 444.00
+-1.00 -1.00
+6 0
+0 
+ 3
+544.00 380.00
+520.00 412.00
+-1.00 -1.00
+6 0
+0 
+ 3
+576.00 388.00
+536.00 548.00
+-1.00 -1.00
+6 0
+0 
+ 3
+560.00 292.00
+488.00 156.00
+-1.00 -1.00
+6 0
+0 
+ 3
+424.00 612.00
+568.00 612.00
+-1.00 -1.00
+2 0
+0 
+ 0
+424.00 68.00
+424.00 84.00
+424.00 84.00
+424.00 84.00
+-1.00 -1.00
+3 3
+7 drivers
+ 0
+424.00 92.00
+424.00 108.00
+424.00 108.00
+424.00 108.00
+-1.00 -1.00
+3 3
+9 interface
+ 3
+480.00 404.00
+456.00 164.00
+-1.00 -1.00
+6 0
+0 
+ 3
+464.00 412.00
+384.00 308.00
+-1.00 -1.00
+6 0
+0 
+ 3
+448.00 436.00
+360.00 420.00
+-1.00 -1.00
+6 0
+0 
+ 3
+312.00 356.00
+320.00 324.00
+-1.00 -1.00
+6 0
+0 
+ 3
+200.00 500.00
+272.00 436.00
+-1.00 -1.00
+6 0
+0 
+ 3
+184.00 340.00
+264.00 284.00
+-1.00 -1.00
+6 0
+0 
+ 3
+144.00 324.00
+144.00 212.00
+-1.00 -1.00
+6 0
+0 
+ 3
+440.00 564.00
+176.00 404.00
+-1.00 -1.00
+6 0
+0 
+ 3
+424.00 588.00
+208.00 548.00
+-1.00 -1.00
+6 0
+0 
+ 3
+352.00 676.00
+432.00 652.00
+-1.00 -1.00
+6 0
+0 
+ 3
+272.00 660.00
+192.00 572.00
+-1.00 -1.00
+6 0
+0 
+ 0
+120.00 132.00
+120.00 148.00
+120.00 148.00
+120.00 148.00
+-1.00 -1.00
+3 3
+7 drivers
+ 0
+120.00 156.00
+120.00 172.00
+120.00 172.00
+120.00 172.00
+-1.00 -1.00
+3 3
+6 device
+ 0
+120.00 180.00
+120.00 196.00
+120.00 196.00
+120.00 196.00
+-1.00 -1.00
+3 3
+7 blocked
+ 0
+424.00 116.00
+424.00 132.00
+424.00 132.00
+424.00 132.00
+-1.00 -1.00
+3 3
+8 network 
+ 0
+560.00 332.00
+560.00 348.00
+560.00 348.00
+560.00 348.00
+-1.00 -1.00
+3 3
+3 IPC
+ 0
+304.00 212.00
+304.00 228.00
+304.00 228.00
+304.00 228.00
+-1.00 -1.00
+3 3
+7 support
+ 0
+304.00 236.00
+304.00 252.00
+304.00 252.00
+304.00 252.00
+-1.00 -1.00
+3 3
+6 memory
+ 0
+304.00 260.00
+304.00 276.00
+304.00 276.00
+304.00 276.00
+-1.00 -1.00
+3 3
+7 virtual
+ 0
+128.00 356.00
+128.00 372.00
+128.00 372.00
+128.00 372.00
+-1.00 -1.00
+3 3
+6 system
+ 0
+128.00 380.00
+128.00 396.00
+128.00 396.00
+128.00 396.00
+-1.00 -1.00
+3 3
+4 file
+ 0
+480.00 452.00
+480.00 468.00
+480.00 468.00
+480.00 468.00
+-1.00 -1.00
+3 3
+5 clock
+ 0
+288.00 380.00
+288.00 396.00
+288.00 396.00
+288.00 396.00
+-1.00 -1.00
+3 3
+7 support
+ 0
+288.00 404.00
+288.00 420.00
+288.00 420.00
+288.00 420.00
+-1.00 -1.00
+3 3
+7 process
+ 0
+448.00 572.00
+448.00 588.00
+448.00 588.00
+448.00 588.00
+-1.00 -1.00
+3 3
+12 system calls
+ 0
+456.00 628.00
+456.00 644.00
+456.00 644.00
+456.00 644.00
+-1.00 -1.00
+3 3
+9 C library
+ 0
+288.00 692.00
+288.00 708.00
+288.00 708.00
+288.00 708.00
+-1.00 -1.00
+3 3
+4 user
+ 0
+272.00 676.00
+272.00 692.00
+272.00 692.00
+272.00 692.00
+-1.00 -1.00
+3 3
+7 program
+ 0
+144.00 516.00
+144.00 532.00
+144.00 532.00
+144.00 532.00
+-1.00 -1.00
+3 3
+3 tty
+ 3
+568.00 612.00
+640.00 612.00
+-1.00 -1.00
+6 0
+0 
+ 3
+424.00 612.00
+64.00 612.00
+-1.00 -1.00
+6 0
+0 
+ 4
+496.00 612.00
+496.00 684.00
+496.00 540.00
+496.00 684.00
+568.00 612.00
+424.00 612.00
+-1.00 -1.00
+6 0
+0 
+ 4
+456.00 100.00
+456.00 164.00
+456.00 36.00
+456.00 164.00
+520.00 100.00
+392.00 100.00
+-1.00 -1.00
+6 0
+0 
+ 4
+336.00 244.00
+336.00 324.00
+336.00 164.00
+336.00 324.00
+416.00 244.00
+256.00 244.00
+-1.00 -1.00
+6 0
+0 
+ 4
+144.00 164.00
+144.00 212.00
+144.00 116.00
+144.00 212.00
+192.00 164.00
+96.00 164.00
+-1.00 -1.00
+6 0
+0 
+ 4
+144.00 372.00
+144.00 420.00
+144.00 324.00
+144.00 420.00
+192.00 372.00
+96.00 372.00
+-1.00 -1.00
+6 0
+0 
+ 4
+576.00 340.00
+576.00 388.00
+576.00 292.00
+576.00 388.00
+624.00 340.00
+528.00 340.00
+-1.00 -1.00
+6 0
+0 
+ 4
+496.00 452.00
+496.00 500.00
+496.00 404.00
+496.00 500.00
+544.00 452.00
+448.00 452.00
+-1.00 -1.00
+6 0
+0 
+ 4
+312.00 404.00
+312.00 452.00
+312.00 356.00
+312.00 452.00
+360.00 404.00
+264.00 404.00
+-1.00 -1.00
+6 0
+0 
+ 4
+160.00 532.00
+160.00 580.00
+160.00 484.00
+160.00 580.00
+208.00 532.00
+112.00 532.00
+-1.00 -1.00
+6 0
+0 
+ 4
+304.00 692.00
+304.00 740.00
+304.00 644.00
+304.00 740.00
+352.00 692.00
+256.00 692.00
+-1.00 -1.00
+6 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/func_units.nr b/share/doc/iso/wisc/figs/func_units.nr
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/share/doc/iso/wisc/figs/func_units.nr
diff --git a/share/doc/iso/wisc/figs/link_to_CONS_primitives.NR.DONT_REMOVE b/share/doc/iso/wisc/figs/link_to_CONS_primitives.NR.DONT_REMOVE
new file mode 100644
index 0000000..16dc3e0
--- /dev/null
+++ b/share/doc/iso/wisc/figs/link_to_CONS_primitives.NR.DONT_REMOVE
@@ -0,0 +1,77 @@
+.(b
+.TS
+tab(+) center expand box;
+c c 
+a | a .
+service primitive & arguments+provided by
+=
+N_CONNECT.request+cons_openvc(... faddr, ...)
+called address+argument faddr
+calling address+not implemented
+receipt confirmation+not implemented
+expedited data+not implemented
+quality of service+not implemented
+NS-user data+not implemented
+_
+N_CONNECT.indication+not implemented
+_
+N_CONNECT.response+cons_netcmd( CONN_REFUSE )
++ or cons_netcmd( CONN_CONFIRM )
++ however, net connection has already
++ been accepted.  If REFUSE, it will
++ be cleared with E_CO_HLI_REJT
++ (higher layer rejects connection)
+responding address+not implemented
+receipt confirmation+not implemented
+expedited data+not implemented
+quality of service+not implemented
+NS-user data+not implemented
+_
+N_CONNECT.confirm+not implemented
+=
+N_DATA.request+cons_output(... m, ...) 
++and cosns_output(... m, ...)
+confirmation+not implemented
+data+mbuf chain m
+_
+N_DATA.indication+pr_input( m, ... )
++or software interrupt
+confirmation+not implemented
+data+mbuf chain
+_
+N_DATA_ACKNOWLEDGE.request+not implemented
+_
+N_DATA_ACKNOWLEDGE.indication+not implemented
+_
+N_EXPEDITED_DATA.request+not implemented
+_
+N_EXPEDITED_DATA.indication+not implemented
+=
+N_RESET.request+not implemented
+N_RESET.indication+socket->so_error = reason
++or pr_ctlinput( PRC_ROUTEDEAD )
+originator+not implemented
+reason+from X.25 packet or ecn driver
+N_RESET.response+not implemented
+N_RESET.confirm+not implemented
+=
+N_DISCONNECT.request+cons_netcmd( CONN_CLOSE )
+reason+uses E_CO_HLI_DISCN (normal 
++disconnect from higher layer)
+responding address+not implemented
+NS_user data+not implemented
+_
+N_DISCONNECT.indication+socket->so_error = reason
++or pr_ctlinput( PRC_ROUTEDEAD )
+originator+not implemented
+reason+from X.25 packet or ecn driver
+responding address+not implemented
+NS_user data+not implemented
+.TE
+.(c
+\fBFigure \n+(FG\fR: Transport Service Primitives
+.)c
+.)b
+.(f
+\** data on disconnect is not supported at this time.
+.)f
diff --git a/share/doc/iso/wisc/figs/link_to_TS_primitives.NR.DONT_REMOVE b/share/doc/iso/wisc/figs/link_to_TS_primitives.NR.DONT_REMOVE
new file mode 100644
index 0000000..3d27df3
--- /dev/null
+++ b/share/doc/iso/wisc/figs/link_to_TS_primitives.NR.DONT_REMOVE
@@ -0,0 +1,60 @@
+.(b
+.TS
+center expand box;
+c c 
+a | a .
+service primitive & arguments	Unix system calls & arguments
+=
+T_CONNECT.request	\fIsocket(), connect(), setsockopt()\fR
+called address	\fIconnect()\fR argument
+calling address	\fIconnect()\fR argument
+quality of service	not implemented
+buffer management	\fIsetsockopt()\fR argument 
+security	not implemented
+data	\fIsetsockopt(), getsockopt()\fR
+_
+T_CONNECT.indication	return from \fIaccept(); getsockopt()\fR
+called address	\fIaccept()\fR argument
+calling address	\fIaccept()\fR argument
+quality of service	not implemented
+security	not implemented
+data	\fIsetsockopt(), getsockopt()\fR
+_
+T_CONNECT.response	no applicable system calls
+_
+T_CONNECT.confirm	return from \fIconnect()\fR
+quality of service	\fIgetsockopt()\fR argument
+data	\fIsetsocktopt, getsockopt()\fR
+=
+T_DATA.request	\fIrecvv(), sendv()\fR
+_
+T_DATA.indication	return from \fIrecvv()\fR, \fIsendv()\fR, or \fIselect()\fR; 
+	or signal SIGIO 
+	ioctl(FIONREAD) tells how much has been
+	queued to read
+=
+T_EXPEDITED_DATA.request	\fIsendv()\fR with MSG_OOB flag
+_
+T_EXPEDITED_DATA.indication	SIGURG, \fIgetsockopt()\fR with TPFLAG_XPD,
+	return from \fIselect()\fR with exceptional 
+	conditions mask
+=
+T_DISCONNECT.request	\fIclose()\fR
+data	\fIsetsockopt()\fR
+_
+T_DISCONNECT.indication	SIGURG, 
+	error return on other primitives
+reason	 errno
+data	\fIgetsockopt()\**\fR
+=
+T_STATUS.request	\fIgetsockopt()\fR, \fItpstat\fR utility program
+_
+T_STATUS.indication	\fIgetsockopt()\fR, \fIselect()\fR, \fItpstat\fR 
+.TE
+.(c
+\fBFigure \n+(FG\fR: Transport Service Primitives
+.)c
+.)b
+.(f
+\** data on disconnect is not supported at this time.
+.)f
diff --git a/share/doc/iso/wisc/figs/mbufrcv.grn b/share/doc/iso/wisc/figs/mbufrcv.grn
new file mode 100644
index 0000000..0f3fa52
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufrcv.grn
@@ -0,0 +1,13 @@
+.(z
+.GS C
+width 5.0
+high 6.0
+narrow 1
+medium 3
+thick 7
+pointscale on
+file mbufrcv.gsrc
+.GE
+.ce
+\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket receive buffer
+.)z
diff --git a/share/doc/iso/wisc/figs/mbufrcv.gsrc b/share/doc/iso/wisc/figs/mbufrcv.gsrc
new file mode 100644
index 0000000..1577804
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufrcv.gsrc
@@ -0,0 +1,1006 @@
+gremlinfile
+0 328.00 496.00
+0
+328.00 224.00
+328.00 234.00
+328.00 234.00
+328.00 234.00
+-1.00 -1.00
+1 1
+7 MT_DATA
+ 0
+328.00 400.00
+328.00 410.00
+328.00 410.00
+328.00 410.00
+-1.00 -1.00
+1 1
+7 MT_DATA
+ 0
+328.00 576.00
+328.00 586.00
+328.00 586.00
+328.00 586.00
+-1.00 -1.00
+1 1
+7 MT_DATA
+ 0
+72.00 576.00
+72.00 586.00
+72.00 586.00
+72.00 586.00
+-1.00 -1.00
+1 1
+7 MT_DATA
+ 3
+384.00 256.00
+416.00 256.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 272.00
+416.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 272.00
+432.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 240.00
+432.00 272.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 416.00
+432.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 448.00
+432.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 448.00
+416.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 432.00
+416.00 432.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 432.00
+160.00 432.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 448.00
+160.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+176.00 448.00
+176.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 416.00
+176.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 512.00
+288.00 512.00
+-1.00 -1.00
+5 0
+0 
+ 3
+512.00 528.00
+512.00 496.00
+528.00 528.00
+528.00 496.00
+-1.00 -1.00
+5 0
+0 
+ 3
+496.00 512.00
+512.00 512.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 320.00
+176.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+176.00 352.00
+176.00 320.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 352.00
+160.00 320.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 336.00
+160.00 336.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 144.00
+432.00 176.00
+-1.00 -1.00
+5 0
+0 
+ 3
+512.00 592.00
+528.00 624.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 496.00
+304.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 176.00
+432.00 144.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 176.00
+416.00 144.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 160.00
+416.00 160.00
+-1.00 -1.00
+5 0
+0 
+ 3
+304.00 528.00
+304.00 496.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 528.00
+288.00 496.00
+-1.00 -1.00
+5 0
+0 
+ 3
+528.00 624.00
+528.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+512.00 624.00
+512.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+496.00 608.00
+512.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 272.00
+349.00 277.00
+352.00 275.00
+355.00 277.00
+352.00 272.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 288.00
+352.00 272.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 288.00
+352.00 288.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 336.00
+416.00 288.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 336.00
+416.00 336.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 448.00
+349.00 453.00
+352.00 451.00
+355.00 453.00
+352.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 464.00
+352.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 464.00
+352.00 464.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 512.00
+416.00 464.00
+-1.00 -1.00
+5 0
+0 
+ 3
+96.00 448.00
+93.00 453.00
+96.00 451.00
+99.00 453.00
+96.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+96.00 464.00
+96.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 464.00
+96.00 464.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 512.00
+160.00 464.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 512.00
+416.00 512.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 512.00
+160.00 512.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 608.00
+427.00 605.00
+429.00 608.00
+427.00 611.00
+432.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 608.00
+432.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 608.00
+315.00 605.00
+317.00 608.00
+315.00 611.00
+320.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+192.00 608.00
+187.00 605.00
+189.00 608.00
+187.00 611.00
+192.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 608.00
+320.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+128.00 608.00
+192.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 624.00
+432.00 496.00
+496.00 496.00
+496.00 624.00
+432.00 624.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 592.00
+496.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+432.00 528.00
+432.00 528.00
+496.00 528.00
+496.00 528.00
+432.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 0
+448.00 512.00
+448.00 522.00
+448.00 522.00
+448.00 522.00
+-1.00 -1.00
+1 1
+6 m_next
+ 0
+448.00 608.00
+448.00 618.00
+448.00 618.00
+448.00 618.00
+-1.00 -1.00
+1 1
+5 m_act
+ 3
+432.00 576.00
+432.00 576.00
+496.00 576.00
+496.00 576.00
+432.00 576.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 224.00
+320.00 224.00
+384.00 224.00
+384.00 224.00
+320.00 224.00
+-1.00 -1.00
+5 0
+0 
+ 0
+336.00 256.00
+336.00 266.00
+336.00 266.00
+336.00 266.00
+-1.00 -1.00
+1 1
+5 m_act
+ 0
+336.00 160.00
+336.00 170.00
+336.00 170.00
+336.00 170.00
+-1.00 -1.00
+1 1
+6 m_next
+ 3
+320.00 176.00
+320.00 176.00
+384.00 176.00
+384.00 176.00
+320.00 176.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 240.00
+384.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 272.00
+320.00 144.00
+384.00 144.00
+384.00 272.00
+320.00 272.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 448.00
+320.00 320.00
+384.00 320.00
+384.00 448.00
+320.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 416.00
+384.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 352.00
+320.00 352.00
+384.00 352.00
+384.00 352.00
+320.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 0
+336.00 336.00
+336.00 346.00
+336.00 346.00
+336.00 346.00
+-1.00 -1.00
+1 1
+6 m_next
+ 0
+336.00 432.00
+336.00 442.00
+336.00 442.00
+336.00 442.00
+-1.00 -1.00
+1 1
+5 m_act
+ 3
+320.00 400.00
+320.00 400.00
+384.00 400.00
+384.00 400.00
+320.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 576.00
+320.00 576.00
+384.00 576.00
+384.00 576.00
+320.00 576.00
+-1.00 -1.00
+5 0
+0 
+ 0
+336.00 608.00
+336.00 618.00
+336.00 618.00
+336.00 618.00
+-1.00 -1.00
+1 1
+5 m_act
+ 0
+336.00 512.00
+336.00 522.00
+336.00 522.00
+336.00 522.00
+-1.00 -1.00
+1 1
+6 m_next
+ 3
+320.00 528.00
+320.00 528.00
+384.00 528.00
+384.00 528.00
+320.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 592.00
+384.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 624.00
+320.00 496.00
+384.00 496.00
+384.00 624.00
+320.00 624.00
+-1.00 -1.00
+5 0
+0 
+ 3
+192.00 624.00
+192.00 496.00
+256.00 496.00
+256.00 624.00
+192.00 624.00
+-1.00 -1.00
+5 0
+0 
+ 3
+192.00 592.00
+256.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+192.00 528.00
+192.00 528.00
+256.00 528.00
+256.00 528.00
+192.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 0
+208.00 512.00
+208.00 522.00
+208.00 522.00
+208.00 522.00
+-1.00 -1.00
+1 1
+6 m_next
+ 0
+208.00 608.00
+208.00 618.00
+208.00 618.00
+208.00 618.00
+-1.00 -1.00
+1 1
+5 m_act
+ 3
+192.00 576.00
+192.00 576.00
+256.00 576.00
+256.00 576.00
+192.00 576.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 400.00
+64.00 400.00
+128.00 400.00
+128.00 400.00
+64.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 0
+80.00 432.00
+80.00 442.00
+80.00 442.00
+80.00 442.00
+-1.00 -1.00
+1 1
+5 m_act
+ 0
+80.00 336.00
+80.00 346.00
+80.00 346.00
+80.00 346.00
+-1.00 -1.00
+1 1
+6 m_next
+ 3
+64.00 352.00
+64.00 352.00
+128.00 352.00
+128.00 352.00
+64.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 416.00
+128.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 448.00
+64.00 320.00
+128.00 320.00
+128.00 448.00
+64.00 448.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 576.00
+64.00 576.00
+128.00 576.00
+128.00 576.00
+64.00 576.00
+-1.00 -1.00
+5 0
+0 
+ 0
+80.00 608.00
+80.00 618.00
+80.00 618.00
+80.00 618.00
+-1.00 -1.00
+1 1
+5 m_act
+ 0
+80.00 512.00
+80.00 522.00
+80.00 522.00
+80.00 522.00
+-1.00 -1.00
+1 1
+6 m_next
+ 3
+64.00 528.00
+64.00 528.00
+128.00 528.00
+128.00 528.00
+64.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 592.00
+128.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 624.00
+64.00 496.00
+128.00 496.00
+128.00 624.00
+64.00 624.00
+-1.00 -1.00
+5 0
+0 
+ 0
+74.00 401.00
+74.00 411.00
+74.00 411.00
+74.00 411.00
+-1.00 -1.00
+1 1
+6 MT_EOT
+ 0
+207.00 577.00
+207.00 587.00
+207.00 587.00
+207.00 587.00
+-1.00 -1.00
+1 1
+6 MT_EOT
+ 0
+446.00 575.00
+446.00 585.00
+446.00 585.00
+446.00 585.00
+-1.00 -1.00
+1 1
+6 MT_EOT
+ 3
+80.00 576.00
+80.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+72.00 576.00
+72.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+88.00 576.00
+88.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+96.00 576.00
+96.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+104.00 576.00
+104.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+112.00 576.00
+112.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+120.00 576.00
+120.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+80.00 400.00
+80.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+72.00 400.00
+72.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+88.00 400.00
+88.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+96.00 400.00
+96.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+104.00 400.00
+104.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+112.00 400.00
+112.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+120.00 400.00
+120.00 376.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 552.00
+336.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 552.00
+328.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+344.00 552.00
+344.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+352.00 552.00
+352.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+360.00 552.00
+360.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+368.00 552.00
+368.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+376.00 552.00
+376.00 528.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 400.00
+336.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 400.00
+328.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+344.00 400.00
+344.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+352.00 400.00
+352.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+360.00 400.00
+360.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+368.00 400.00
+368.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+376.00 400.00
+376.00 352.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 208.00
+328.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 208.00
+336.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+352.00 208.00
+352.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+344.00 208.00
+344.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+360.00 208.00
+360.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+368.00 208.00
+368.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 3
+376.00 208.00
+376.00 192.00
+-1.00 -1.00
+1 0
+0 
+ 0
+64.00 640.00
+64.00 650.00
+64.00 650.00
+64.00 650.00
+-1.00 -1.00
+1 1
+10 first TSDU
+ 0
+192.00 640.00
+192.00 650.00
+192.00 650.00
+192.00 650.00
+-1.00 -1.00
+1 1
+11 second TSDU
+ 0
+320.00 640.00
+320.00 650.00
+320.00 650.00
+320.00 650.00
+-1.00 -1.00
+1 1
+9 last TSDU
+ 0
+64.00 688.00
+64.00 698.00
+64.00 698.00
+64.00 698.00
+-1.00 -1.00
+1 1
+16 so->so_rcv.sb_mb
+ 3
+48.00 704.00
+48.00 672.00
+160.00 672.00
+160.00 704.00
+48.00 704.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 688.00
+32.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 3
+32.00 688.00
+32.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+32.00 608.00
+64.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 3
+64.00 608.00
+59.00 605.00
+61.00 608.00
+59.00 611.00
+64.00 608.00
+-1.00 -1.00
+5 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/mbufrcv.nr b/share/doc/iso/wisc/figs/mbufrcv.nr
new file mode 100644
index 0000000..af35c70
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufrcv.nr
@@ -0,0 +1,504 @@
+.(z
+.br
+.nr g1 2880u
+.nr g2 3250u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D't 1u'
+.sp -1
+.sp 557u
+\h'186u'\D'l -29u 18u'\D'l 12u -18u'\D'l -12u -17u'\D'l 29u 17u'
+.sp -1
+\D'l 186u 0u'
+.sp -1
+.sp -464u
+\D'l 0u 464u'
+.sp -1
+\h'93u'\D'l -93u 0u'
+.sp -1
+.sp -93u
+\h'93u'\D'l 0u 186u'\D'l 651u 0u'\D'l 0u -186u'\D'l -651u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "so->so_rcv.sb_mb
+.sp 93u
+\h'186u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "last TSDU
+.sp 371u
+\h'1673u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "second TSDU
+.sp 371u
+\h'929u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "first TSDU
+.sp 371u
+\h'186u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'
+.sp -1
+.sp 2879u
+\h'1998u'\D'l 0u 93u'
+.sp -1
+\h'1951u'\D'l 0u 93u'
+.sp -1
+\h'1905u'\D'l 0u 93u'
+.sp -1
+\h'1812u'\D'l 0u 93u'
+.sp -1
+\h'1858u'\D'l 0u 93u'
+.sp -1
+\h'1765u'\D'l 0u 93u'
+.sp -1
+\h'1719u'\D'l 0u 93u'
+.sp -1
+.sp -1115u
+\h'1998u'\D'l 0u 279u'
+.sp -1
+\h'1951u'\D'l 0u 279u'
+.sp -1
+\h'1905u'\D'l 0u 279u'
+.sp -1
+\h'1858u'\D'l 0u 279u'
+.sp -1
+\h'1812u'\D'l 0u 279u'
+.sp -1
+\h'1719u'\D'l 0u 279u'
+.sp -1
+\h'1765u'\D'l 0u 279u'
+.sp -1
+.sp -882u
+\h'1998u'\D'l 0u 140u'
+.sp -1
+\h'1951u'\D'l 0u 140u'
+.sp -1
+\h'1905u'\D'l 0u 140u'
+.sp -1
+\h'1858u'\D'l 0u 140u'
+.sp -1
+\h'1812u'\D'l 0u 140u'
+.sp -1
+\h'1719u'\D'l 0u 140u'
+.sp -1
+\h'1765u'\D'l 0u 140u'
+.sp -1
+.sp 882u
+\h'511u'\D'l 0u 139u'
+.sp -1
+\h'465u'\D'l 0u 139u'
+.sp -1
+\h'418u'\D'l 0u 139u'
+.sp -1
+\h'372u'\D'l 0u 139u'
+.sp -1
+\h'325u'\D'l 0u 139u'
+.sp -1
+\h'233u'\D'l 0u 139u'
+.sp -1
+\h'279u'\D'l 0u 139u'
+.sp -1
+.sp -1021u
+\h'511u'\D'l 0u 279u'
+.sp -1
+\h'465u'\D'l 0u 279u'
+.sp -1
+\h'418u'\D'l 0u 279u'
+.sp -1
+\h'372u'\D'l 0u 279u'
+.sp -1
+\h'325u'\D'l 0u 279u'
+.sp -1
+\h'233u'\D'l 0u 279u'
+.sp -1
+\h'279u'\D'l 0u 279u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_EOT
+.sp 6u
+\h'2404u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_EOT
+.sp -6u
+\h'1016u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_EOT
+.sp 1015u
+\h'244u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp -279u
+\h'186u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
+.sp -1
+.sp 186u
+\h'186u'\D'l 372u 0u'
+.sp -1
+.sp 372u
+\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 93u
+\h'279u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -465u
+\h'279u'\&\*(g9
+.sp |\n(g8u
+.sp -279u
+\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.sp 742u
+\h'186u'\D'l 0u 744u'\D'l 372u 0u'\D'l 0u -744u'\D'l -372u 0u'
+.sp -1
+.sp 186u
+\h'186u'\D'l 372u 0u'
+.sp -1
+.sp 372u
+\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 93u
+\h'279u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -465u
+\h'279u'\&\*(g9
+.sp |\n(g8u
+.sp -279u
+\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.sp -1021u
+\h'929u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -186u
+\h'1022u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 372u
+\h'1022u'\&\*(g9
+.sp |\n(g8u
+.sp 279u
+\h'929u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.sp -372u
+\h'929u'\D'l 372u 0u'
+.sp -1
+.sp -186u
+\h'929u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
+.sp -1
+\h'1673u'\D'l 0u 743u'\D'l 371u 0u'\D'l 0u -743u'\D'l -371u 0u'
+.sp -1
+.sp 186u
+\h'1673u'\D'l 371u 0u'
+.sp -1
+.sp 372u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 93u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -465u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.sp -279u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.sp 1021u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -186u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 372u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.sp 279u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.sp -372u
+\h'1673u'\D'l 371u 0u'
+.sp -1
+.sp -186u
+\h'1673u'\D'l 0u 744u'\D'l 371u 0u'\D'l 0u -744u'\D'l -371u 0u'
+.sp -1
+.sp 1022u
+\h'1673u'\D'l 0u 743u'\D'l 371u 0u'\D'l 0u -743u'\D'l -371u 0u'
+.sp -1
+.sp 186u
+\h'1673u'\D'l 371u 0u'
+.sp -1
+.sp 372u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 93u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -465u
+\h'1765u'\&\*(g9
+.sp |\n(g8u
+.sp -279u
+\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
+.sp -1
+.sp -2043u
+\h'2323u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -186u
+\h'2416u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 372u
+\h'2416u'\&\*(g9
+.sp |\n(g8u
+.sp 279u
+\h'2323u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
+.sp -1
+.sp -372u
+\h'2323u'\D'l 372u 0u'
+.sp -1
+.sp -186u
+\h'2323u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
+.sp -1
+.sp 93u
+\h'558u'\D'l 371u 0u'
+.sp -1
+\h'1301u'\D'l 372u 0u'
+.sp -1
+\h'929u'\D'l -29u 18u'\D'l 12u -18u'\D'l -12u -17u'\D'l 29u 17u'
+.sp -1
+\h'1673u'\D'l -29u 18u'\D'l 11u -18u'\D'l -11u -17u'\D'l 29u 17u'
+.sp -1
+\h'2044u'\D'l 279u 0u'
+.sp -1
+\h'2323u'\D'l -29u 18u'\D'l 11u -18u'\D'l -11u -17u'\D'l 29u 17u'
+.sp -1
+.sp 558u
+\h'558u'\D'l 186u 0u'
+.sp -1
+\h'2044u'\D'l 186u 0u'
+.sp -1
+\h'744u'\D'l 0u 277u'
+.sp -1
+.sp 277u
+\h'744u'\D'l -372u 0u'
+.sp -1
+\h'372u'\D'l 0u 93u'
+.sp -1
+.sp 93u
+\h'372u'\D'l -17u -29u'\D'l 17u 12u'\D'l 17u -12u'\D'l -17u 29u'
+.sp -1
+.sp -370u
+\h'2230u'\D'l 0u 277u'
+.sp -1
+.sp 277u
+\h'2230u'\D'l -372u 0u'
+.sp -1
+\h'1858u'\D'l 0u 93u'
+.sp -1
+.sp 93u
+\h'1858u'\D'l -17u -29u'\D'l 17u 12u'\D'l 18u -12u'\D'l -18u 29u'
+.sp -1
+.sp 651u
+\h'2044u'\D'l 186u 0u'
+.sp -1
+\h'2230u'\D'l 0u 278u'
+.sp -1
+.sp 278u
+\h'2230u'\D'l -372u 0u'
+.sp -1
+\h'1858u'\D'l 0u 93u'
+.sp -1
+.sp 93u
+\h'1858u'\D'l -17u -29u'\D'l 17u 12u'\D'l 18u -12u'\D'l -18u 29u'
+.sp -1
+.sp -1950u
+\h'2695u'\D'l 92u 0u'
+.sp -1
+.sp -93u
+\h'2787u'\D'l 0u 186u'
+.sp -1
+\h'2880u'\D'l 0u 186u'
+.sp -1
+.sp 558u
+\h'1487u'\D'l 0u 185u'
+.sp -1
+\h'1580u'\D'l 0u 185u'
+.sp -1
+.sp 2136u
+\h'2044u'\D'l 186u 0u'
+.sp -1
+.sp -93u
+\h'2230u'\D'l 0u 185u'
+.sp -1
+\h'2323u'\D'l 0u 185u'
+.sp -1
+.sp -1858u
+\h'1487u'\D'l 93u -185u'
+.sp -1
+.sp -557u
+\h'2787u'\D'l 93u -186u'
+.sp -1
+.sp 2600u
+\h'2230u'\D'l 93u -185u'
+.sp -1
+.sp -1114u
+\h'558u'\D'l 186u 0u'
+.sp -1
+.sp -93u
+\h'744u'\D'l 0u 186u'
+.sp -1
+\h'836u'\D'l 0u 186u'
+.sp -1
+.sp 186u
+\h'744u'\D'l 92u -186u'
+.sp -1
+.sp -1114u
+\h'2695u'\D'l 92u 0u'
+.sp -1
+.sp -93u
+\h'2787u'\D'l 0u 185u'\D'l 93u -185u'\D'l 0u 185u'
+.sp -1
+.sp 93u
+\h'1301u'\D'l 186u 0u'
+.sp -1
+.sp 556u
+\h'744u'\D'l 92u -186u'
+.sp -1
+.sp -186u
+\h'836u'\D'l 0u 186u'
+.sp -1
+\h'744u'\D'l 0u 186u'
+.sp -1
+.sp 93u
+\h'558u'\D'l 186u 0u'
+.sp -1
+\h'2044u'\D'l 186u 0u'
+.sp -1
+.sp -93u
+\h'2230u'\D'l 0u 186u'
+.sp -1
+\h'2323u'\D'l 0u 186u'
+.sp -1
+.sp 186u
+\h'2230u'\D'l 93u -186u'
+.sp -1
+.sp 1022u
+\h'2230u'\D'l 93u -186u'
+.sp -1
+.sp -186u
+\h'2323u'\D'l 0u 186u'
+.sp -1
+\h'2230u'\D'l 0u 186u'
+.sp -1
+.sp 93u
+\h'2044u'\D'l 186u 0u'
+.sp -1
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_DATA
+.sp -1857u
+\h'233u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_DATA
+.sp -1857u
+\h'1719u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_DATA
+.sp -836u
+\h'1719u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 5
+.nr g8 \n(.d
+.ds g9 "MT_DATA
+.sp 186u
+\h'1719u'\&\*(g9
+.sp |\n(g8u
+.sp 650u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket receive buffer
+.)z
diff --git a/share/doc/iso/wisc/figs/mbufsnd.grn b/share/doc/iso/wisc/figs/mbufsnd.grn
new file mode 100644
index 0000000..9b7ac5e
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufsnd.grn
@@ -0,0 +1,13 @@
+.(z
+.GS C
+width 5.0
+high 6.0
+narrow 1
+medium 3
+thick 7
+pointscale on
+file mbufsnd.gsrc
+.GE
+.ce
+\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket send buffer
+.)z
diff --git a/share/doc/iso/wisc/figs/mbufsnd.gsrc b/share/doc/iso/wisc/figs/mbufsnd.gsrc
new file mode 100644
index 0000000..8e2f0a8
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufsnd.gsrc
@@ -0,0 +1,534 @@
+gremlinfile
+0 124.00 410.00
+0
+124.00 310.00
+124.00 320.00
+124.00 320.00
+124.00 320.00
+-1.00 -1.00
+1 1
+12 == user data
+ 3
+71.00 343.00
+71.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+79.00 343.00
+79.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+87.00 343.00
+87.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+95.00 343.00
+95.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+103.00 343.00
+103.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+111.00 343.00
+111.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+119.00 343.00
+119.00 295.00
+-1.00 -1.00
+1 0
+0 
+ 3
+160.00 688.00
+256.00 688.00
+160.00 688.00
+256.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 512.00
+352.00 512.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 528.00
+352.00 496.00
+368.00 528.00
+368.00 496.00
+-1.00 -1.00
+5 0
+0 
+ 0
+264.00 656.00
+264.00 666.00
+264.00 666.00
+264.00 666.00
+-1.00 -1.00
+1 1
+7 MT_DATA
+ 3
+256.00 480.00
+320.00 480.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 480.00
+272.00 490.00
+272.00 490.00
+272.00 490.00
+-1.00 -1.00
+1 1
+6 MT_XPD
+ 3
+312.00 304.00
+312.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+304.00 304.00
+304.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+296.00 304.00
+296.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+288.00 304.00
+288.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+280.00 304.00
+280.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+264.00 304.00
+264.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+272.00 304.00
+272.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 3
+256.00 304.00
+256.00 304.00
+320.00 304.00
+320.00 304.00
+256.00 304.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 256.00
+256.00 256.00
+320.00 256.00
+320.00 256.00
+256.00 256.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 352.00
+285.00 357.00
+288.00 355.00
+291.00 357.00
+288.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 416.00
+352.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 416.00
+352.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 352.00
+256.00 224.00
+320.00 224.00
+320.00 352.00
+256.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 368.00
+288.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 368.00
+288.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 704.00
+352.00 672.00
+368.00 704.00
+368.00 672.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 688.00
+352.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 0
+64.00 688.00
+64.00 698.00
+64.00 698.00
+64.00 698.00
+-1.00 -1.00
+1 1
+16 so->so_snd.sb_mb
+ 3
+256.00 688.00
+251.00 685.00
+253.00 688.00
+251.00 691.00
+256.00 688.00
+-1.00 -1.00
+5 0
+0 
+ 3
+48.00 704.00
+48.00 672.00
+160.00 672.00
+160.00 704.00
+48.00 704.00
+-1.00 -1.00
+5 0
+0 
+ 3
+312.00 656.00
+312.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+304.00 656.00
+304.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+296.00 656.00
+296.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+288.00 656.00
+288.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+280.00 656.00
+280.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+264.00 656.00
+264.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 3
+272.00 656.00
+272.00 608.00
+-1.00 -1.00
+1 0
+0 
+ 0
+271.00 305.00
+271.00 315.00
+271.00 315.00
+271.00 315.00
+-1.00 -1.00
+1 1
+6 MT_EOT
+ 3
+256.00 704.00
+256.00 576.00
+320.00 576.00
+320.00 704.00
+256.00 704.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 672.00
+320.00 672.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 608.00
+256.00 608.00
+320.00 608.00
+320.00 608.00
+256.00 608.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 592.00
+272.00 602.00
+272.00 602.00
+272.00 602.00
+-1.00 -1.00
+1 1
+6 m_next
+ 0
+272.00 688.00
+272.00 698.00
+272.00 698.00
+272.00 698.00
+-1.00 -1.00
+1 1
+5 m_act
+ 3
+256.00 656.00
+256.00 656.00
+320.00 656.00
+320.00 656.00
+256.00 656.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 528.00
+256.00 400.00
+320.00 400.00
+320.00 528.00
+256.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 496.00
+320.00 496.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 432.00
+256.00 432.00
+320.00 432.00
+320.00 432.00
+256.00 432.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 416.00
+272.00 426.00
+272.00 426.00
+272.00 426.00
+-1.00 -1.00
+1 1
+6 m_next
+ 0
+272.00 512.00
+272.00 522.00
+272.00 522.00
+272.00 522.00
+-1.00 -1.00
+1 1
+5 m_act
+ 3
+256.00 304.00
+256.00 304.00
+320.00 304.00
+320.00 304.00
+256.00 304.00
+-1.00 -1.00
+5 0
+0 
+ 0
+272.00 336.00
+272.00 346.00
+272.00 346.00
+272.00 346.00
+-1.00 -1.00
+1 1
+5 m_act
+ 0
+272.00 240.00
+272.00 250.00
+272.00 250.00
+272.00 250.00
+-1.00 -1.00
+1 1
+6 m_next
+ 3
+256.00 256.00
+256.00 256.00
+320.00 256.00
+320.00 256.00
+256.00 256.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 320.00
+320.00 320.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 352.00
+256.00 224.00
+320.00 224.00
+320.00 352.00
+256.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 592.00
+352.00 592.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 592.00
+352.00 544.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 544.00
+288.00 544.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 544.00
+288.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 528.00
+285.00 533.00
+288.00 531.00
+291.00 533.00
+288.00 528.00
+-1.00 -1.00
+5 0
+0 
+ 3
+320.00 240.00
+352.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 256.00
+352.00 224.00
+-1.00 -1.00
+5 0
+0 
+ 3
+368.00 256.00
+368.00 224.00
+-1.00 -1.00
+5 0
+0 
+ 3
+352.00 224.00
+368.00 256.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 472.00
+288.00 464.00
+-1.00 -1.00
+5 0
+0 
+ 0
+72.00 480.00
+72.00 490.00
+72.00 490.00
+72.00 490.00
+-1.00 -1.00
+1 1
+13 tpcb->tp_Xuna
+ 0
+72.00 464.00
+72.00 474.00
+72.00 474.00
+72.00 474.00
+-1.00 -1.00
+1 1
+18 sequence number of
+ 0
+72.00 448.00
+72.00 458.00
+72.00 458.00
+72.00 458.00
+-1.00 -1.00
+1 1
+8 XPD TPDU
+ 3
+288.00 464.00
+208.00 456.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 472.00
+208.00 480.00
+208.00 480.00
+-1.00 -1.00
+5 0
+0 
+ 3
+208.00 488.00
+184.00 472.00
+208.00 448.00
+-1.00 -1.00
+5 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/mbufsnd.nr b/share/doc/iso/wisc/figs/mbufsnd.nr
new file mode 100644
index 0000000..4b38574
--- /dev/null
+++ b/share/doc/iso/wisc/figs/mbufsnd.nr
@@ -0,0 +1,284 @@
+.(z
+.br
+.nr g1 2304u
+.nr g2 3455u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D't 1u'
+.sp -1
+.sp 1554u
+\h'1152u'\D'l -173u 115u'\D'l 173u 173u'
+.sp -1
+.sp 115u
+\h'1728u'\D'l -576u -57u'\D'l 0u 0u'
+.sp -1
+.sp 58u
+\h'1728u'\D'l -576u 57u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "XPD TPDU
+.sp 115u
+\h'173u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "sequence number of
+\h'173u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "tpcb->tp_Xuna
+.sp -115u
+\h'173u'\&\*(g9
+.sp |\n(g8u
+.sp -58u
+\h'1728u'\D'l 0u 58u'
+.sp -1
+.sp 1786u
+\h'2189u'\D'l 115u -231u'
+.sp -1
+.sp -231u
+\h'2304u'\D'l 0u 231u'
+.sp -1
+\h'2189u'\D'l 0u 231u'
+.sp -1
+.sp 116u
+\h'1959u'\D'l 230u 0u'
+.sp -1
+.sp -2073u
+\h'1728u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
+.sp -1
+.sp -115u
+\h'1728u'\D'l 0u 115u'
+.sp -1
+\h'2189u'\D'l -461u 0u'
+.sp -1
+.sp -346u
+\h'2189u'\D'l 0u 346u'
+.sp -1
+\h'1959u'\D'l 230u 0u'
+.sp -1
+.sp 1727u
+\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
+.sp -1
+.sp 231u
+\h'1498u'\D'l 461u 0u'
+.sp -1
+.sp 460u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 116u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -576u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.sp -345u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -1497u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp -807u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.sp -922u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.sp -461u
+\h'1498u'\D'l 461u 0u'
+.sp -1
+.sp -229u
+\h'1498u'\D'l 0u 921u'\D'l 461u 0u'\D'l 0u -921u'\D'l -461u 0u'
+.sp -1
+.sp -922u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_act
+.sp -230u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "m_next
+.sp 461u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+.sp 346u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.sp -461u
+\h'1498u'\D'l 461u 0u'
+.sp -1
+.sp -230u
+\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "MT_EOT
+.sp 2872u
+\h'1606u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'
+.sp -1
+.sp 345u
+\h'1613u'\D'l 0u 346u'
+.sp -1
+\h'1555u'\D'l 0u 346u'
+.sp -1
+\h'1670u'\D'l 0u 346u'
+.sp -1
+\h'1728u'\D'l 0u 346u'
+.sp -1
+\h'1786u'\D'l 0u 346u'
+.sp -1
+\h'1843u'\D'l 0u 346u'
+.sp -1
+\h'1901u'\D'l 0u 346u'
+.sp -1
+\D's -1u'
+.sp -1
+.sp -345u
+\D'l 0u 230u'\D'l 807u 0u'\D'l 0u -230u'\D'l -807u 0u'
+.sp -1
+.sp 115u
+\h'1498u'\D'l -36u 22u'\D'l 14u -22u'\D'l -14u -21u'\D'l 36u 21u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "so->so_snd.sb_mb
+\h'115u'\&\*(g9
+.sp |\n(g8u
+\h'1959u'\D'l 230u 0u'
+.sp -1
+.sp -115u
+\h'2189u'\D'l 0u 230u'\D'l 115u -230u'\D'l 0u 230u'
+.sp -1
+.sp 2418u
+\h'1728u'\D'l 0u 115u'
+.sp -1
+\h'2189u'\D'l -461u 0u'
+.sp -1
+.sp 115u
+\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
+.sp -1
+.sp -461u
+\h'2189u'\D'l 0u 346u'
+.sp -1
+\h'1959u'\D'l 230u 0u'
+.sp -1
+.sp 461u
+\h'1728u'\D'l -21u -36u'\D'l 21u 15u'\D'l 22u -15u'\D'l -22u 36u'
+.sp -1
+.sp 691u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+.sp -345u
+\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
+.sp -1
+\D's 4u'
+.sp -1
+\h'1613u'\D'l 0u 345u'
+.sp -1
+\h'1555u'\D'l 0u 345u'
+.sp -1
+\h'1670u'\D'l 0u 345u'
+.sp -1
+\h'1728u'\D'l 0u 345u'
+.sp -1
+\h'1786u'\D'l 0u 345u'
+.sp -1
+\h'1843u'\D'l 0u 345u'
+.sp -1
+\h'1901u'\D'l 0u 345u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "MT_XPD
+.sp -1267u
+\h'1613u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp -1267u
+\h'1498u'\D'l 461u 0u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "MT_DATA
+.sp -1267u
+\h'1555u'\&\*(g9
+.sp |\n(g8u
+.sp -345u
+\h'2189u'\D'l 0u 229u'\D'l 115u -229u'\D'l 0u 229u'
+.sp -1
+.sp 115u
+\h'1959u'\D'l 230u 0u'
+.sp -1
+.sp -1267u
+\h'807u'\D'l 691u 0u'\D'l -691u 0u'\D'l 691u 0u'
+.sp -1
+\D's 4u'
+.sp -1
+.sp 2483u
+\h'511u'\D'l 0u 346u'
+.sp -1
+\h'454u'\D'l 0u 346u'
+.sp -1
+\h'396u'\D'l 0u 346u'
+.sp -1
+\h'338u'\D'l 0u 346u'
+.sp -1
+\h'281u'\D'l 0u 346u'
+.sp -1
+\h'223u'\D'l 0u 346u'
+.sp -1
+\h'166u'\D'l 0u 346u'
+.sp -1
+.ft R
+.ps 6
+.nr g8 \n(.d
+.ds g9 "== user data
+.sp 238u
+\h'547u'\&\*(g9
+.sp |\n(g8u
+.sp 857u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket send buffer
+.)z
diff --git a/share/doc/iso/wisc/figs/osi_addr.grn b/share/doc/iso/wisc/figs/osi_addr.grn
new file mode 100644
index 0000000..333260b
--- /dev/null
+++ b/share/doc/iso/wisc/figs/osi_addr.grn
@@ -0,0 +1,18 @@
+.(z
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.4
+narrow 1
+medium 3
+thick 7
+pointscale off
+file osi_addr.gsrc
+.GE
+.ce
+\fB Figure \n+(FG\fR: Format of OSI addresses
+.)z
diff --git a/share/doc/iso/wisc/figs/osi_addr.gsrc b/share/doc/iso/wisc/figs/osi_addr.gsrc
new file mode 100644
index 0000000..0a69b96
--- /dev/null
+++ b/share/doc/iso/wisc/figs/osi_addr.gsrc
@@ -0,0 +1,62 @@
+gremlinfile
+0 87.01 78.31
+3
+87.01 641.69
+87.01 567.61
+349.25 567.61
+349.25 641.69
+87.01 641.69
+-1.00 -1.00
+5 0
+0 
+ 0
+138.15 617.43
+138.15 636.43
+138.15 636.43
+138.15 636.43
+-1.00 -1.00
+1 4
+3 IDP
+ 3
+212.23 641.69
+212.23 567.61
+-1.00 -1.00
+5 0
+0 
+ 3
+87.01 609.57
+212.23 609.57
+-1.00 -1.00
+5 0
+0 
+ 0
+98.81 585.31
+98.81 604.31
+98.81 604.31
+98.81 604.31
+-1.00 -1.00
+1 4
+3 AFI
+ 3
+149.29 610.22
+149.29 567.61
+-1.00 -1.00
+5 0
+0 
+ 0
+170.27 586.62
+170.27 605.62
+170.27 605.62
+170.27 605.62
+-1.00 -1.00
+1 4
+3 IDI
+ 0
+271.23 598.42
+271.23 617.42
+271.23 617.42
+271.23 617.42
+-1.00 -1.00
+1 4
+3 DSP
+ -1
diff --git a/share/doc/iso/wisc/figs/osi_addr.nr b/share/doc/iso/wisc/figs/osi_addr.nr
new file mode 100644
index 0000000..f4c88fa
--- /dev/null
+++ b/share/doc/iso/wisc/figs/osi_addr.nr
@@ -0,0 +1,59 @@
+.(z
+.br
+.nr g1 3456u
+.nr g2 1722u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+.ft R
+.ps 14
+.nr g8 \n(.d
+.ds g9 "DSP
+.sp 570u
+\h'2428u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 14
+.nr g8 \n(.d
+.ds g9 "IDI
+.sp 726u
+\h'1097u'\&\*(g9
+.sp |\n(g8u
+\D't 1u'
+.sp -1
+.sp 415u
+\h'821u'\D'l 0u 561u'
+.sp -1
+.ft R
+.ps 14
+.nr g8 \n(.d
+.ds g9 "AFI
+.sp 328u
+\h'156u'\&\*(g9
+.sp |\n(g8u
+.sp 8u
+\D'l 1650u 0u'
+.sp -1
+.sp -423u
+\h'1650u'\D'l 0u 976u'
+.sp -1
+.ft R
+.ps 14
+.nr g8 \n(.d
+.ds g9 "IDP
+.sp 320u
+\h'674u'\&\*(g9
+.sp |\n(g8u
+\D'l 0u 976u'\D'l 3456u 0u'\D'l 0u -976u'\D'l -3456u 0u'
+.sp -1
+.sp 1722u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG\fR: Format of OSI addresses
+.)z
diff --git a/share/doc/iso/wisc/figs/tppt.grn b/share/doc/iso/wisc/figs/tppt.grn
new file mode 100644
index 0000000..649c3d9
--- /dev/null
+++ b/share/doc/iso/wisc/figs/tppt.grn
@@ -0,0 +1,18 @@
+.(z
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.4
+narrow 1
+medium 3
+thick 7
+pointscale off
+file tppt.gsrc
+.GE
+.ce
+\fB Figure \n+(FG\fR: Output of tppt(8)
+.)z
diff --git a/share/doc/iso/wisc/figs/tppt.gsrc b/share/doc/iso/wisc/figs/tppt.gsrc
new file mode 100644
index 0000000..5643940
--- /dev/null
+++ b/share/doc/iso/wisc/figs/tppt.gsrc
@@ -0,0 +1,411 @@
+gremlinfile
+0 352.00 352.00
+0
+352.00 368.00
+352.00 381.00
+352.00 381.00
+352.00 381.00
+-1.00 -1.00
+2 2
+17 this is a CR TPDU
+ 3
+256.00 384.00
+256.00 400.00
+368.00 400.00
+368.00 384.00
+256.00 384.00
+-1.00 -1.00
+5 0
+0 
+ 0
+112.00 288.00
+112.00 302.00
+112.00 302.00
+112.00 302.00
+-1.00 -1.00
+1 3
+59 +12:  0x02  0x00  0x07  0xc0    20:  0x01  0x08  0x00  0x00
+ 0
+112.00 304.00
+112.00 318.00
+112.00 318.00
+112.00 318.00
+-1.00 -1.00
+1 3
+59 + 8:  0x06  0x74  0x70  0x70    12:  0x69  0x6e  0xc7  0xc2
+ 0
+112.00 320.00
+112.00 334.00
+112.00 334.00
+112.00 334.00
+-1.00 -1.00
+1 3
+59 + 0:  0x15  0xe0  0x00  0x00     4:  0x00  0x03  0x00  0xc1
+ 0
+160.00 208.00
+160.00 221.00
+160.00 221.00
+160.00 221.00
+-1.00 -1.00
+2 2
+17 class and options
+ 3
+112.00 208.00
+144.00 208.00
+-1.00 -1.00
+6 0
+0 
+ 3
+336.00 320.00
+368.00 320.00
+-1.00 -1.00
+6 0
+0 
+ 3
+80.00 352.00
+75.00 349.00
+77.00 352.00
+75.00 355.00
+80.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+96.00 288.00
+91.00 285.00
+93.00 288.00
+91.00 291.00
+96.00 288.00
+-1.00 -1.00
+5 0
+0 
+ 3
+96.00 288.00
+48.00 288.00
+48.00 240.00
+96.00 240.00
+-1.00 -1.00
+5 0
+0 
+ 0
+336.00 432.00
+336.00 445.00
+336.00 445.00
+336.00 445.00
+-1.00 -1.00
+2 2
+22 indicates a TPDU event
+ 0
+48.00 448.00
+48.00 461.00
+48.00 461.00
+48.00 461.00
+-1.00 -1.00
+2 2
+18 TPDU was received;
+ 0
+128.00 448.00
+128.00 461.00
+128.00 461.00
+128.00 461.00
+-1.00 -1.00
+2 2
+28 its total length is 22 bytes
+ 0
+48.00 432.00
+48.00 445.00
+48.00 445.00
+48.00 445.00
+-1.00 -1.00
+2 2
+26 and its header is 22 bytes
+ 0
+48.00 416.00
+48.00 429.00
+48.00 429.00
+48.00 429.00
+-1.00 -1.00
+2 2
+15 (21 in the LI +
+ 0
+112.00 416.00
+112.00 429.00
+112.00 429.00
+112.00 429.00
+-1.00 -1.00
+2 2
+13 1 for the LI)
+ 3
+112.00 240.00
+144.00 240.00
+-1.00 -1.00
+1 0
+0 
+ 0
+160.00 240.00
+160.00 253.00
+160.00 253.00
+160.00 253.00
+-1.00 -1.00
+2 2
+2 LI
+ 3
+208.00 320.00
+336.00 320.00
+-1.00 -1.00
+2 0
+0 
+ 3
+112.00 224.00
+144.00 224.00
+-1.00 -1.00
+2 0
+0 
+ 0
+160.00 224.00
+160.00 237.00
+160.00 237.00
+160.00 237.00
+-1.00 -1.00
+2 2
+16 dst-ref, src-ref
+ 3
+304.00 240.00
+336.00 240.00
+-1.00 -1.00
+3 0
+0 
+ 0
+352.00 240.00
+352.00 253.00
+352.00 253.00
+352.00 253.00
+-1.00 -1.00
+2 2
+26 calling transport selector
+ 3
+144.00 288.00
+224.00 288.00
+-1.00 -1.00
+4 0
+0 
+ 3
+304.00 224.00
+336.00 224.00
+-1.00 -1.00
+4 0
+0 
+ 0
+352.00 224.00
+352.00 237.00
+352.00 237.00
+352.00 237.00
+-1.00 -1.00
+2 2
+25 called transport selector
+ 3
+240.00 288.00
+336.00 288.00
+-1.00 -1.00
+5 0
+0 
+ 3
+304.00 208.00
+336.00 208.00
+-1.00 -1.00
+5 0
+0 
+ 0
+352.00 208.00
+352.00 221.00
+352.00 221.00
+352.00 221.00
+-1.00 -1.00
+2 2
+9 TPDU size
+ 3
+144.00 320.00
+192.00 320.00
+-1.00 -1.00
+1 0
+0 
+ 0
+176.00 240.00
+176.00 253.00
+176.00 253.00
+176.00 253.00
+-1.00 -1.00
+2 2
+11 , TPDU type
+ 3
+400.00 432.00
+400.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+400.00 400.00
+397.00 405.00
+400.00 403.00
+403.00 405.00
+400.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+368.00 400.00
+368.00 384.00
+432.00 384.00
+432.00 400.00
+368.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 0
+384.00 384.00
+384.00 398.00
+384.00 398.00
+384.00 398.00
+-1.00 -1.00
+1 3
+4 tpdu
+ 3
+80.00 352.00
+48.00 352.00
+48.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+96.00 336.00
+96.00 272.00
+416.00 272.00
+416.00 336.00
+96.00 336.00
+-1.00 -1.00
+5 0
+0 
+ 3
+80.00 368.00
+80.00 336.00
+224.00 336.00
+224.00 368.00
+80.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 0
+96.00 352.00
+96.00 366.00
+96.00 366.00
+96.00 366.00
+-1.00 -1.00
+1 3
+19 INPUT  total len 22
+ 0
+96.00 336.00
+96.00 350.00
+96.00 350.00
+96.00 350.00
+-1.00 -1.00
+1 3
+13 HDRLEN: 21+1 
+ 3
+224.00 352.00
+224.00 336.00
+320.00 336.00
+320.00 352.00
+224.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 0
+240.00 336.00
+240.00 350.00
+240.00 350.00
+240.00 350.00
+-1.00 -1.00
+1 3
+12 CR_TPDU_type
+ 0
+336.00 336.00
+336.00 350.00
+336.00 350.00
+336.00 350.00
+-1.00 -1.00
+1 3
+23 cdt 0(0x0)     dref 0x0
+ 3
+288.00 352.00
+285.00 357.00
+288.00 355.00
+291.00 357.00
+288.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 352.00
+288.00 368.00
+352.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 0
+80.00 144.00
+80.00 158.00
+80.00 158.00
+80.00 158.00
+-1.00 -1.00
+1 3
+24 1a: Ref 22   arg 14(0xe)
+ 0
+256.00 384.00
+256.00 398.00
+256.00 398.00
+256.00 398.00
+-1.00 -1.00
+1 3
+22 @ 91990  : 0000.435125
+ 3
+288.00 400.00
+285.00 405.00
+288.00 403.00
+291.00 405.00
+288.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+288.00 400.00
+288.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 0
+240.00 416.00
+240.00 429.00
+240.00 429.00
+240.00 429.00
+-1.00 -1.00
+2 2
+30 event # : time since 1st event
+ 3
+368.00 320.00
+384.00 320.00
+-1.00 -1.00
+3 0
+0 
+ 3
+144.00 304.00
+336.00 304.00
+-1.00 -1.00
+3 0
+0 
+ 3
+336.00 304.00
+384.00 304.00
+-1.00 -1.00
+4 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/tppt.gsrc.save b/share/doc/iso/wisc/figs/tppt.gsrc.save
new file mode 100644
index 0000000..3ad56ef
--- /dev/null
+++ b/share/doc/iso/wisc/figs/tppt.gsrc.save
@@ -0,0 +1,335 @@
+gremlinfile
+0 240.00 464.00
+0
+240.00 256.00
+240.00 269.00
+240.00 269.00
+240.00 269.00
+-1.00 -1.00
+2 2
+11 , TPDU type
+ 3
+208.00 320.00
+256.00 320.00
+-1.00 -1.00
+1 0
+0 
+ 0
+224.00 192.00
+224.00 205.00
+224.00 205.00
+224.00 205.00
+-1.00 -1.00
+2 2
+9 TPDU size
+ 3
+176.00 192.00
+208.00 192.00
+-1.00 -1.00
+5 0
+0 
+ 3
+304.00 288.00
+400.00 288.00
+-1.00 -1.00
+5 0
+0 
+ 0
+224.00 208.00
+224.00 221.00
+224.00 221.00
+224.00 221.00
+-1.00 -1.00
+2 2
+25 called transport selector
+ 3
+176.00 208.00
+208.00 208.00
+-1.00 -1.00
+4 0
+0 
+ 3
+208.00 288.00
+288.00 288.00
+-1.00 -1.00
+4 0
+0 
+ 3
+432.00 304.00
+464.00 304.00
+-1.00 -1.00
+4 0
+0 
+ 3
+160.00 336.00
+160.00 272.00
+480.00 272.00
+480.00 336.00
+160.00 336.00
+-1.00 -1.00
+5 0
+0 
+ 0
+224.00 224.00
+224.00 237.00
+224.00 237.00
+224.00 237.00
+-1.00 -1.00
+2 2
+26 calling transport selector
+ 3
+176.00 224.00
+208.00 224.00
+-1.00 -1.00
+3 0
+0 
+ 3
+208.00 304.00
+432.00 304.00
+-1.00 -1.00
+3 0
+0 
+ 3
+432.00 320.00
+464.00 320.00
+-1.00 -1.00
+3 0
+0 
+ 0
+224.00 240.00
+224.00 253.00
+224.00 253.00
+224.00 253.00
+-1.00 -1.00
+2 2
+16 dst-ref, src-ref
+ 3
+176.00 240.00
+208.00 240.00
+-1.00 -1.00
+2 0
+0 
+ 3
+272.00 320.00
+400.00 320.00
+-1.00 -1.00
+2 0
+0 
+ 0
+224.00 256.00
+224.00 269.00
+224.00 269.00
+224.00 269.00
+-1.00 -1.00
+2 2
+2 LI
+ 3
+176.00 256.00
+208.00 256.00
+-1.00 -1.00
+1 0
+0 
+ 0
+48.00 416.00
+48.00 429.00
+48.00 429.00
+48.00 429.00
+-1.00 -1.00
+2 2
+13 1 for the LI)
+ 0
+48.00 432.00
+48.00 445.00
+48.00 445.00
+48.00 445.00
+-1.00 -1.00
+2 2
+15 (21 in the LI +
+ 0
+48.00 448.00
+48.00 461.00
+48.00 461.00
+48.00 461.00
+-1.00 -1.00
+2 2
+26 and its header is 22 bytes
+ 0
+48.00 464.00
+48.00 477.00
+48.00 477.00
+48.00 477.00
+-1.00 -1.00
+2 2
+28 its total length is 22 bytes
+ 0
+48.00 480.00
+48.00 493.00
+48.00 493.00
+48.00 493.00
+-1.00 -1.00
+2 2
+18 TPDU was received;
+ 0
+176.00 416.00
+176.00 429.00
+176.00 429.00
+176.00 429.00
+-1.00 -1.00
+2 2
+17 TPDU is a CR TPDU
+ 0
+368.00 432.00
+368.00 445.00
+368.00 445.00
+368.00 445.00
+-1.00 -1.00
+2 2
+22 indicates a TPDU event
+ 3
+160.00 304.00
+112.00 304.00
+112.00 256.00
+160.00 256.00
+-1.00 -1.00
+5 0
+0 
+ 3
+160.00 304.00
+155.00 301.00
+157.00 304.00
+155.00 307.00
+160.00 304.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 352.00
+256.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+256.00 352.00
+253.00 357.00
+256.00 355.00
+259.00 357.00
+256.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+80.00 352.00
+48.00 352.00
+48.00 400.00
+-1.00 -1.00
+5 0
+0 
+ 3
+80.00 352.00
+75.00 349.00
+77.00 352.00
+75.00 355.00
+80.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 384.00
+416.00 416.00
+-1.00 -1.00
+5 0
+0 
+ 3
+416.00 384.00
+413.00 389.00
+416.00 387.00
+419.00 389.00
+416.00 384.00
+-1.00 -1.00
+5 0
+0 
+ 3
+192.00 352.00
+192.00 336.00
+288.00 336.00
+288.00 352.00
+192.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+80.00 352.00
+80.00 336.00
+192.00 336.00
+192.00 352.00
+80.00 352.00
+-1.00 -1.00
+5 0
+0 
+ 3
+80.00 368.00
+80.00 352.00
+208.00 352.00
+208.00 368.00
+80.00 368.00
+-1.00 -1.00
+5 0
+0 
+ 3
+400.00 384.00
+400.00 368.00
+448.00 368.00
+448.00 384.00
+400.00 384.00
+-1.00 -1.00
+5 0
+0 
+ 0
+96.00 288.00
+96.00 303.00
+96.00 303.00
+96.00 303.00
+-1.00 -1.00
+1 2
+66                  +16: 0x02 0x00 0x07 0xc0  20: 0x01 0x08 0x00 0x00
+ 0
+96.00 304.00
+96.00 319.00
+96.00 319.00
+96.00 319.00
+-1.00 -1.00
+1 2
+66                  + 8: 0x06 0x74 0x70 0x70  12: 0x69 0x6e 0x67 0xc2
+ 0
+96.00 320.00
+96.00 335.00
+96.00 335.00
+96.00 335.00
+-1.00 -1.00
+1 2
+66                  + 0: 0x15 0xe0 0x00 0x00   4: 0x00 0x03 0x00 0xc1
+ 0
+96.00 336.00
+96.00 351.00
+96.00 351.00
+96.00 351.00
+-1.00 -1.00
+1 2
+56 HDRLEN:  21+1   CR_TPDU_type    cdt 0(0x0)      dref 0x0
+ 0
+96.00 352.00
+96.00 367.00
+96.00 367.00
+96.00 367.00
+-1.00 -1.00
+1 2
+18 INPUT total len 22
+ 0
+96.00 368.00
+96.00 383.00
+96.00 383.00
+96.00 383.00
+-1.00 -1.00
+1 2
+60 1a: Ref 22      arg 14(0xe),    @ 91990 : 0000.435125   tpdu
+ -1
diff --git a/share/doc/iso/wisc/figs/tppt.nr b/share/doc/iso/wisc/figs/tppt.nr
new file mode 100644
index 0000000..a6dcd18
--- /dev/null
+++ b/share/doc/iso/wisc/figs/tppt.nr
@@ -0,0 +1,296 @@
+.(z
+.br
+.nr g1 3456u
+.nr g2 2736u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D's 16u'\D't 1u'
+.sp -1
+.sp 1296u
+\h'2592u'\D'l 432u 0u'
+.sp -1
+\D's -1u'\D't 7u'
+.sp -1
+\h'864u'\D'l 1728u 0u'
+.sp -1
+.sp -144u
+\h'2880u'\D'l 144u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "event # : time since 1st event
+.sp -864u
+\h'1728u'\&\*(g9
+.sp |\n(g8u
+\D't 1u'
+.sp -1
+.sp -720u
+\h'2160u'\D'l 0u -144u'
+.sp -1
+\h'2160u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
+.sp -1
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "@ 91990  : 0000.435125
+.sp 144u
+\h'1872u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "1a: Ref 22   arg 14(0xe)
+.sp 2304u
+\h'288u'\&\*(g9
+.sp |\n(g8u
+.sp 432u
+\h'2160u'\D'l 0u -144u'\D'l 576u 0u'
+.sp -1
+\h'2160u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
+.sp -1
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "cdt 0(0x0)     dref 0x0
+.sp 144u
+\h'2592u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "CR_TPDU_type
+.sp 144u
+\h'1728u'\&\*(g9
+.sp |\n(g8u
+\h'1584u'\D'l 0u 144u'\D'l 864u 0u'\D'l 0u -144u'\D'l -864u 0u'
+.sp -1
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "HDRLEN: 21+1 
+.sp 144u
+\h'432u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "INPUT  total len 22
+\h'432u'\&\*(g9
+.sp |\n(g8u
+.sp -144u
+\h'288u'\D'l 0u 288u'\D'l 1296u 0u'\D'l 0u -288u'\D'l -1296u 0u'
+.sp -1
+.sp 288u
+\h'432u'\D'l 0u 576u'\D'l 2880u 0u'\D'l 0u -576u'\D'l -2880u 0u'
+.sp -1
+.sp -144u
+\h'288u'\D'l -288u 0u'\D'l 0u -432u'
+.sp -1
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "tpdu
+.sp -288u
+\h'3024u'\&\*(g9
+.sp |\n(g8u
+.sp -432u
+\h'2880u'\D'l 0u 144u'\D'l 576u 0u'\D'l 0u -144u'\D'l -576u 0u'
+.sp -1
+\h'3168u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
+.sp -1
+.sp -288u
+\h'3168u'\D'l 0u 288u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 ", TPDU type
+.sp 1728u
+\h'1152u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'
+.sp -1
+.sp 1008u
+\h'864u'\D'l 432u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "TPDU size
+.sp 1008u
+\h'2736u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp 1008u
+\h'2304u'\D'l 288u 0u'
+.sp -1
+.sp -720u
+\h'1728u'\D'l 864u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "called transport selector
+.sp 576u
+\h'2736u'\&\*(g9
+.sp |\n(g8u
+\D's 16u'
+.sp -1
+.sp 576u
+\h'2304u'\D'l 288u 0u'
+.sp -1
+.sp -576u
+\h'864u'\D'l 720u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "calling transport selector
+.sp 432u
+\h'2736u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'\D't 7u'
+.sp -1
+.sp 432u
+\h'2304u'\D'l 288u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "dst-ref, src-ref
+.sp 144u
+\h'1008u'\&\*(g9
+.sp |\n(g8u
+\D's 20u'\D't 1u'
+.sp -1
+.sp 144u
+\h'576u'\D'l 288u 0u'
+.sp -1
+.sp -864u
+\h'1440u'\D'l 1152u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "LI
+.sp 720u
+\h'1008u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'
+.sp -1
+.sp 720u
+\h'576u'\D'l 288u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "1 for the LI)
+.sp -1584u
+\h'576u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "(21 in the LI +
+.sp -1584u
+\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "and its header is 22 bytes
+.sp -1728u
+\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "its total length is 22 bytes
+.sp -1872u
+\h'720u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "TPDU was received;
+.sp -1872u
+\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "indicates a TPDU event
+.sp -1728u
+\h'2592u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'
+.sp -1
+.sp -432u
+\h'432u'\D'l -432u 0u'\D'l 0u 432u'\D'l 432u 0u'
+.sp -1
+\h'432u'\D'l -45u 27u'\D'l 18u -27u'\D'l -18u -27u'\D'l 45u 27u'
+.sp -1
+.sp -576u
+\h'288u'\D'l -45u 27u'\D'l 18u -27u'\D'l -18u -27u'\D'l 45u 27u'
+.sp -1
+\D't 3u'
+.sp -1
+.sp 288u
+\h'2592u'\D'l 288u 0u'
+.sp -1
+.sp 1008u
+\h'576u'\D'l 288u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "class and options
+\h'1008u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "+ 0:  0x15  0xe0  0x00  0x00     4:  0x00  0x03  0x00  0xc1
+.sp -1008u
+\h'576u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "+ 8:  0x06  0x74  0x70  0x70    12:  0x69  0x6e  0xc7  0xc2
+.sp -864u
+\h'576u'\&\*(g9
+.sp |\n(g8u
+.ft R
+.ps 12
+.nr g8 \n(.d
+.ds g9 "+12:  0x02  0x00  0x07  0xc0    20:  0x01  0x08  0x00  0x00
+.sp -720u
+\h'576u'\&\*(g9
+.sp |\n(g8u
+\D't 1u'
+.sp -1
+.sp -1584u
+\h'1872u'\D'l 0u -144u'\D'l 1008u 0u'\D'l 0u 144u'\D'l -1008u 0u'
+.sp -1
+.ft I
+.ps 10
+.nr g8 \n(.d
+.ds g9 "this is a CR TPDU
+.sp 144u
+\h'2736u'\&\*(g9
+.sp |\n(g8u
+.sp 2160u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG\fR: Output of tppt(8)
+.)z
diff --git a/share/doc/iso/wisc/figs/trans_flow.grn b/share/doc/iso/wisc/figs/trans_flow.grn
new file mode 100644
index 0000000..4a45d91
--- /dev/null
+++ b/share/doc/iso/wisc/figs/trans_flow.grn
@@ -0,0 +1,20 @@
+.(z
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.4
+narrow 1
+medium 3
+thick 7
+pointscale off
+file trans_flow.gsrc
+.GE
+.ce
+\fB Figure \n+(FG\fR: Control flow (solid) and data flow (broken) 
+.ce
+among the parts of the transport implementation. 
+.)z
diff --git a/share/doc/iso/wisc/figs/trans_flow.gsrc b/share/doc/iso/wisc/figs/trans_flow.gsrc
new file mode 100644
index 0000000..1b96523
--- /dev/null
+++ b/share/doc/iso/wisc/figs/trans_flow.gsrc
@@ -0,0 +1,567 @@
+gremlinfile
+0 448.00 587.00
+3
+448.00 201.00
+450.69 206.18
+450.55 202.57
+453.83 201.07
+448.00 201.00
+-1.00 -1.00
+6 0
+0 
+ 3
+549.00 260.00
+447.00 201.00
+-1.00 -1.00
+6 0
+0 
+ 3
+582.00 238.00
+585.82 233.60
+582.52 235.05
+579.91 232.55
+582.00 238.00
+-1.00 -1.00
+6 0
+0 
+ 3
+585.00 148.00
+583.00 239.00
+-1.00 -1.00
+6 0
+0 
+ 3
+423.00 376.00
+428.82 375.64
+425.47 374.30
+425.42 370.70
+423.00 376.00
+-1.00 -1.00
+6 0
+0 
+ 3
+542.00 322.00
+422.00 375.00
+-1.00 -1.00
+6 0
+0 
+ 3
+393.00 246.00
+389.63 250.76
+392.77 248.99
+395.61 251.22
+393.00 246.00
+-1.00 -1.00
+6 0
+0 
+ 3
+390.00 364.00
+392.00 244.00
+-1.00 -1.00
+6 0
+0 
+ 3
+476.00 655.00
+481.66 653.59
+478.12 652.88
+477.41 649.34
+476.00 655.00
+-1.00 -1.00
+6 0
+0 
+ 3
+540.00 577.00
+476.00 656.00
+-1.00 -1.00
+6 0
+0 
+ 3
+138.00 209.00
+139.96 203.51
+137.41 206.06
+134.08 204.69
+138.00 209.00
+-1.00 -1.00
+6 0
+0 
+ 3
+137.00 209.00
+124.00 149.00
+-1.00 -1.00
+6 0
+0 
+ 3
+378.00 242.00
+375.00 247.00
+378.00 245.00
+381.00 247.00
+378.00 242.00
+-1.00 -1.00
+1 0
+0 
+ 3
+376.00 364.00
+378.00 239.00
+-1.00 -1.00
+1 0
+0 
+ 3
+441.00 215.00
+443.50 220.27
+443.50 216.66
+446.82 215.28
+441.00 215.00
+-1.00 -1.00
+1 0
+0 
+ 3
+541.00 269.00
+438.00 214.00
+-1.00 -1.00
+1 0
+0 
+ 3
+600.00 240.00
+603.25 235.16
+600.15 237.00
+597.25 234.86
+600.00 240.00
+-1.00 -1.00
+1 0
+0 
+ 3
+599.00 242.00
+605.00 148.00
+-1.00 -1.00
+1 0
+0 
+ 3
+497.00 138.00
+491.22 137.21
+494.24 139.18
+493.59 142.73
+497.00 138.00
+-1.00 -1.00
+1 0
+0 
+ 3
+441.00 165.00
+495.00 138.00
+-1.00 -1.00
+1 0
+0 
+ 3
+423.00 231.00
+423.07 236.83
+424.57 233.55
+428.18 233.69
+423.00 231.00
+-1.00 -1.00
+1 0
+0 
+ 3
+563.00 479.00
+421.00 231.00
+-1.00 -1.00
+1 0
+0 
+ 3
+433.00 394.00
+438.82 394.29
+435.65 392.59
+436.00 389.00
+433.00 394.00
+-1.00 -1.00
+1 0
+0 
+ 3
+554.00 335.00
+434.00 391.00
+-1.00 -1.00
+1 0
+0 
+ 3
+176.00 317.00
+178.50 322.27
+178.50 318.66
+181.82 317.28
+176.00 317.00
+-1.00 -1.00
+1 0
+0 
+ 3
+325.00 413.00
+175.00 315.00
+-1.00 -1.00
+1 0
+0 
+ 3
+343.00 378.00
+340.62 372.67
+340.54 376.28
+337.18 377.59
+343.00 378.00
+-1.00 -1.00
+1 0
+0 
+ 3
+199.00 285.00
+342.00 377.00
+-1.00 -1.00
+1 0
+0 
+ 3
+344.00 226.00
+338.60 228.20
+342.20 228.40
+343.40 231.80
+344.00 226.00
+-1.00 -1.00
+1 0
+0 
+ 3
+197.00 458.00
+342.00 226.00
+-1.00 -1.00
+1 0
+0 
+ 3
+523.00 513.00
+520.80 507.60
+520.60 511.20
+517.20 512.40
+523.00 513.00
+-1.00 -1.00
+1 0
+0 
+ 3
+424.00 461.00
+522.00 512.00
+-1.00 -1.00
+1 0
+0 
+ 3
+553.00 583.00
+547.45 584.79
+551.02 585.26
+551.97 588.74
+553.00 583.00
+-1.00 -1.00
+1 0
+0 
+ 3
+491.00 657.00
+553.00 583.00
+-1.00 -1.00
+1 0
+0 
+ 3
+235.00 559.00
+235.65 564.79
+236.82 561.38
+240.42 561.15
+235.00 559.00
+-1.00 -1.00
+1 0
+0 
+ 3
+304.00 656.00
+233.00 556.00
+-1.00 -1.00
+1 0
+0 
+ 4
+383.00 420.00
+354.00 467.00
+383.00 364.77
+383.00 475.23
+438.23 420.00
+327.77 420.00
+-1.00 -1.00
+5 0
+0 
+ 4
+189.00 515.00
+160.00 562.00
+189.00 459.77
+189.00 570.23
+244.23 515.00
+133.77 515.00
+-1.00 -1.00
+5 0
+0 
+ 4
+577.00 532.00
+548.00 579.00
+577.00 476.77
+577.00 587.23
+632.23 532.00
+521.77 532.00
+-1.00 -1.00
+5 0
+0 
+ 4
+592.00 296.00
+563.00 343.00
+592.00 240.77
+592.00 351.23
+647.23 296.00
+536.77 296.00
+-1.00 -1.00
+5 0
+0 
+ 4
+388.00 185.00
+359.00 232.00
+388.00 129.77
+388.00 240.23
+443.23 185.00
+332.77 185.00
+-1.00 -1.00
+5 0
+0 
+ 4
+145.00 265.00
+116.00 312.00
+145.00 209.77
+145.00 320.23
+200.23 265.00
+89.77 265.00
+-1.00 -1.00
+5 0
+0 
+ 3
+282.00 708.00
+282.00 658.00
+500.00 658.00
+500.00 708.00
+282.00 708.00
+-1.00 -1.00
+5 0
+0 
+ 3
+384.00 660.00
+384.00 484.00
+-1.00 -1.00
+6 0
+0 
+ 3
+384.00 484.00
+381.00 489.00
+384.00 487.00
+387.00 489.00
+384.00 484.00
+-1.00 -1.00
+6 0
+0 
+ 3
+552.00 484.00
+408.00 236.00
+-1.00 -1.00
+6 0
+0 
+ 3
+408.00 236.00
+408.28 241.82
+409.66 238.50
+413.27 238.50
+408.00 236.00
+-1.00 -1.00
+6 0
+0 
+ 3
+432.00 452.00
+528.00 500.00
+-1.00 -1.00
+6 0
+0 
+ 3
+528.00 500.00
+525.50 494.73
+525.50 498.34
+522.18 499.72
+528.00 500.00
+-1.00 -1.00
+6 0
+0 
+ 3
+240.00 484.00
+328.00 444.00
+-1.00 -1.00
+6 0
+0 
+ 3
+240.00 484.00
+245.69 485.26
+242.85 483.05
+243.79 479.57
+240.00 484.00
+-1.00 -1.00
+6 0
+0 
+ 0
+320.00 668.00
+320.00 681.00
+320.00 681.00
+320.00 681.00
+-1.00 -1.00
+3 2
+11 SOCKET CODE
+ 0
+512.00 116.00
+512.00 129.00
+512.00 129.00
+512.00 129.00
+-1.00 -1.00
+3 2
+13 NETWORK LEVEL
+ 3
+496.00 148.00
+496.00 100.00
+704.00 100.00
+704.00 148.00
+496.00 148.00
+-1.00 -1.00
+6 0
+0 
+ 0
+64.00 116.00
+64.00 129.00
+64.00 129.00
+64.00 129.00
+-1.00 -1.00
+3 2
+5 CLOCK
+ 3
+48.00 148.00
+48.00 100.00
+160.00 100.00
+160.00 148.00
+48.00 148.00
+-1.00 -1.00
+6 0
+0 
+ 0
+160.00 500.00
+160.00 513.00
+160.00 513.00
+160.00 513.00
+-1.00 -1.00
+3 2
+4 SEND
+ 0
+544.00 524.00
+544.00 537.00
+544.00 537.00
+544.00 537.00
+-1.00 -1.00
+3 2
+4 RECV
+ 0
+352.00 421.00
+352.00 434.00
+352.00 434.00
+352.00 434.00
+-1.00 -1.00
+3 2
+6 DRIVER
+ 0
+105.00 264.00
+105.00 277.00
+105.00 277.00
+105.00 277.00
+-1.00 -1.00
+3 2
+6 TIMERS
+ 0
+560.00 276.00
+560.00 289.00
+560.00 289.00
+560.00 289.00
+-1.00 -1.00
+3 2
+5 INPUT
+ 0
+349.00 181.00
+349.00 194.00
+349.00 194.00
+349.00 194.00
+-1.00 -1.00
+3 2
+6 OUTPUT
+ 3
+192.00 292.00
+336.00 388.00
+-1.00 -1.00
+6 0
+0 
+ 3
+336.00 388.00
+334.59 382.34
+333.88 385.88
+330.34 386.59
+336.00 388.00
+-1.00 -1.00
+6 0
+0 
+ 3
+328.00 404.00
+184.00 308.00
+-1.00 -1.00
+6 0
+0 
+ 3
+184.00 308.00
+187.13 312.92
+186.68 309.34
+189.81 307.55
+184.00 308.00
+-1.00 -1.00
+6 0
+0 
+ 3
+208.00 460.00
+352.00 236.00
+-1.00 -1.00
+6 0
+0 
+ 3
+352.00 236.00
+347.08 239.13
+350.66 238.68
+352.45 241.81
+352.00 236.00
+-1.00 -1.00
+6 0
+0 
+ 3
+432.00 148.00
+496.00 116.00
+-1.00 -1.00
+6 0
+0 
+ 3
+496.00 116.00
+491.00 113.00
+493.00 116.00
+491.00 119.00
+496.00 116.00
+-1.00 -1.00
+6 0
+0 
+ 3
+224.00 564.00
+288.00 660.00
+-1.00 -1.00
+6 0
+0 
+ 3
+288.00 660.00
+288.45 654.19
+286.66 657.32
+283.08 656.87
+288.00 660.00
+-1.00 -1.00
+6 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/trans_flow.nr b/share/doc/iso/wisc/figs/trans_flow.nr
new file mode 100644
index 0000000..2b8061c
--- /dev/null
+++ b/share/doc/iso/wisc/figs/trans_flow.nr
@@ -0,0 +1,274 @@
+.(z
+.br
+.nr g1 3456u
+.nr g2 3202u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+.sp 253u
+\h'1265u'\D'l 2u 30u'\D'l -9u -16u'\D'l -19u 2u'\D'l 26u -16u'
+.sp -1
+.sp 505u
+\h'928u'\D'l 337u -505u'
+.sp -1
+.sp 2359u
+\h'2361u'\D'l -27u 16u'\D'l 11u -16u'\D'l -11u -15u'\D'l 27u 15u'
+.sp -1
+.sp -168u
+\h'2023u'\D'l 338u 168u'
+.sp -1
+.sp -464u
+\h'1602u'\D'l -26u -16u'\D'l 19u 2u'\D'l 9u -16u'\D'l -2u 30u'
+.sp -1
+.sp -1180u
+\h'843u'\D'l 759u 1180u'
+.sp -1
+.sp 801u
+\h'717u'\D'l 16u -26u'\D'l -2u 19u'\D'l 16u 9u'\D'l -30u -2u'
+.sp -1
+.sp -506u
+\h'1475u'\D'l -758u 506u'
+.sp -1
+.sp 84u
+\h'1518u'\D'l -8u 30u'\D'l -4u -18u'\D'l -18u -4u'\D'l 30u -8u'
+.sp -1
+.sp 506u
+\h'759u'\D'l 759u -506u'
+.sp -1
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "OUTPUT
+.sp 585u
+\h'1586u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "INPUT
+.sp 85u
+\h'2698u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "TIMERS
+.sp 148u
+\h'301u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "DRIVER
+.sp -679u
+\h'1602u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "RECV
+.sp -1221u
+\h'2613u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "SEND
+.sp -1096u
+\h'590u'\&\*(g9
+.sp |\n(g8u
+.sp 759u
+\D'l 0u 253u'\D'l 590u 0u'\D'l 0u -253u'\D'l -590u 0u'
+.sp -1
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "CLOCK
+.sp 168u
+\h'85u'\&\*(g9
+.sp |\n(g8u
+\h'2361u'\D'l 0u 253u'\D'l 1095u 0u'\D'l 0u -253u'\D'l -1095u 0u'
+.sp -1
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "NETWORK LEVEL
+.sp 168u
+\h'2445u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 10
+.nr g8 \n(.d
+.ds g9 "SOCKET CODE
+.sp -2739u
+\h'1433u'\&\*(g9
+.sp |\n(g8u
+.sp -1770u
+\h'1012u'\D'l 30u -7u'\D'l -15u 12u'\D'l 5u 18u'\D'l -20u -23u'
+.sp -1
+\h'1012u'\D'l 463u 210u'
+.sp -1
+.sp -85u
+\h'2529u'\D'l -13u 28u'\D'l 0u -19u'\D'l -18u -7u'\D'l 31u -2u'
+.sp -1
+.sp 253u
+\h'2023u'\D'l 506u -253u'
+.sp -1
+.sp 1138u
+\h'1897u'\D'l 1u -30u'\D'l 8u 17u'\D'l 19u 0u'\D'l -28u 13u'
+.sp -1
+.sp -1306u
+\h'2656u'\D'l -759u 1306u'
+.sp -1
+\h'1771u'\D'l -16u -27u'\D'l 16u 11u'\D'l 15u -11u'\D'l -15u 27u'
+.sp -1
+.sp -926u
+\h'1771u'\D'l 0u 926u'
+.sp -1
+\D't 1u'
+.sp -1
+.sp -253u
+\h'1233u'\D'l 0u 263u'\D'l 1149u 0u'\D'l 0u -263u'\D'l -1149u 0u'
+.sp -1
+.sp 2332u
+\h'220u'\D'c 581u'
+.sp -1
+.sp 422u
+\h'1501u'\D'c 581u'
+.sp -1
+.sp -585u
+\h'2575u'\D'c 581u'
+.sp -1
+.sp -1242u
+\h'2496u'\D'c 581u'
+.sp -1
+.sp 89u
+\h'452u'\D'c 581u'
+.sp -1
+.sp 500u
+\h'1474u'\D'c 581u'
+.sp -1
+\D's 4u'
+.sp -1
+.sp -1242u
+\h'1349u'\D'l -374u 526u'
+.sp -1
+.sp 511u
+\h'986u'\D'l 3u -31u'\D'l 6u 18u'\D'l 19u 1u'\D'l -28u 12u'
+.sp -1
+.sp -517u
+\h'2334u'\D'l 327u 390u'
+.sp -1
+.sp 390u
+\h'2661u'\D'l -29u -9u'\D'l 18u -3u'\D'l 5u -18u'\D'l 6u 30u'
+.sp -1
+.sp 642u
+\h'1981u'\D'l 517u -268u'
+.sp -1
+.sp -273u
+\h'2503u'\D'l -12u 27u'\D'l -1u -18u'\D'l -18u -6u'\D'l 31u -3u'
+.sp -1
+.sp 289u
+\h'785u'\D'l 764u 1222u'
+.sp -1
+.sp 1222u
+\h'1560u'\D'l -29u -12u'\D'l 19u -1u'\D'l 7u -18u'\D'l 3u 31u'
+.sp -1
+.sp -311u
+\h'796u'\D'l 753u -485u'
+.sp -1
+.sp -490u
+\h'1555u'\D'l -13u 28u'\D'l 0u -19u'\D'l -18u -7u'\D'l 31u -2u'
+.sp -1
+.sp -184u
+\h'1460u'\D'l -791u 516u'
+.sp -1
+.sp 506u
+\h'675u'\D'l 13u -28u'\D'l 0u 19u'\D'l 17u 7u'\D'l -30u 2u'
+.sp -1
+.sp -95u
+\h'2666u'\D'l -632u -295u'
+.sp -1
+.sp -311u
+\h'2029u'\D'l 30u -2u'\D'l -16u 9u'\D'l 1u 19u'\D'l -15u -26u'
+.sp -1
+.sp -448u
+\h'2714u'\D'l -749u 1307u'
+.sp -1
+.sp 1307u
+\h'1976u'\D'l 0u -31u'\D'l 8u 17u'\D'l 19u -1u'\D'l -27u 15u'
+.sp -1
+.sp 347u
+\h'2071u'\D'l 284u 143u'
+.sp -1
+.sp 143u
+\h'2366u'\D'l -31u 4u'\D'l 16u -11u'\D'l -3u -18u'\D'l 18u 25u'
+.sp -1
+.sp -548u
+\h'2903u'\D'l 32u 495u'
+.sp -1
+.sp 10u
+\h'2908u'\D'l 18u 26u'\D'l -17u -10u'\D'l -15u 11u'\D'l 14u -27u'
+.sp -1
+.sp -153u
+\h'2598u'\D'l -543u 290u'
+.sp -1
+.sp 285u
+\h'2071u'\D'l 13u -28u'\D'l 0u 19u'\D'l 17u 7u'\D'l -30u 2u'
+.sp -1
+.sp -785u
+\h'1728u'\D'l 11u 658u'
+.sp -1
+.sp 643u
+\h'1739u'\D'l -16u -27u'\D'l 16u 11u'\D'l 16u -11u'\D'l -16u 27u'
+.sp -1
+\D's -1u'\D't 3u'
+.sp -1
+.sp 174u
+\h'469u'\D'l -68u 316u'
+.sp -1
+\h'475u'\D'l 10u 28u'\D'l -14u -13u'\D'l -17u 7u'\D'l 21u -22u'
+.sp -1
+.sp -1938u
+\h'2592u'\D'l -337u -416u'
+.sp -1
+.sp -411u
+\h'2255u'\D'l 30u 7u'\D'l -19u 4u'\D'l -3u 19u'\D'l -8u -30u'
+.sp -1
+.sp 1532u
+\h'1802u'\D'l 11u 632u'
+.sp -1
+.sp 622u
+\h'1818u'\D'l -18u -25u'\D'l 17u 9u'\D'l 15u -12u'\D'l -14u 28u'
+.sp -1
+.sp -401u
+\h'2603u'\D'l -632u -279u'
+.sp -1
+.sp -284u
+\h'1976u'\D'l 31u 2u'\D'l -18u 7u'\D'l 0u 19u'\D'l -13u -28u'
+.sp -1
+.sp 1201u
+\h'2829u'\D'l -10u -480u'
+.sp -1
+.sp -474u
+\h'2814u'\D'l 20u 23u'\D'l -18u -8u'\D'l -13u 13u'\D'l 11u -28u'
+.sp -1
+.sp -116u
+\h'2640u'\D'l -538u 311u'
+.sp -1
+.sp 311u
+\h'2108u'\D'l 14u -28u'\D'l -1u 19u'\D'l 17u 8u'\D'l -30u 1u'
+.sp -1
+.sp 532u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fB Figure \n+(FG\fR: Control flow (solid) and data flow (broken) 
+.ce
+among the parts of the transport implementation. 
+.)z
diff --git a/share/doc/iso/wisc/figs/unix_ipc.grn b/share/doc/iso/wisc/figs/unix_ipc.grn
new file mode 100644
index 0000000..7c06d27
--- /dev/null
+++ b/share/doc/iso/wisc/figs/unix_ipc.grn
@@ -0,0 +1,18 @@
+.(z L
+.GS C
+width 6.0
+high 7.0
+1 8
+2 10
+3 12
+4 14
+sc 0.3
+narrow 1
+medium 3
+thick 7
+pointscale off
+file unix_ipc.gsrc
+.GE
+.ce
+\fBFigure \n+(FG\fR:  IPC in 4.2 Unix
+.)z
diff --git a/share/doc/iso/wisc/figs/unix_ipc.gsrc b/share/doc/iso/wisc/figs/unix_ipc.gsrc
new file mode 100644
index 0000000..cafe972
--- /dev/null
+++ b/share/doc/iso/wisc/figs/unix_ipc.gsrc
@@ -0,0 +1,1041 @@
+gremlinfile
+0 384.00 408.00
+3
+384.00 380.00
+387.00 375.00
+384.00 377.00
+381.00 375.00
+384.00 380.00
+-1.00 -1.00
+6 0
+0 
+ 3
+392.00 612.00
+608.00 612.00
+-1.00 -1.00
+6 0
+0 
+ 3
+248.00 612.00
+32.00 612.00
+-1.00 -1.00
+6 0
+0 
+ 4
+176.00 692.00
+176.00 740.00
+176.00 644.00
+176.00 740.00
+224.00 692.00
+128.00 692.00
+-1.00 -1.00
+6 0
+0 
+ 4
+160.00 532.00
+160.00 580.00
+160.00 484.00
+160.00 580.00
+208.00 532.00
+112.00 532.00
+-1.00 -1.00
+6 0
+0 
+ 4
+528.00 340.00
+528.00 388.00
+528.00 292.00
+528.00 388.00
+576.00 340.00
+480.00 340.00
+-1.00 -1.00
+6 0
+0 
+ 4
+544.00 124.00
+544.00 188.00
+544.00 60.00
+544.00 188.00
+608.00 124.00
+480.00 124.00
+-1.00 -1.00
+6 0
+0 
+ 4
+320.00 604.00
+320.00 676.00
+320.00 532.00
+320.00 676.00
+392.00 604.00
+248.00 604.00
+-1.00 -1.00
+6 0
+0 
+ 0
+144.00 676.00
+144.00 692.00
+144.00 692.00
+144.00 692.00
+-1.00 -1.00
+3 3
+7 program
+ 0
+152.00 700.00
+152.00 716.00
+152.00 716.00
+152.00 716.00
+-1.00 -1.00
+3 3
+4 user
+ 0
+288.00 628.00
+288.00 644.00
+288.00 644.00
+288.00 644.00
+-1.00 -1.00
+3 3
+9 C library
+ 0
+280.00 572.00
+280.00 588.00
+280.00 588.00
+280.00 588.00
+-1.00 -1.00
+3 3
+12 system calls
+ 0
+144.00 532.00
+144.00 548.00
+144.00 548.00
+144.00 548.00
+-1.00 -1.00
+3 3
+5 clock
+ 0
+512.00 132.00
+512.00 148.00
+512.00 148.00
+512.00 148.00
+-1.00 -1.00
+3 3
+8 network 
+ 0
+512.00 108.00
+512.00 124.00
+512.00 124.00
+512.00 124.00
+-1.00 -1.00
+3 3
+9 interface
+ 0
+512.00 84.00
+512.00 100.00
+512.00 100.00
+512.00 100.00
+-1.00 -1.00
+3 3
+7 drivers
+ 0
+32.00 628.00
+32.00 644.00
+32.00 644.00
+32.00 644.00
+-1.00 -1.00
+2 3
+4 user
+ 0
+32.00 580.00
+32.00 596.00
+32.00 596.00
+32.00 596.00
+-1.00 -1.00
+2 3
+6 kernel
+ 3
+248.00 612.00
+392.00 612.00
+-1.00 -1.00
+1 0
+0 
+ 0
+488.00 692.00
+488.00 708.00
+488.00 708.00
+488.00 708.00
+-1.00 -1.00
+3 3
+7 network
+ 0
+480.00 668.00
+480.00 684.00
+480.00 684.00
+480.00 684.00
+-1.00 -1.00
+3 3
+10 management
+ 4
+528.00 692.00
+528.00 756.00
+528.00 628.00
+528.00 756.00
+592.00 692.00
+464.00 692.00
+-1.00 -1.00
+6 0
+0 
+ 4
+528.00 500.00
+528.00 548.00
+528.00 452.00
+528.00 548.00
+576.00 500.00
+480.00 500.00
+-1.00 -1.00
+6 0
+0 
+ 0
+504.00 508.00
+504.00 524.00
+504.00 524.00
+504.00 524.00
+-1.00 -1.00
+3 3
+7 routing
+ 0
+504.00 484.00
+504.00 500.00
+504.00 500.00
+504.00 500.00
+-1.00 -1.00
+3 3
+6 tables
+ 4
+320.00 436.00
+320.00 516.00
+320.00 356.00
+320.00 516.00
+400.00 436.00
+240.00 436.00
+-1.00 -1.00
+6 0
+0 
+ 0
+288.00 420.00
+288.00 436.00
+288.00 436.00
+288.00 436.00
+-1.00 -1.00
+3 3
+7 sockets
+ 3
+80.00 356.00
+80.00 100.00
+208.00 100.00
+208.00 356.00
+80.00 356.00
+-1.00 -1.00
+6 0
+0 
+ 0
+112.00 292.00
+112.00 308.00
+112.00 308.00
+112.00 308.00
+-1.00 -1.00
+3 3
+9 transport
+ 0
+112.00 244.00
+112.00 260.00
+112.00 260.00
+112.00 260.00
+-1.00 -1.00
+3 3
+8 protocol
+ 0
+112.00 188.00
+112.00 204.00
+112.00 204.00
+112.00 204.00
+-1.00 -1.00
+3 3
+6 switch
+ 4
+448.00 228.00
+448.00 276.00
+448.00 180.00
+448.00 276.00
+496.00 228.00
+400.00 228.00
+-1.00 -1.00
+6 0
+0 
+ 4
+288.00 292.00
+288.00 340.00
+288.00 244.00
+288.00 340.00
+336.00 292.00
+240.00 292.00
+-1.00 -1.00
+6 0
+0 
+ 4
+288.00 132.00
+288.00 180.00
+288.00 84.00
+288.00 180.00
+336.00 132.00
+240.00 132.00
+-1.00 -1.00
+6 0
+0 
+ 0
+504.00 340.00
+504.00 356.00
+504.00 356.00
+504.00 356.00
+-1.00 -1.00
+3 3
+5 mbufs
+ 0
+264.00 292.00
+264.00 308.00
+264.00 308.00
+264.00 308.00
+-1.00 -1.00
+3 3
+7 proto 1
+ 0
+264.00 124.00
+264.00 140.00
+264.00 140.00
+264.00 140.00
+-1.00 -1.00
+3 3
+7 proto n
+ 3
+208.00 660.00
+256.00 636.00
+-1.00 -1.00
+6 0
+0 
+ 3
+480.00 652.00
+384.00 628.00
+-1.00 -1.00
+6 0
+0 
+ 3
+384.00 564.00
+480.00 516.00
+-1.00 -1.00
+6 0
+0 
+ 3
+304.00 532.00
+304.00 516.00
+-1.00 -1.00
+6 0
+0 
+ 5
+240.00 420.00
+176.00 420.00
+144.00 404.00
+128.00 372.00
+128.00 356.00
+-1.00 -1.00
+6 0
+0 
+ 3
+216.00 292.00
+240.00 292.00
+-1.00 -1.00
+6 0
+0 
+ 3
+216.00 132.00
+240.00 132.00
+-1.00 -1.00
+6 0
+0 
+ 3
+336.00 292.00
+368.00 292.00
+-1.00 -1.00
+6 0
+0 
+ 3
+336.00 132.00
+368.00 132.00
+-1.00 -1.00
+6 0
+0 
+ 3
+368.00 132.00
+368.00 324.00
+-1.00 -1.00
+6 0
+0 
+ 3
+512.00 180.00
+488.00 196.00
+-1.00 -1.00
+6 0
+0 
+ 5
+368.00 324.00
+368.00 356.00
+368.00 364.00
+-1.00 -1.00
+6 0
+0 
+ 3
+328.00 268.00
+400.00 244.00
+-1.00 -1.00
+6 0
+0 
+ 3
+328.00 164.00
+400.00 204.00
+-1.00 -1.00
+6 0
+0 
+ 3
+208.00 660.00
+213.81 660.45
+210.68 658.66
+211.13 655.08
+208.00 660.00
+-1.00 -1.00
+6 0
+0 
+ 3
+256.00 636.00
+250.34 637.41
+253.88 638.12
+254.59 641.66
+256.00 636.00
+-1.00 -1.00
+6 0
+0 
+ 3
+384.00 628.00
+389.00 631.00
+387.00 628.00
+389.00 625.00
+384.00 628.00
+-1.00 -1.00
+6 0
+0 
+ 3
+480.00 652.00
+475.00 649.00
+477.00 652.00
+475.00 655.00
+480.00 652.00
+-1.00 -1.00
+6 0
+0 
+ 3
+384.00 564.00
+389.81 564.45
+386.68 562.66
+387.13 559.08
+384.00 564.00
+-1.00 -1.00
+6 0
+0 
+ 3
+480.00 516.00
+475.00 513.00
+477.00 516.00
+475.00 519.00
+480.00 516.00
+-1.00 -1.00
+6 0
+0 
+ 3
+304.00 532.00
+307.00 527.00
+304.00 529.00
+301.00 527.00
+304.00 532.00
+-1.00 -1.00
+6 0
+0 
+ 3
+304.00 516.00
+301.00 521.00
+304.00 519.00
+307.00 521.00
+304.00 516.00
+-1.00 -1.00
+6 0
+0 
+ 3
+128.00 356.00
+125.00 361.00
+128.00 359.00
+131.00 361.00
+128.00 356.00
+-1.00 -1.00
+6 0
+0 
+ 3
+240.00 292.00
+235.00 289.00
+237.00 292.00
+235.00 295.00
+240.00 292.00
+-1.00 -1.00
+6 0
+0 
+ 3
+240.00 132.00
+235.00 129.00
+237.00 132.00
+235.00 135.00
+240.00 132.00
+-1.00 -1.00
+6 0
+0 
+ 3
+368.00 364.00
+371.00 359.00
+368.00 361.00
+365.00 359.00
+368.00 364.00
+-1.00 -1.00
+6 0
+0 
+ 3
+328.00 268.00
+333.81 268.45
+330.68 266.66
+331.13 263.08
+328.00 268.00
+-1.00 -1.00
+6 0
+0 
+ 3
+400.00 244.00
+395.00 241.00
+397.00 244.00
+395.00 247.00
+400.00 244.00
+-1.00 -1.00
+6 0
+0 
+ 3
+400.00 204.00
+398.59 198.34
+397.88 201.88
+394.34 202.59
+400.00 204.00
+-1.00 -1.00
+6 0
+0 
+ 3
+328.00 164.00
+331.13 168.92
+330.68 165.34
+333.81 163.55
+328.00 164.00
+-1.00 -1.00
+6 0
+0 
+ 3
+488.00 196.00
+493.66 194.59
+490.12 193.88
+489.41 190.34
+488.00 196.00
+-1.00 -1.00
+6 0
+0 
+ 3
+512.00 180.00
+506.34 181.41
+509.88 182.12
+510.59 185.66
+512.00 180.00
+-1.00 -1.00
+6 0
+0 
+ 0
+416.00 228.00
+416.00 244.00
+416.00 244.00
+416.00 244.00
+-1.00 -1.00
+3 3
+6 DoD IP
+ 0
+368.00 20.00
+368.00 36.00
+368.00 36.00
+368.00 36.00
+-1.00 -1.00
+2 3
+12 control flow
+ 0
+144.00 20.00
+144.00 36.00
+144.00 36.00
+144.00 36.00
+-1.00 -1.00
+2 3
+9 data flow
+ 3
+304.00 36.00
+352.00 36.00
+-1.00 -1.00
+6 0
+0 
+ 3
+80.00 36.00
+128.00 36.00
+-1.00 -1.00
+1 0
+0 
+ 3
+224.00 676.00
+264.00 652.00
+-1.00 -1.00
+1 0
+0 
+ 3
+464.00 676.00
+384.00 644.00
+-1.00 -1.00
+1 0
+0 
+ 3
+392.00 580.00
+488.00 532.00
+-1.00 -1.00
+1 0
+0 
+ 3
+200.00 500.00
+248.00 468.00
+-1.00 -1.00
+1 0
+0 
+ 5
+120.00 500.00
+48.00 372.00
+48.00 276.00
+48.00 196.00
+48.00 84.00
+64.00 68.00
+144.00 68.00
+480.00 68.00
+496.00 76.00
+-1.00 -1.00
+1 0
+0 
+ 3
+152.00 68.00
+152.00 100.00
+-1.00 -1.00
+1 0
+0 
+ 3
+432.00 52.00
+432.00 180.00
+-1.00 -1.00
+1 0
+0 
+ 3
+216.00 116.00
+240.00 116.00
+-1.00 -1.00
+1 0
+0 
+ 3
+216.00 276.00
+240.00 276.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 276.00
+384.00 276.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 116.00
+384.00 116.00
+-1.00 -1.00
+1 0
+0 
+ 3
+384.00 116.00
+384.00 388.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 148.00
+408.00 188.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 252.00
+400.00 228.00
+-1.00 -1.00
+1 0
+0 
+ 3
+472.00 180.00
+488.00 164.00
+-1.00 -1.00
+1 0
+0 
+ 3
+504.00 300.00
+480.00 268.00
+-1.00 -1.00
+1 0
+0 
+ 3
+480.00 340.00
+328.00 324.00
+-1.00 -1.00
+1 0
+0 
+ 3
+400.00 420.00
+488.00 372.00
+-1.00 -1.00
+1 0
+0 
+ 3
+544.00 292.00
+544.00 188.00
+-1.00 -1.00
+1 0
+0 
+ 3
+528.00 452.00
+528.00 388.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 532.00
+336.00 516.00
+-1.00 -1.00
+1 0
+0 
+ 3
+224.00 676.00
+229.66 674.59
+226.12 673.88
+225.41 670.34
+224.00 676.00
+-1.00 -1.00
+1 0
+0 
+ 3
+264.00 652.00
+258.34 653.41
+261.88 654.12
+262.59 657.66
+264.00 652.00
+-1.00 -1.00
+1 0
+0 
+ 3
+384.00 644.00
+387.13 648.92
+386.68 645.34
+389.81 643.55
+384.00 644.00
+-1.00 -1.00
+1 0
+0 
+ 3
+464.00 676.00
+462.59 670.34
+461.88 673.88
+458.34 674.59
+464.00 676.00
+-1.00 -1.00
+1 0
+0 
+ 3
+392.00 580.00
+397.81 580.45
+394.68 578.66
+395.13 575.08
+392.00 580.00
+-1.00 -1.00
+1 0
+0 
+ 3
+488.00 532.00
+482.19 531.55
+485.32 533.34
+484.87 536.92
+488.00 532.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 532.00
+339.00 527.00
+336.00 529.00
+333.00 527.00
+336.00 532.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 516.00
+333.00 521.00
+336.00 519.00
+339.00 521.00
+336.00 516.00
+-1.00 -1.00
+1 0
+0 
+ 3
+248.00 468.00
+242.19 467.55
+245.32 469.34
+244.87 472.92
+248.00 468.00
+-1.00 -1.00
+1 0
+0 
+ 3
+152.00 100.00
+152.00 84.00
+-1.00 -1.00
+1 0
+0 
+ 3
+240.00 116.00
+235.00 113.00
+237.00 116.00
+235.00 119.00
+240.00 116.00
+-1.00 -1.00
+1 0
+0 
+ 3
+152.00 100.00
+155.00 95.00
+152.00 97.00
+149.00 95.00
+152.00 100.00
+-1.00 -1.00
+1 0
+0 
+ 3
+432.00 180.00
+435.00 175.00
+432.00 177.00
+429.00 175.00
+432.00 180.00
+-1.00 -1.00
+1 0
+0 
+ 3
+472.00 180.00
+477.66 178.59
+474.12 177.88
+473.41 174.34
+472.00 180.00
+-1.00 -1.00
+1 0
+0 
+ 3
+496.00 156.00
+490.34 157.41
+493.88 158.12
+494.59 161.66
+496.00 156.00
+-1.00 -1.00
+1 0
+0 
+ 3
+496.00 76.00
+494.59 70.34
+493.88 73.88
+490.34 74.59
+496.00 76.00
+-1.00 -1.00
+1 0
+0 
+ 3
+408.00 188.00
+406.59 182.34
+405.88 185.88
+402.34 186.59
+408.00 188.00
+-1.00 -1.00
+1 0
+0 
+ 3
+336.00 148.00
+339.13 152.92
+338.68 149.34
+341.81 147.55
+336.00 148.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 252.00
+333.81 252.45
+330.68 250.66
+331.13 247.08
+328.00 252.00
+-1.00 -1.00
+1 0
+0 
+ 3
+400.00 228.00
+395.00 225.00
+397.00 228.00
+395.00 231.00
+400.00 228.00
+-1.00 -1.00
+1 0
+0 
+ 3
+544.00 292.00
+547.00 287.00
+544.00 289.00
+541.00 287.00
+544.00 292.00
+-1.00 -1.00
+1 0
+0 
+ 3
+504.00 300.00
+502.59 294.34
+501.88 297.88
+498.34 298.59
+504.00 300.00
+-1.00 -1.00
+1 0
+0 
+ 3
+480.00 268.00
+481.41 273.66
+482.12 270.12
+485.66 269.41
+480.00 268.00
+-1.00 -1.00
+1 0
+0 
+ 3
+400.00 420.00
+405.81 420.45
+402.68 418.66
+403.13 415.08
+400.00 420.00
+-1.00 -1.00
+1 0
+0 
+ 3
+488.00 372.00
+482.19 371.55
+485.32 373.34
+484.87 376.92
+488.00 372.00
+-1.00 -1.00
+1 0
+0 
+ 3
+528.00 452.00
+531.00 447.00
+528.00 449.00
+525.00 447.00
+528.00 452.00
+-1.00 -1.00
+1 0
+0 
+ 3
+528.00 388.00
+525.00 393.00
+528.00 391.00
+531.00 393.00
+528.00 388.00
+-1.00 -1.00
+1 0
+0 
+ 3
+480.00 340.00
+475.00 337.00
+477.00 340.00
+475.00 343.00
+480.00 340.00
+-1.00 -1.00
+1 0
+0 
+ 3
+328.00 324.00
+333.00 327.00
+331.00 324.00
+333.00 321.00
+328.00 324.00
+-1.00 -1.00
+1 0
+0 
+ 5
+240.00 404.00
+176.00 404.00
+160.00 388.00
+152.00 372.00
+152.00 356.00
+-1.00 -1.00
+1 0
+0 
+ 3
+152.00 356.00
+149.00 361.00
+152.00 359.00
+155.00 361.00
+152.00 356.00
+-1.00 -1.00
+1 0
+0 
+ 5
+480.00 324.00
+448.00 308.00
+416.00 292.00
+400.00 276.00
+336.00 212.00
+320.00 196.00
+312.00 180.00
+-1.00 -1.00
+1 0
+0 
+ 3
+312.00 180.00
+311.55 185.81
+313.34 182.68
+316.92 183.13
+312.00 180.00
+-1.00 -1.00
+1 0
+0 
+ 3
+480.00 324.00
+476.87 319.08
+477.32 322.66
+474.19 324.45
+480.00 324.00
+-1.00 -1.00
+1 0
+0 
+ -1
diff --git a/share/doc/iso/wisc/figs/unix_ipc.nr b/share/doc/iso/wisc/figs/unix_ipc.nr
new file mode 100644
index 0000000..de24796
--- /dev/null
+++ b/share/doc/iso/wisc/figs/unix_ipc.nr
@@ -0,0 +1,499 @@
+.(z L
+.br
+.nr g1 3155u
+.nr g2 4031u
+.GS C
+.nr g3 \n(.f
+.nr g4 \n(.s
+\0
+.sp -1
+\D's 4u'\D't 1u'
+.sp -1
+.sp 2366u
+\h'2454u'\D'l -17u 27u'\D'l 2u -20u'\D'l -17u -10u'\D'l 32u 3u'
+.sp -1
+.sp 789u
+\h'1534u'\D'l -3u -32u'\D'l 10u 17u'\D'l 20u -2u'\D'l -27u 17u'
+.sp -1
+.sp -789u
+\h'2454u'\D'g -175u 88u -176u 87u -87u 88u -351u 350u -87u 88u -44u 88u'
+.sp -1
+.sp -175u
+\h'657u'\D'l -16u -28u'\D'l 16u 11u'\D'l 17u -11u'\D'l -17u 28u'
+.sp -1
+.sp -263u
+\h'1139u'\D'g -350u 0u -88u 87u -44u 88u 0u 88u'
+.sp -1
+.sp 438u
+\h'1621u'\D'l 28u -17u'\D'l -11u 17u'\D'l 11u 16u'\D'l -28u -16u'
+.sp -1
+.sp -88u
+\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
+.sp -1
+.sp -263u
+\h'2717u'\D'l -16u -27u'\D'l 16u 11u'\D'l 16u -11u'\D'l -16u 27u'
+.sp -1
+.sp -350u
+\h'2717u'\D'l 16u 27u'\D'l -16u -11u'\D'l -16u 11u'\D'l 16u -27u'
+.sp -1
+.sp 438u
+\h'2498u'\D'l -32u 2u'\D'l 17u -9u'\D'l -2u -20u'\D'l 17u 27u'
+.sp -1
+.sp -263u
+\h'2016u'\D'l 32u -2u'\D'l -18u 9u'\D'l 3u 20u'\D'l -17u -27u'
+.sp -1
+.sp 833u
+\h'2454u'\D'l 8u -31u'\D'l 4u 19u'\D'l 19u 4u'\D'l -31u 8u'
+.sp -1
+.sp -176u
+\h'2586u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
+.sp -1
+.sp 44u
+\h'2805u'\D'l 16u 28u'\D'l -16u -11u'\D'l -17u 11u'\D'l 17u -28u'
+.sp -1
+.sp 351u
+\h'2016u'\D'l -28u 16u'\D'l 11u -16u'\D'l -11u -17u'\D'l 28u 17u'
+.sp -1
+.sp -132u
+\h'1621u'\D'l 32u -2u'\D'l -17u 10u'\D'l 3u 19u'\D'l -18u -27u'
+.sp -1
+.sp 570u
+\h'1665u'\D'l 17u -27u'\D'l -2u 20u'\D'l 17u 10u'\D'l -32u -3u'
+.sp -1
+.sp -219u
+\h'2060u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
+.sp -1
+.sp 614u
+\h'2542u'\D'l -8u 31u'\D'l -4u -20u'\D'l -19u -4u'\D'l 31u -7u'
+.sp -1
+.sp -439u
+\h'2542u'\D'l -31u -7u'\D'l 19u -4u'\D'l 4u -20u'\D'l 8u 31u'
+.sp -1
+.sp -131u
+\h'2410u'\D'l 31u 8u'\D'l -19u 3u'\D'l -4u 20u'\D'l -8u -31u'
+.sp -1
+\h'2191u'\D'l 17u 27u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -27u'
+.sp -1
+.sp 438u
+\h'657u'\D'l 17u 27u'\D'l -17u -10u'\D'l -16u 10u'\D'l 16u -27u'
+.sp -1
+.sp -88u
+\h'1139u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
+.sp -1
+.sp 88u
+\h'657u'\D'l 0u 88u'
+.sp -1
+.sp -2016u
+\h'1183u'\D'l -32u 3u'\D'l 17u -10u'\D'l -2u -20u'\D'l 17u 27u'
+.sp -1
+.sp -262u
+\h'1665u'\D'l -16u -27u'\D'l 16u 11u'\D'l 17u -11u'\D'l -17u 27u'
+.sp -1
+.sp -88u
+\h'1665u'\D'l 17u 28u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -28u'
+.sp -1
+\h'2498u'\D'l -32u 3u'\D'l 17u -10u'\D'l -2u -19u'\D'l 17u 26u'
+.sp -1
+.sp -262u
+\h'1972u'\D'l 32u -3u'\D'l -17u 10u'\D'l 2u 19u'\D'l -17u -26u'
+.sp -1
+.sp -526u
+\h'2366u'\D'l -7u 31u'\D'l -4u -20u'\D'l -20u -4u'\D'l 31u -7u'
+.sp -1
+.sp 175u
+\h'1928u'\D'l 17u -27u'\D'l -2u 20u'\D'l 17u 9u'\D'l -32u -2u'
+.sp -1
+.sp -44u
+\h'1271u'\D'l -31u -8u'\D'l 19u -4u'\D'l 4u -19u'\D'l 8u 31u'
+.sp -1
+.sp -131u
+\h'1052u'\D'l 31u 7u'\D'l -20u 4u'\D'l -4u 20u'\D'l -7u -31u'
+.sp -1
+.sp 788u
+\h'1665u'\D'l 0u 88u'
+.sp -1
+.sp 438u
+\h'2717u'\D'l 0u 350u'
+.sp -1
+.sp 876u
+\h'2805u'\D'l 0u 570u'
+.sp -1
+.sp -701u
+\h'2016u'\D'l 482u 263u'
+.sp -1
+.sp 438u
+\h'2454u'\D'l -833u 88u'
+.sp -1
+.sp 219u
+\h'2586u'\D'l -132u 176u'
+.sp -1
+.sp 658u
+\h'2410u'\D'l 88u 87u'
+.sp -1
+.sp -395u
+\h'1621u'\D'l 395u 132u'
+.sp -1
+.sp 570u
+\h'1665u'\D'l 395u -219u'
+.sp -1
+.sp 175u
+\h'1928u'\D'l 0u -1490u'
+.sp -1
+\h'1665u'\D'l 263u 0u'
+.sp -1
+.sp -876u
+\h'1665u'\D'l 263u 0u'
+.sp -1
+\h'1008u'\D'l 131u 0u'
+.sp -1
+.sp 876u
+\h'1008u'\D'l 131u 0u'
+.sp -1
+.sp 351u
+\h'2191u'\D'l 0u -701u'
+.sp -1
+.sp -88u
+\h'657u'\D'l 0u -175u'
+.sp -1
+.sp -2366u
+\h'482u'\D'g -395u 701u 0u 526u 0u 438u 0u 614u 88u 87u 438u 0u 1841u 0u 88u -43u'
+.sp -1
+\h'920u'\D'l 263u 175u'
+.sp -1
+.sp -437u
+\h'1972u'\D'l 526u 262u'
+.sp -1
+.sp -526u
+\h'2366u'\D'l -438u 175u'
+.sp -1
+\h'1052u'\D'l 219u 131u'
+.sp -1
+.sp 3505u
+\h'263u'\D'l 263u 0u'
+.sp -1
+\D's -1u'\D't 3u'
+.sp -1
+\h'1490u'\D'l 263u 0u'
+.sp -1
+.ft I
+.ps 12
+.nr g8 \n(.d
+.ds g9 "data flow
+.sp 87u
+\h'613u'\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 12
+.nr g8 \n(.d
+.ds g9 "control flow
+.sp 87u
+\h'1840u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "DoD IP
+.sp -1052u
+\h'2103u'\&\*(g9
+.sp |\n(g8u
+.sp -789u
+\h'2629u'\D'l -31u -8u'\D'l 20u -4u'\D'l 4u -19u'\D'l 7u 31u'
+.sp -1
+.sp -88u
+\h'2498u'\D'l 31u 8u'\D'l -19u 4u'\D'l -4u 19u'\D'l -8u -31u'
+.sp -1
+.sp 175u
+\h'1621u'\D'l 18u -26u'\D'l -3u 19u'\D'l 17u 10u'\D'l -32u -3u'
+.sp -1
+.sp -219u
+\h'2016u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
+.sp -1
+.sp -219u
+\h'2016u'\D'l -28u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 28u 16u'
+.sp -1
+.sp -131u
+\h'1621u'\D'l 32u -3u'\D'l -17u 10u'\D'l 3u 20u'\D'l -18u -27u'
+.sp -1
+.sp -526u
+\h'1840u'\D'l 17u 27u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -27u'
+.sp -1
+.sp 1271u
+\h'1139u'\D'l -27u 16u'\D'l 11u -16u'\D'l -11u -17u'\D'l 27u 17u'
+.sp -1
+.sp -877u
+\h'1139u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
+.sp -1
+.sp -350u
+\h'526u'\D'l -17u -28u'\D'l 17u 11u'\D'l 16u -11u'\D'l -16u 28u'
+.sp -1
+.sp -876u
+\h'1490u'\D'l -17u -27u'\D'l 17u 11u'\D'l 16u -11u'\D'l -16u 27u'
+.sp -1
+.sp -88u
+\h'1490u'\D'l 16u 28u'\D'l -16u -11u'\D'l -17u 11u'\D'l 17u -28u'
+.sp -1
+.sp 88u
+\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
+.sp -1
+.sp -263u
+\h'1928u'\D'l 32u -2u'\D'l -17u 9u'\D'l 2u 20u'\D'l -17u -27u'
+.sp -1
+.sp -482u
+\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
+.sp -1
+.sp 132u
+\h'1928u'\D'l 28u -17u'\D'l -11u 17u'\D'l 11u 16u'\D'l -28u -16u'
+.sp -1
+.sp -44u
+\h'1227u'\D'l -31u -8u'\D'l 19u -4u'\D'l 4u -19u'\D'l 8u 31u'
+.sp -1
+.sp -132u
+\h'964u'\D'l 32u -2u'\D'l -17u 10u'\D'l 2u 19u'\D'l -17u -27u'
+.sp -1
+.sp 2716u
+\h'1621u'\D'l 395u -219u'
+.sp -1
+.sp -569u
+\h'1621u'\D'l 395u 131u'
+.sp -1
+.sp -307u
+\h'1840u'\D'g 0u -175u 0u -44u'
+.sp -1
+.sp 789u
+\h'2629u'\D'l -131u -88u'
+.sp -1
+.sp 263u
+\h'1840u'\D'l 0u -1052u'
+.sp -1
+\h'1665u'\D'l 175u 0u'
+.sp -1
+.sp -877u
+\h'1665u'\D'l 175u 0u'
+.sp -1
+.sp 877u
+\h'1008u'\D'l 131u 0u'
+.sp -1
+.sp -877u
+\h'1008u'\D'l 131u 0u'
+.sp -1
+.sp -701u
+\h'1139u'\D'g -350u 0u -176u 88u -87u 175u 0u 88u'
+.sp -1
+.sp -613u
+\h'1490u'\D'l 0u 88u'
+.sp -1
+.sp -175u
+\h'1928u'\D'l 526u 263u'
+.sp -1
+.sp -482u
+\h'2454u'\D'l -526u 132u'
+.sp -1
+.sp -44u
+\h'964u'\D'l 263u 132u'
+.sp -1
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "proto n
+.sp 2936u
+\h'1271u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "proto 1
+.sp 2015u
+\h'1271u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "mbufs
+.sp 1752u
+\h'2586u'\&\*(g9
+.sp |\n(g8u
+.sp 2892u
+\h'1139u'\D'c 525u'
+.sp -1
+.sp -877u
+\h'1139u'\D'c 525u'
+.sp -1
+.sp 351u
+\h'2016u'\D'c 525u'
+.sp -1
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "switch
+.sp 219u
+\h'438u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "protocol
+.sp -88u
+\h'438u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "transport
+.sp -351u
+\h'438u'\&\*(g9
+.sp |\n(g8u
+.sp -701u
+\h'263u'\D'l 0u 1402u'\D'l 701u 0u'\D'l 0u -1402u'\D'l -701u 0u'
+.sp -1
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "sockets
+.sp -351u
+\h'1402u'\&\*(g9
+.sp |\n(g8u
+.sp -439u
+\h'1139u'\D'c 876u'
+.sp -1
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "tables
+.sp -263u
+\h'2586u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "routing
+.sp -394u
+\h'2586u'\&\*(g9
+.sp |\n(g8u
+.sp -350u
+\h'2454u'\D'c 525u'
+.sp -1
+.sp -1051u
+\h'2366u'\D'c 701u'
+.sp -1
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "management
+.sp 131u
+\h'2454u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "network
+\h'2498u'\&\*(g9
+.sp |\n(g8u
+\D's 4u'\D't 1u'
+.sp -1
+.sp 438u
+\h'1183u'\D'l 789u 0u'
+.sp -1
+.ft I
+.ps 12
+.nr g8 \n(.d
+.ds g9 "kernel
+.sp 176u
+\&\*(g9
+.sp |\n(g8u
+.ft I
+.ps 12
+.nr g8 \n(.d
+.ds g9 "user
+.sp -87u
+\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "drivers
+.sp 2892u
+\h'2629u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "interface
+.sp 2760u
+\h'2629u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "network 
+.sp 2629u
+\h'2629u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "clock
+.sp 438u
+\h'613u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "system calls
+.sp 219u
+\h'1358u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "C library
+.sp -87u
+\h'1402u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "user
+.sp -482u
+\h'657u'\&\*(g9
+.sp |\n(g8u
+.ft B
+.ps 12
+.nr g8 \n(.d
+.ds g9 "program
+.sp -350u
+\h'613u'\&\*(g9
+.sp |\n(g8u
+\D's -1u'\D't 3u'
+.sp -1
+.sp 44u
+\h'1183u'\D'c 788u'
+.sp -1
+.sp 2629u
+\h'2454u'\D'c 701u'
+.sp -1
+.sp -1184u
+\h'2454u'\D'c 525u'
+.sp -1
+.sp -1051u
+\h'438u'\D'c 525u'
+.sp -1
+.sp -876u
+\h'526u'\D'c 525u'
+.sp -1
+.sp 438u
+\h'1183u'\D'l -1183u 0u'
+.sp -1
+\h'1972u'\D'l 1183u 0u'
+.sp -1
+.sp 1270u
+\h'1928u'\D'l 17u 28u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -28u'
+.sp -1
+.sp 1972u
+\D't 3u'\D's -1u'
+.br
+.ft \n(g3
+.ps \n(g4
+.GE
+.ce
+\fBFigure \n+(FG\fR:  IPC in 4.2 Unix
+.)z
diff --git a/share/doc/iso/wisc/intro.nr b/share/doc/iso/wisc/intro.nr
new file mode 100644
index 0000000..5e03515
--- /dev/null
+++ b/share/doc/iso/wisc/intro.nr
@@ -0,0 +1,76 @@
+.NC "Introduction"
+.sh 1 "Introduction"
+.pp
+This document describes the design and implementation of the ISO
+transport and network layers written for the ACIS Operating System,
+the IBM ACIS port of Berkeley 4.3 Unix\**
+.(f
+\** Unix is a registered trademark of AT&T.
+.)f
+for the IBM RT PC,
+hereafter called AOS.
+Collectively, this work is called the Wisconsin ARGO kernel. 
+The ARGO kernel supports the 
+the connection-oriented ISO transport service (COTS), the
+ISO connectionless network service (CLNS)
+and a
+connection-oriented network service (CONS).
+The COTS is provided by the ISO transport protocol TP,
+ISO 8073 Revised.
+The CLNS is provided by the connectionless network protocol,
+ISO 8473.
+The CONS is provided by the X.25 protocols.
+The ARGO implementation of the CONS is not a complete
+ISO CONS, but contains enough of the CONS to support
+the COTS and the CLNS (in the latter case, the CONS can be
+viewed as a subnetwork service).
+.pp
+The purposes of this document are
+.ip "1) "
+to describe the transport service and the software interface
+between the user and provider of this service,
+.ip "2) "
+to describe the network service and the software interface it
+provides,
+.ip "3) "
+to describe the design of the software which provides
+these services, and
+.ip "4) "
+to provide a guide for readers who are perusing or maintaining
+the ARGO kernel source code.
+.pp
+It is assumed that the reader is familiar with the \fBC\fR
+programming language,
+with Unix conventions, and with the ISO specifications listed in Appendix A.
+.sh 1 "Organization"
+.pp
+This document is composed of several chapters.
+Chapter One contains this introduction. Chapter Two presents a
+definition of terms and phrases used throughout the document.
+Chapter Three describes the transport service interface, which is
+the interface between the transport protocol implementation software and the transport user software.
+Chapter Four describes the network service interface, and the interface
+above and below the network layer.
+Chapter Five explains the format of an OSI address.
+Chapter Six describes the
+the architecture of the interprocess communication support in the 
+kernel, which to a large degree mandates
+the design of a protocol implementation for a 4.3 Unix kernel.
+Chapter Seven describes the design of this transport
+protocol implementation,
+including descriptions of implementation options.
+Chapter Eight describes the design of the network layer implementation.
+Chapter Nine describes the way errors are handled in the system.
+Chapter Ten summarizes the methods used for
+testing and debugging the ARGO kernel.
+Appendix A is a list of the applicable ISO standards.
+.\" The manual pages relevant to the transport and network layers
+.\" are included as Appendix B.
+.pp
+Several conventions are followed in this document.
+All procedure names and system call names are followed
+by a pair of parentheses, for example,
+\fIread()\fR.
+References to manual pages consist of the name of the
+manual page, followed by the section in which
+the man page is found: \fIread(2)\fR.
diff --git a/share/doc/iso/wisc/ipc.nr b/share/doc/iso/wisc/ipc.nr
new file mode 100644
index 0000000..9f9d962
--- /dev/null
+++ b/share/doc/iso/wisc/ipc.nr
@@ -0,0 +1,372 @@
+.NC "The Design of Unix IPC"
+.sh 1 "General"
+.pp
+The ARGO implementation of 
+TP and CLNP was designed to fit into the AOS
+kernel
+as easily as possible.
+All the standard protocol hooks are used.
+To understand the design, it is useful to have
+read 
+Leffler, Joy, and Fabry:
+\*(lq4.2 BSD Networking Implementation Notes\*(rq July 1983.
+This section describes the
+design of the IPC support in the AOS kernel.
+.sh 1 "Functional Unit Overview"
+.pp
+The 
+AOS
+kernel
+is a monolithic program of considerable size and complexity.
+The code can be separated into parts of distinct function,
+but there are no kernel processes per se.
+The kernel code is either executed on behalf of a user
+process, in which case the kernel was entered by a system call, 
+or it is executed on behalf of a hardware or software interrupt.
+The following sections describe briefly the major functional units 
+of the kernel.
+.\" FIGURE
+.so figs/func_units.nr
+.CF
+shows the arrangement of these kernel units and 
+their interactions.
+.sh 2 "The file system."
+.pp
+.sh 2 "Virtual memory support."
+.pp
+This includes protection, swapping, paging, and
+text sharing.
+.sh 2  "Blocked device drivers (disks, tapes)."
+.pp
+All these drivers share some minor functional units,
+such as buffer management and bus support
+for the various types of busses on the machine.
+.sh 2 "Interprocess communication (IPC)."
+.pp
+This includes 
+support for various protocols, 
+buffer management, and a standard interface for inter-protocol
+communication.
+.sh 2 "Network interface drivers." 
+.pp
+These drivers are closely tied to the IPC support. 
+They use the IPC's buffer management unit rather
+than the buffers used by the blocked device drivers.
+The interface between these drivers and the rest of the kernel 
+differs from the interface used by the blocked devices.
+.sh 2 "Tty driver" 
+.pp
+This is terminal support, including the user interface
+and the device drivers.
+.sh 2 "System call interface." 
+.pp
+This handles signals, traps, and system calls.
+.sh 2 "Clock." 
+.pp
+The clock is used in various forms by many
+other units.
+.sh 2 "User process support (the rest)." 
+.pp
+This includes support for accounting, process creation, 
+control, scheduling, and destruction.
+.pp
+.sh 2 "IPC"
+.pp
+The major functional unit that supports IPC
+can be divided into the following smaller functional
+units.
+.sh 3 "Buffer management." 
+.pp
+All protocols share a pool of buffers called \fImbufs\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct mbuf {
+.T&
+l l l l.
++struct mbuf+*m_next;+/* next buffer in chain */
++u_long+m_off;+/* offset of data */
++short+m_len;+/* amount of data */
++short+m_type;+/* mbuf type (0 == free) */
++u_char+m_dat[MLEN];+/* data storage */
++struct mbuf+*m_act;+/* link in 2-d structure */
+};
+.TE
+\fR
+.)b
+.pp
+There are two forms of mbufs - small ones and large ones.
+Small ones are 128 octets in 
+AOS
+and 256 octets
+in the ARGO release. Small mbufs are copied by byte-to-byte
+copies.
+The data in these mbufs are kept in the character
+array field \fIm_dat\fR in the mbuf structure
+itself.
+For this type of mbuf, the field \fIm_off\fR is positive,
+and is the offset to the beginning of the data from
+the beginning of the mbuf structure itself.
+Large mbufs, called \fIclusters\fR, are page-sized
+and page-aligned.
+They may be \*(lqcopied\*(rq by multiply mapping the pages they occupy.
+They consist of a page of memory plus a small mbuf structure 
+whose fields are used
+to link clusters into chains, but whose \fIm_dat\fR array is 
+not used.
+The \fIm_off\fR field of the structure 
+is the offset (positive or negative) from the
+beginning of the mbuf structure to the beginning
+of the data page part of the cluster.
+In the case of clusters, the offset is always out of the
+bounds of the \fIm_dat\fR array and so it is alway possible
+to tell from the \fIm_off\fR field whether an mbuf structure
+is part of a cluster or is a small mbuf.
+All mbufs permanently reside in memory.
+The mbuf management unit manages its own page table. 
+The mbuf manager keeps limited statistics on the quantities and
+types of buffers in use.
+Mbufs are used for many purposes, and most of these purposes
+have a type associated with them.
+Some of the types that buffers may take are
+MT_FREE (not allocated), MT_DATA,
+MT_HEADER, MT_SOCKET (socket structure),
+MT_PCB (protocol control block),
+MT_RTABLE (routing tables),
+and
+MT_SOOPTS (arguments passed to \fIgetsockopt()\fR and 
+\fIsetsockopt()\fR.
+Data are passed among functional units by means
+of queues, the contents of which are
+either chains of mbufs or groups of chains of mbufs.
+Mbufs are linked into chains with the \fIm_next\fR field.
+Chains of mbufs are linked into groups with the \fIm_act\fR
+field.
+The \fIm_act\fR field allows a protocol to retain packet
+boundaries in a queue of mbufs.
+.sh 3 "Routing." 
+.pp
+Routing decisions in the kernel are made by the procedure \fIrtalloc()\fR.
+This procedure will scan the kernel routing tables (stored in mbufs)
+looking for a route. A route is represented by
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct rtentry {
+.T&
+l l l l.
++u_long+rt_hash;+/* to speed lookups */
++struct sockaddr+rt_dst;+/* key */
++struct sockaddr+rt_gateway;+/* value */
++short+rt_flags;+/* up/down?, host/net */
++short+rt_refcnt;+/* # held references */
++u_long+rt_use;+/* raw # packets forwarded */
++struct ifnet+*rt_ifp;+/* interface to use */
+}
+.TE
+\fR
+.)b
+When looking for a route, \fIrtalloc()\fR will first hash the entire destination
+address, and scan the routing tables looking for a complete route. If a route
+is not found, then \fIrtalloc()\fR will rescan the table looking for a route
+which matches the \fInetwork\fR portion of the address. If a route is still
+not found, then a default route is used (if present). 
+.pp
+If a route is found, the entity which called \fIrtalloc()\fR can use information
+from the \fIrtentry\fR structure to dispatch the datagram. Specifically, the
+datagram is queued on the interface identified by the interface 
+pointer \fIrt_ifp\fR.
+.sh 3 "Socket code." 
+.pp
+This is the protocol-independent part of the IPC support.
+Each communication endpoint (which may or may not be associated
+with a connection) is represented by the following structure:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct socket {
+.T&
+l l l l.
++short+so_type;+/* type, e.g. SOCK_DGRAM  */
++short+so_options;+/* from socket call */
++short+so_linger;+/* time to linger @ close */
++short+so_state;+/* internal state flags */
++caddr_t+so_pcb;+/* network layer pcb */
++struct protosw+*so_proto;+/* protocol handle */
++struct socket+*so_head;+/* ptr to accept socket */
++struct socket+*so_q0;+/* queue of partial connX */
++short+so_q0len;+/* # partials on so_q0 */
++struct socket+*so_q;+/* queue of incoming connX */
++short+so_qlen;+/* # connections on so_q */
++short+so_qlimit;+/* max # queued connX */
++struct sockbuf+{
+++short+sb_cc;+/* actual chars in buffer */
+++short+sb_hiwat;+/* max actual char count */
+++short+sb_mbcnt;+/* chars of mbufs used */
+++short+sb_mbmax;+/* max chars of mbufs to use */
+++short+sb_lowat;+/* low water mark (not used yet) */
+++short+sb_timeo;+/* timeout (not used ) */
+++struct mbuf+*sb_mb;+/* the mbuf chain */
+++struct proc+*sb_sel;+/* process selecting */
+++short+sb_flags;+/* flags, see below */
++} so_rcv, so_snd;
++short+so_timeo;+/* connection timeout */
++u_short+so_error;+/* error affecting connX */
++short+so_oobmark;+/* oob mark (TCP only) */
++short+so_pgrp;+/* pgrp for signals */
+}
+.TE
+\fR
+.)b
+.pp
+The socket code maintains a pair of queues for each socket,
+\fIso_rcv\fR and \fIso_snd\fR.
+Each queue is associated with a count of the number of characters
+in the queue, the maximum number of characters allowed to be put
+in the queue, some status information (\fIsb_flags\fR), and
+several unused fields.
+For a send operation, data are copied from the user's address space
+into chains of mbufs.
+This is done by the socket module, which then calls the underlying
+transport protocol module to place the data
+on the send queue. 
+This is generally done by 
+appending to the chain beginning at \fIsb_mb\fR.
+The socket module copies data from the \fIso_rcv\fR queue
+to the user's address space to effect a receive operation.
+The underlying transport layer is expected to have put incoming
+data into \fIso_rcv\fR by calling procedures in this module.
+.in -5
+.sh 3 "Transport protocol management."
+.pp
+All protocols and address types must be \*(lqregistered\*(rq in a
+common way in order to use the IPC user interface.
+Each protocol must have an entry in a protocol switch table.
+Each entry takes the form:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct protosw {
+.T&
+l l l l.
++short+pr_type;+/* socket type used for */
++short+pr_family;+/* protocol family */
++short+pr_protocol;+/* protocol # from the database */
++short+pr_flags;+/* status information */
++++/* protocol-protocol hooks */
++int+(*pr_input)();+/* input (from below) */
++int+(*pr_output)();+/* output (from above) */
++int+(*pr_ctlinput)();+/* control input */
++int+(*pr_ctloutput)();+/* control output */
++++/* user-protocol hook */
++int+(*pr_usrreq)();+/* user request: see list below */
++++/* utility hooks */
++int+(*pr_init)();+/* initialization hook */
++int+(*pr_fasttimo)();+/* fast timeout (200ms) */
++int+(*pr_slowtimo)();+/* slow timeout (500ms) */
++int+(*pr_drain)();+/* free some space (not used) */
+}
+.TE
+\fR
+.)b
+.pp
+Associated with each protocol are the types of socket
+abstractions supported by the protocol (\fIpr_type\fR), the
+format of the addresses used by the protocol (\fIpr_family\fR),
+the routines to be called to perform
+a standard set of protocol functions (\fIpr_input\fR,...,\fIpr_drain\fR),
+and some status information (\fIpr_flags\fR).
+The field pr_flags keeps such information as
+SS_ISCONNECTED (this socket has a peer),
+SS_ISCONNECTING	(this socket is in the process of establishing
+a connection),
+SS_ISDISCONNECTING (this socket is in the process of being disconnected),
+SS_CANTSENDMORE (this socket is half-closed and cannot send),
+SS_CANTRCVMORE (this socket is half-closed and cannot receive).
+There are some flags that are specific to the TCP concept
+of out-of-band data.
+A flag SS_OOBAVAIL was added for the ARGO implementation, to support
+the TP concept of out-of-band data (expedited data).
+.sh 3 "Network Interface Drivers" 
+.pp
+The drivers for the devices attaching a Unix machine to a network
+medium share a common interface to the protocol
+software.
+There is a common data structure for managing queues,
+not surprisingly, a chain of mbufs.
+There is a set of macros that are used to enqueue and
+dequeue mbuf chains at high priority.
+A driver 
+delivers an indication to a protocol entity when
+an incoming packet has been placed on a queue by 
+issuing a
+software
+interrupt.
+.sh 3 "Support for individual protocols." 
+.pp
+Each protocol is written as a separate functional unit.
+Because all protocols share the clock and the mbuf pool, they
+are not entirely insulated from each other.
+The details of TP are described in a section that
+follows.
+.\"*****************************************************
+.\" FIGURE
+.so figs/unix_ipc.nr
+.pp
+.CF
+shows the arrangement of the IPC  support.
+.pp
+The AOS
+IPC was designed for DoD Internet protocols, all of
+which run over DoD IP.
+The assumptions that DoD Internet is the domain
+and that DoD IP is the network layer 
+appear in the code and data structures in numerous places.
+For example, it is assumed that addresses can be compared
+by a bitwise comparison of 4 octets.
+Another example is that the transport protocols all directly call
+IP routines.
+There are no hooks in the data structures through
+which the transport layer can choose a network level protocol.
+A third example is that the host's local addresses
+are stored in the network interface drivers and the drivers
+have only one address - an Internet address.
+A fourth example is that headers are assumed to
+fit in one small mbuf (112 bytes for data in AOS).
+A fifth example is this:
+It is assumed in many places that buffer space is managed
+in units of characters or octets.
+The user data are copied from user address space into the kernel mbufs
+amorphously
+by the socket code, a protocol-independent part of the kernel.
+This is fine for a stream protocol, but it means that a
+packet protocol, in order to \*(lqpacketize\*(rq the data,
+must perform a memory-to-memory copy
+that might have been avoided had the protocol layer done the original
+copy from user address space.
+Furthermore, protocols that count credit in terms of packets or
+buffers rather than characters do not work efficiently because
+the computation of buffer space is not in the protocol module,
+but rather it is in the socket code module.
+This list of examples is not complete.
+.pp
+To summarize, adding a new transport protocol to the kernel consists of
+adding entries to the tables in the protocol management
+unit, 
+modifying the network interface driver(s) to recognize
+new network protocol identifiers, 
+adding the
+new system calls to the kernel and to the user library,
+and
+adding code modules for each of the protocols,
+and correcting deficiencies in the socket code,
+where the assumptions made about the nature of 
+transport protocols do not apply. 
diff --git a/share/doc/iso/wisc/macros.nr b/share/doc/iso/wisc/macros.nr
new file mode 100644
index 0000000..a3624c9
--- /dev/null
+++ b/share/doc/iso/wisc/macros.nr
@@ -0,0 +1,50 @@
+.\"	
+.\" Macro to initialize chapter macros
+.\"	
+.de IC
+.nr CN 0 1
+..
+.\"	
+.\" Macro to begin new chapter
+.\"	
+.de NC
+.he 'ARGO Kernel Programmer\'s Guide''Chapter \\n+(CN'
+.bp
+.sh 0 "_" 1 1 1 1 1 1
+.sz +2
+.(l C
+CHAPTER \\n(CN
+
+\fB\\$1\fR
+.)l
+.sp 1
+.(x
+Chapter \\n(CN     \\$1
+.)x
+.sz -2
+..
+.\"	
+.\"	Figure conventions:
+.\"	1) do .so of figure source - figure reg incremented here
+.\"	2) make references to figure via CF
+.\"	
+.\"	
+.\"	Macro to initialize figure register
+.\"	
+.de IF
+.nr FG 0 1
+..
+.\"	
+.\"	Macro for current figure number
+.\"	
+.de CF
+Figure \\n(FG
+..
+.\"
+.\"	Define this macro to include section headings in table of contents
+.\"
+.de $0
+.(x
+Section \\$2 \\$1
+.)x
+..
diff --git a/share/doc/iso/wisc/net_design.nr b/share/doc/iso/wisc/net_design.nr
new file mode 100644
index 0000000..d066f8e
--- /dev/null
+++ b/share/doc/iso/wisc/net_design.nr
@@ -0,0 +1,1139 @@
+.NC "The Design of the ARGO Network Layer"
+.sh 1 "Connectionless Network Layer
+.pp
+The following sections describe the design of the ARGO
+connectionless network layer (CLNL).
+The connectionless network service is provided by several
+network-layer protocols: ES-IS (ISO 9542), 
+CLNP (ISO 8348), and (ISO 8208) X.25.
+The protocol CLNP is the primary connectionless network layer
+protocol.
+It is supported by X.25 when X.25 is used as a subnetwork layer.
+X.25 can also be viewed as a link layer protocol in this context.
+The ES-IS protocol supports CLNP by providing the following functions:
+.ip \(bu 5
+automatic mapping of NSAP-addresses to SNPA addresses,
+.ip \(bu 5
+automatic configuration of networks of end systems and intermediate
+systems,  and
+.ip \(bu 5
+redirection of network-layer traffic in response to 
+configuration changes.
+.pp
+The rest of this chapter describes the design of 
+CLNP, the design of  ES-IS,
+and the design of the connection-oriented
+network layer, including the connection-oriented subnetwork service (X.25).
+.pp
+CLNP has two subsets defined: the Inactive Network Layer 
+protocol subset and the Non-Segmenting protocol subset. 
+The Inactive Network Layer subset is a null-function subset 
+in which the CLNP is not needed, and the 
+protocol consists of sending
+a 1-byte header containing the value zero. 
+This "subset" is not supported in ARGO.
+.pp
+The Non-Segmenting protocol subset permits simplification of the DT NPDU
+header when it is known that segmentation of the DT NPDU is not required.
+ARGO supports this subset.
+When this subset is used, 
+the segmentation part of the DT NPDU (data packet) header is not present, 
+and the \fIdon't segment\fR bit is set in the 
+fixed part of the header. 
+This subset is chosen by setting the bit
+\fICLNP_NO_SEG\fR in the \fIflags\fR argument to \fIclnp_output()\fR.
+.pp
+Throughout the remainder of this
+document,
+following definitions apply:
+.(b
+\(bu DT NPDU: data transfer NPDU.
+\(bu ER NPDU: error report NPDU.
+\(bu NPDU: either an ER or DT NPDU.
+.)b
+.sh 2 "DT NPDU Output"
+.pp
+A CLNP DT NPDU is transmitted by calling \fIclnp_output()\fR. 
+.so figs/clnp_output.nr
+.\" FIGURE
+.CF
+outlines the sequence of steps taken by \fIclnp_output()\fR when
+transmitting an NPDU. 
+The solid lines indicate normal flow of control. The
+dashed lines indicate possible error returns (with associated
+error code).
+.pp
+\fIClnp_output()\fR will automatically cache (in the \fIisopcb\fR)
+the header of each packet it sends. This cached copy of the header
+is used on subsequent sends reducing the amount of time spent generating
+the header. Therefore, the first action \fIclnp_output()\fR takes is to
+examine the cached header (if any). If the header is still valid (see below)
+then it is used. Otherwise, a new header is built.
+.sh 3 "When The Cached Header Is Invalid"
+.pp
+Before any resources are allocated, the options to be sent with the packet
+are examined. If any unsupported options are present, the error \fIEINVAL\fR
+is returned.
+Next, the length of the source and destination 
+NSAP addresses (taken from the \fIisopcb\fR)
+are checked. The source address length may be zero. This
+indicates that \fIclnp_output()\fR should compute the source address based upon
+the route taken, in which case CLNP calls
+the function \fIclnp_srcroute()\fR.
+Source routing 
+will be discussed in detail later in this section.
+If, in the process of checking
+the address lengths, an invalid length is detected, the error
+\fIENAMETOOLONG\fR is returned.
+.pp
+After checking the lengths of the addresses, 
+CLNP allocates an \fImbuf\fR in which the DT NPDU header will be constructed. 
+If an \fImbuf\fR cannot be found, the error
+\fIENOBUFS\fR is returned. Once the \fImbuf\fR is allocated, 
+the fixed part of the DT NPDU header is copied into the \fImbuf\fR.
+.pp
+The next step is to route the DT NPDU. This is accomplished by the
+\fIclnp_route()\fR function. 
+It is necessary to route the datagram early in the output process because
+in many cases, the source address will not be known until the route
+has been created.
+When a system is multi-homed it has several source addresses. 
+The source address to choose depends on the
+network interface (thus, the route) used.
+.pp
+The address part of the DT NPDU follows the fixed part. 
+Since appending the address part is the next task, 
+the source address must be determined.
+Therefore the route must be determined.
+.pp
+After appending the address part to the fixed part of the
+NPDU header, CLNP
+appends any options given in the arguments to 
+\fIclnp_output()\fR.
+The options are specified in a
+separate \fImbuf\fR stored in the \fIiso_pcb\fR.
+If this \fImbuf\fR
+pointer is not null, a copy of the \fImbuf\fR is made, and this copy is 
+chained (appended) to the
+\fImbuf\fR in which the
+NPDU header resides. The options \fImbuf\fR linked in with the DT packet
+must be a copy of the options \fImbuf\fR passed to \fIclnp_output()\fR. If
+this was not done, then
+the options \fImbuf\fR passed would be freed by the interface
+driver after the NPDU had been transmitted.
+Since a copy must be made, it is possible for \fIclnp_output()\fR to
+return \fIENOBUFS\fR at this time.
+A later section of this chapter describes
+the handling of options in greater detail.
+.pp
+User data for the packet are passed to 
+\fIclnp_output()\fR as an \fImbuf\fR chain.
+This \fImbuf\fR chain is appended to the DT NPDU header chain. 
+At this point, the DT NPDU is ready for transmission. 
+If header caching has not been disabled, a cache entry is made in the 
+\fIisopcb\fR.
+If the size of the entire packet 
+is less than the maximum transmission unit (MTU) of the 
+network interface to be used,
+the packet is placed on the queue for that network interface,
+otherwise \fIclnp_fragment()\fR is invoked to
+break up the packet into smaller packets, called
+"derived NPDUs", and transmit the derived NPDUs.
+.sh 3 "When A Cached Header Exists"
+.pp
+In this case, \fIclnp_output()\fR updates the segmentation part of the
+header (if segmenting is permitted), computes the checksum, and transmits
+(or fragments) the packet.
+.pp
+The cached CLNP header is stored in the \fIstruct isopcb\fR. The field
+\fIisop_clnpcache\fR within the \fIisopcb\fR points to an \fImbuf\fR
+which contains a \fIstruct clnp_cache\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+struct clnp_cache {
+.T&
+l l l l.
++u_short+cni_securep;+/* ptr to security option */
++struct iso_addr+clc_dst;+/* destination of packet */
++struct mbuf+*clc_options;+/* ptr to options mbuf */
++int+clc_flags;+/* flags passed to clnp_output */
++int+clc_segoff;+/* offset of seg part of header */
++struct sockaddr+*clc_firsthop;+/* first hop of packet */
++struct ifnet+*clc_ifp;+/* ptr to interface */
++struct mbuf+*clc_hdr;+/* cached pkt hdr (finally)! */
+};
+.TE
+\fR
+.)b
+The first three fields \fIclc_dst, clc_options\fR and \fIclc_flags\fR
+are used to check the validity of the cache entry. The cache is considered
+valid if:
+.ip \(bu 5
+The options mbuf has not changed.
+.ip \(bu 5
+The destination of the packet has not changed.
+.ip \(bu 5
+The route still exists and is up.
+.ip \(bu 5
+The flags have not changed.
+.pp
+If all these conditions are met, then the bulk of the \fIclnp_output()\fR
+processing is avoided. The fields \fIclc_segoff, clc_firsthop,\fR 
+and \fIclc_ifp\fR are used by \fIclnp_output()\fR to transmit the packet.
+The field \fIclc_ifp\fR contains the actual cached header which is copied
+and then enqueued on the outgoing interface.
+.sh 2 "NPDU Input"
+.pp
+.\" FIGURE
+.so figs/clnp_input.nr
+All CLNP NPDUs are processed by \fIclnp_input()\fR. 
+.CF
+outlines
+the flow of control within \fIclnlintr()\fR and \fIclnp_input()\fR. 
+The solid lines
+indicate normal flow of control. The dashed lines indicate 
+possible error returns.
+.pp
+\fIClnlintr()\fR is invoked by a software interrupt. 
+This interrupt is posted by a device driver whenever a 
+packet is placed in CLNL's input queue 
+\fIclnlintrq()\fR, and the queue is empty. 
+It is the responsibility of \fIclnlintr()\fR, when invoked, 
+to process all packets present on the input queue. 
+Thus, to begin the task of processing a packet, \fIclnlintr()\fR
+removes the next packet from the queue. 
+When an error is discovered during processing, the packet is discarded and
+\fIclnlintr()\fR begins afresh.
+.pp
+Once removed, the type of the NPDU is checked. If the NPDU is an
+ES-IS packet, then \fIesis_input()\fR is called. If the NPDU is a CLNP
+packet, then \fIclnp_input()\fR is called. Other packets are silently
+discarded.
+The function \fIclnp_hdr_ck()\fR checks the NPDU for consistency. 
+Before checking consistency, \fIclnp_hdr_ck()\fR insures
+that the entire NPDU header is located
+contigiously in a single \fImbuf\fR (\fIm_pullup()\fR\** performs this task).
+.(f
+\** If the NPDU header is larger than \fIMLEN\fR (currently 256), then
+\fIm_pullup()\fR will allocate a cluster \fImbuf\fR.
+.)f
+After "pulling" the header into a single \fImbuf\fR, \fIclnp_hdr_ck()\fR
+checks for the proper CLNP version and protocol identification. 
+It also checks that the lifetime field is greater than zero.
+After checking header consistency, the NPDU checksum is computed.\**
+.(f
+\** If the checksum value is zero, the checksum is not computed. 
+The value zero is reserved to mean \*(lqdo not use checksum\*(rq.
+.)f
+If the checksum is valid, \fIclnp_data_ck()\fR is called to insure
+that the amount of data in the \fImbuf\fR chain corresponds to the
+amount indicated in the NPDU header.
+.pp
+Once the consistency of the NPDU has been assured, the various parts of the
+packet are extracted. 
+Care is taken with each extraction to insure that an attempt is not made
+to address data that does not really exist. (Such an attempt could
+result in a kernel trap).
+.pp
+Next, the options part of the NPDU, if present, is checked for validity.
+If unsupported options are found, the packet is discarded. 
+See the section \*(lqNPDU options\*(rq for details of options processing.
+.pp
+Finally, after the preceding checks and extractions have been made, the
+destination address is examined. 
+If the address indicates that the packet's destination is not this
+system, the packet is forwarded by calling \fIclnp_forward()\fR. 
+See the section \*(lqDT NPDU Forwarding\*(rl for details of packet forwarding.
+If this end system is the
+packet's destination, processing continues.
+.pp
+If the packet is not complete, it is passed to \fIclnp_reass()\fR for
+reassembly. 
+See the section \*(lqDT NPDU Reassembly\*(rq
+for details of packet reassembly.
+.pp
+At this point, a complete NPDU is in hand. 
+If the NPDU is a DT NPDU, it is given to the transport layer
+by calling the TP input routine. 
+Otherwise, it is give to the ER NPDU processing function, 
+\fIclnp_er_input()\fR.
+.sh 3 "DT NPDU Forwarding"
+.pp
+Packet forwarding is accomplished by \fIclnp_forward()\fR. 
+This is performed regardless of the system's type (end or intermediate).
+The task of
+forwarding a packet is fairly straight-forward. First, the lifetime
+field of the datagram is decremented. 
+If this operation changes the value to zero, the packet is discarded.
+.pp
+If the source route option is present, and the address at the top of the list
+matches an address of one of the system's network interfaces, then
+the next-source-route-to-be-used offset is adjusted in the option.
+Next, the packet is routed by \fIclnp_route()\fR
+or \fIclnp_srcroute()\fR. 
+If the record route option is present, the address of the outgoing 
+network interface is recorded by \fIclnp_dooptions()\fR.
+.pp
+Finally the packet is dispatched. 
+If the size of the entire packet is less than the MTU of the output 
+network interface, the packet is enqueued for that interface, 
+otherwise \fIclnp_fragment()\fR is invoked to
+fragment the packet and enqueue the derived NPDUs.
+.sh 2 "NPDU Options"
+.pp
+The options section of an NPDU consists of a series of triplets:
+\fIoption identification\fR, \fIoption length\fR, 
+and \fIoption value\fR. 
+These triplets are checked each time the options are examined or changed. 
+To avoid repeated parsing of the options, the ARGO CLNP
+maintains an index. 
+This index is organized as a \fIclnp_optidx\fR structure. 
+This structure is shown below.
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+struct clnp_optidx {
+.T&
+l l l l.
++u_short+cni_securep;+/* ptr to security option */
++char+cni_secure_len;+/* length of security option */
++u_short+cni_srcrt_s;+/* offset of src rt option */
++u_short+cni_srcrt_len;+/* length of src rt option */
++u_short+cni_recrtp;+/* ptr to head of recrt option */
++char+cni_recrt_len;+/* length of recrt option */
++char+cni_priorp;+/* ptr to priority option */
++u_short+cni_qos_formatp;+/* ptr to format of qos option */
++char+cni_qos_len;+/* length of qos option */
++char+cni_er_reason;+/* reason from ER pdu option */
+};
+.TE
+.)b
+This index allows CLNP quickly to discover the existence 
+and value of an option. 
+For example, if a security option is present, the \fIcni_securep\fR
+field of the option index is non-zero and the value of
+\fIcni_securep\fR is an offset to the beginning of the 
+security option. 
+The function \fIclnp_opt_sanity()\fR 
+parses the options and computes the index.
+While parsing, it also verifies that the 
+options are valid and correctly structured.
+If an error occurs while parsing an option, 
+\fIclnp_opt_sanity()\fR returns an error code. 
+The following sections describe how options are processed
+during the send, forward and receive operations.
+.sh 3 "Sending Options"
+.pp
+Options to be sent with a datagram are passed to \fIclnp_output()\fR as
+two arguments. An option index is passed along with an \fImbuf\fR
+containing the options. 
+The options in the \fImbuf\fR must be formatted
+exactly as specified by CLNP. 
+If the security, quality of service, or
+priority options are specified, \fIclnp_output()\fR will not transmit the
+datagram and \fIEINVAL\fR is returned.
+The system call \fIsetsockopt()\fR is used to set the CLNP options 
+to be sent on a datagram. 
+See \fIclnp(4)\fR for more information about setting CLNP options.
+.pp
+If a source route is specified, 
+the normal CLNP routing function \fIclnp_route()\fR is not used, and 
+\fIclnp_srcroute()\fR is invoked.
+.pp
+When the DECBIT config option is specified, \fIclnp_output\fR will
+automatically add the globally unique quality of service option to the packet.
+The sequencing preferred and low delay bits in this option are set.
+.sh 3 "Forwarding Options"
+.pp
+During packet forwarding, the padding, security,
+and priority options are ignored. If record route is selected, the
+function \fIclnp_dooptions()\fR logs the current network
+interface address in the record route list.
+.pp
+If a source route is specified, 
+the normal CLNP routing function \fIclnp_route()\fR is not used, and 
+\fIclnp_srcroute()\fR is invoked.
+.sh 4 "The Congestion Experienced Bit"
+.pp
+If a packet is forwarded containing the globally unique quality of
+service option, and the interface through which the packet will be 
+transmitted has a queue length greater than \fIcongest_threshold\fR,
+then the congestion experienced bit is set in the quality of service option.
+.pp
+The threshold value stored in \fIcongest_threshold\fR may be changed
+with the \fIclnlutil\fR utility.
+.sh 3 "Receiving Options"
+.pp
+On receipt, all CLNP options are ignored except the security 
+and globally unique quality of service option.
+If the security option is found, the packet is discarded.
+If the globally unique quality of service option is present, and the
+congestion experienced bit is set, then the transport congestion
+control function \fItpclnp_ctlinput(PRC_QUENCH2, addr)\fR is called.
+The following table summarizes the CLNP option processing.
+.(b
+.TS
+allbox, tab(+);
+l l l l.
+Option+Send+Forward+Receive
+=
+Padding+may be set+-+-
+Security+reject+ignore+discard
+Source Route+\fIclnp_srcroute()\fR+\fIclnp_srcroute()\fR+-
+Record Route+-+\fIclnp_dooptions()\fR+-
+QOS+added+congestion bit set+tpclnp_ctlinput()
+Priority+reject+ignore+-
+.TE
+.)b
+.sh 2 "DT NPDU Segmentation"
+.pp
+Segmentation is the process by which initial NPDUs are segmented into 
+smaller derived NPDUs when the initial NPDU is too large for transmission
+on a network interface.
+Segmentation is accomplished by \fIclnp_fragment()\fR. 
+This function chops the NPDU into pieces and individually places the pieces
+in the appropriate network interface's output queue. 
+Each piece is made as large as possible. 
+Note: The phrase "fragmentation" is used synonymously with "segmentation"
+throughout this prose and the CLNP fragmentation code. This is due to 
+this author's familiarity with the DoD Internet Protocol which uses
+the term "fragment."
+.sh 2 "DT NPDU Reassembly"
+.pp
+Derived NPDUs are put back together by the process called 
+reassembly. 
+Reassembly is performed only at the destination end system.
+When a derived NPDU arrives, it is passed to \fIclnp_reass()\fR. 
+This function scans a linked list of NPDUs awaiting reassembly. 
+Each packet in the list is represented by a fragment list
+descriptor, which is stored in an \fImbuf\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct clnp_fragl {
+.T&
+l l l l.
++struct iso_addr+cfl_src;+/* source */
++struct iso_addr+cfl_dst;+/* destination */
++u_short+cfl_id;+/* id of the pkt */
++u_char+cfl_ttl;+/* time to live */
++u_short+cfl_last;+/* offset of last 
++++byte of packet */
++struct mbuf +*cfl_orighdr;+/* ptr to 
++++original header */
++struct clnp_frag+*cfl_frags;+/* linked list 
++++of fragments */
++struct clnp_fragl+*cfl_next;+/* next pkt be-
++++ing reassembled */
+};
+.TE
+\fR
+.)b
+The fields \fIcfl_src\fR, \fIcfl_dst\fR, and \fIcfl_id\fR are used to
+match an incoming derived NPDU with a fragment list. 
+\fICfl_orighdr\fR contains a copy of the NPDU header of the first fragment received. 
+The linked list of fragments pertaining to the packet is stored in the
+\fIcfl_frags\fR field. 
+Each NPDU fragment represented by a \fIclnp_frag\fR structure, 
+stored in an \fImbuf\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct clnp_frag {
+.T&
+l l l l.
++u_int+cfr_first;+/* offset of 
++++first byte of this frag */
++u_int+cfr_last;+/* offset of last 
++++byte of this frag */
++u_int+cfr_bytes;+/* bytes to shave */
++struct mbuf+*cfr_data;+/* ptr to data */
++struct clnp_frag+*cfr_next;+/* next frag */
+};
+.TE
+\fR
+.)b
+The fields \fIcfr_first\fR and \fIcfr_last\fR indicate the first and
+last octet of the fragment. 
+\fICfr_data\fR points to an mbuf chain
+which contains the data for the fragment.
+.pp
+If \fIclnp_reass()\fR finds a \fIclnp_fragl\fR structure matching the
+incoming derived NPDU, \fIclnp_insert_frag()\fR is called to create
+a \fIclnp_frag\fR structure and insert it in the linked list of
+packet fragments. 
+If no \fIclnp_fragl\fR structure is found, 
+\fIclnp_newpkt()\fR is invoked to create a new fragment list structure.
+.pp
+The last task \fIclnp_reass()\fR performs is to check if the fragment
+that just arrived completes the reassembly of the initial NPDU. 
+If it does, the reassembled NPDU is rearranged to 
+look like it just arrived intact.
+It accomplishes this by linking the \fImbuf\fRs holding
+the fragments into one \fImbuf\fR chain that represents the initial
+NPDU.
+A pointer to this \fImbuf\fR chain is returned by \fIclnp_reass()\fR.
+.pp
+If the newly arrived fragment does not complete an initial NPDU, 
+\fIclnp_reass()\fR returns NULL.
+.sh 3 "Reassembly Lifetime Control"
+.pp
+One function of the CLNP is to prevent
+a proliferation of fragments awaiting reassembly from
+consuming buffers in an end system for indefinite periods of time.
+This function is called reassembly lifetime control.
+It is accomplished by 
+periodic traversal of
+the list of \fIclnp_fragl\fR structures, decrementing the 
+\fIcfl_ttl\fR field. 
+This field is a copy of the NPDU time-to-live
+field. If \fIcfl_ttl\fR reaches zero, all resources associated with the
+fragment are released.
+The procedure
+\fIclnp_slowtimo()\fR, which is called by the system
+clock every 500 milliseconds (every half-second),
+performs the CLNP reassembly lifetime control.
+.sh 2 "ER NPDU"
+.pp
+An ER NPDU is sent to the originator of a packet when a DT NPDU is
+discarded and the error report function is not suppressed. Suppression
+of the error report function is accomplished by setting the "no ER"
+bit in the CLNP header.
+A packet is discarded by \fIclnp_discard()\fR. 
+Before it
+returns the \fImbufs\fR used to store the 
+the discarded packet to the \fImbuf\fR free list,
+\fIclnp_discard()\fR 
+determines if the error report function is suppressed. 
+If not, 
+an ER NPDU will be sent to the originator of the discarded packet by
+calling \fIclnp_emit_er()\fR.
+.pp
+\fIClnp_emit_er()\fR will create an ER NPDU, address it to the 
+originator of the discarded packet, route the NPDU, 
+and transmit it, sending the header of the discarded NPDU as data. 
+ER NPDUs may not be segmented. 
+If the ER NPDU is too large for the outgoing network interface, 
+the packet is truncated.
+.sh 2 "Raw CLNP"
+.pp
+In order to test CLNP in isolation from higher layer
+protocols, ARGO provides a \*(lqraw\*(rq interface to CLNP.
+This raw interface is selected with the \fISOCK_RAW\fR parameter to
+the
+\fIsocket()\fR
+system call.
+When a \*(rqraw\*(rq socket is open,
+and CLNP receives an NPDU,
+CLNP must determine whether the incoming NPDU is destined for
+the 
+\*(rqraw\*(rq interface or for the interface to the 
+OSI transport protocol entity.
+ARGO addresses this problem by using non-standard NPDU types
+for packets sent on \*(rqraw\*(rq sockets.
+The type field in the CLNP NPDU header
+is set to \fICLNP_RAW\fR (hex 1d) rather than \fICLNP_DT\fR
+in NPDUs that originate from 
+\*(rqraw\*(rq sockets.
+This non-standard type value is used by \fIclnp_input()\fR
+to decide which upper layer protocol should receive the packet.
+See \fIclnptest(8)\fR for more information about the.
+\*(rqraw\*(rq CLNP interface.
+.sh 2 "CLNP Echo"
+.pp
+In the DoD world, ICMP supports an \fIecho\fR service. 
+This allows one to \*(lqping\*(rq a distant gateway and 
+to receive an echo response (a packet in return) if the gateway is working.
+There is no counterpart to \*(lqecho\*(rq in ISO 8473 (CLNP). 
+ARGO provides this non-standard feature in its connectionless
+network layer.
+.pp
+Like raw CLNP, implementing an echo function requires a non-standard
+NPDU type value to allow
+\fIclnp_input()\fR to differentiate between a DT NPDU to be forwarded
+or passed to a higher layer protocol, and an NPDU that is to be echoed.
+When requesting an echo, 
+the CLNP type field is set to \fICLNP_EC\fR (hex 1E) rather
+than CLNP_DT. 
+When \fIclnp_input()\fR receives a packet with type
+\fICLNP_EC\fR, 
+it swaps the source and destination addresses, sets the
+type field to \fICLNP_ECR\fR (hex 1F) and forwards
+the packet back to the sender. 
+See also \fIclnpping(8)\fR.
+.sh 2 "Timers"
+.pp
+The only timer used by CLNP is the 
+500 millisecond timer, which is 
+user for reassembly lifetime control.
+See the section \*(lqReassembly Lifetime Control.\*(rq
+.sh 1 "End System to Intermediate System Routing Protocol (ES-IS)"
+.\" ROB
+.sh 2 "Overview"
+.pp
+This section describes the implementation of the ES-IS routing protocol.
+This protocol is used primarily to resolve NSAP address to SNPA address 
+translations. It is also used to identify end systems
+and intermediate systems on
+the local subnetwork. 
+All of this work is accomplished by transmitting
+packets of the type End System Hello (ESH), Intermediate System Hello (ISH)
+and Request Redirect (RD).
+.pp
+For the purpose of this section, the following definitions of end system (ES)
+and intermediate system (IS) apply.
+.ip \(bu 5
+An \fIend system\fR is an open system that
+is an OSI end system in the standard OSI sense
+(that it supports a full OSI protocol suite in addition to the network layer)
+and that
+implements the functions of the
+the ES-IS protocol that are mandatory for end systems,
+such as the Query Configuration function and the Record Redirect
+function,
+but that does not implement
+the functions of the ES-IS protocol that are for intermediate systems.
+.ip \(bu 5
+An \fIintermediate system\fR is an open system that
+is an OSI intermediate system in the standard OSI sense
+(that it performs packet routing in the network layer)
+and that
+implements the functions of the
+the ES-IS protocol that are mandatory for intermediate systems,
+such as the Request Redirect function, 
+but not the functions of the ES-IS protocol that are for end systems.
+.pp
+While system may be an ES or an IS or both according to the
+standard OSI definitions, this is not the case in the context of
+the ES-IS protocol.
+.pp
+An ARGO system is by default an end system, by the definitions given above.
+An ARGO system can be made to function as an intermediate system
+instead of an end system with the \fIclnlutil\fR program. 
+See \fIclnlutil(8)\fR for more information.
+.sh 2 "Report Configuration Function"
+.pp
+The report configuration function is used by end systems and intermediate
+systems to inform each other of their reachability and current subnetwork
+addresses. 
+This function is invoked whenever the configuration timer
+expires. 
+This timer fires at a frequency of once every
+\fIesis_config_time\fR seconds. 
+By default, this value is 60 (seconds), 
+but it may be changed with the \fIclnlutil\fR program.
+.pp
+The report configuration function is contained in the C function 
+\fIesis_config()\fR. Called every \fIesis_config_time\fR seconds, 
+\fIesis_config()\fR searches the list of active network interfaces
+calling \fIesis_shoutput\fR for each interface that is up, has
+broadcast ability and has an ISO address configured.
+.pp
+The function \fIesis_shoutput()\fR has the responsibility of building and 
+transmitting ESH and ISH packets.
+It takes several arguments, including  a pointer to a network interface
+and
+a packet type (ESH or ISH).
+If the packet type is ESH, then
+each NSAP address configured on the specified interface is added to
+the ESH NPDU. ISH NPDUs may only contain a single NSAP address\**.
+.(f
+\** Actually, ISH packets contain Network Entity Titles (NETs). ARGO
+does not make a distinction between NETs and NSAPs.
+.)f
+After the packet is built, it is transmitted on the subnetwork. ESH packets
+are sent to the multicast address \fIall intermediate systems\fR, whereas
+ISH packets are sent to the multicast address \fIall end systems\fR.
+.pp
+Each ISH and ESH NPDU contains 
+a holding timer setting. This setting (specified 
+in seconds) is used by the receiver of the NPDU to set its
+holding timer. When its holding timer expires, the information from
+the NPDU is erased. The holding timer value sent on each ISH and ESH NPDU
+is contained in the variable \fIesis_holding_time\fR. By default, this
+timer setting is 120 seconds. This value may be changed with the 
+\fIclnlutil\fR utility program.
+.sh 2 "Record Configuration Function"
+.pp
+The Record Configuration function receives ESH or ISH NPDUs, extracts the
+configuration information, and updates kernel-resident tables. 
+The two functions \fIesis_eshinput()\fR and \fIesis_ishinput()\fR 
+process incoming ESH and ISH NPDUs, respectively.
+.pp
+The ES-IS entity maintains a table that
+associates a SNPA-addresses with NSAP-addresses.
+This table is called the \fISNPA cache\fR.
+.pp
+Whenever an ESH or ISH NPDU is received, 
+an entry is made in the SNPA cache
+via the \fIsnpac_add()\fR function. 
+This entry is kept in the cache until the holding timer expires. 
+In addition to adding an entry to the SNPA cache, \fIsnpac_add()\fR creates
+a default ISO route toward the sender of the ISH.
+One such route is kept so that the ES-IS entity has at most one
+route to an IS at any time.
+Note that ISHs from different sources will 
+cause the route to the source of the earlier ISH to be 
+overwritten.
+The default route
+will be removed when the ISH holding timer expires.
+.pp
+If, at the time an ESH or ISH NPDU is received, the SNPA cache
+contains no entry for the NSAP address in the NPDU just received, 
+an ESH or ISH (depending on the system type) NPDU is
+transmitted to the sender of the NPDU just received.
+.sh 2 "Resolving NSAP addresses to SNPA addresses: Query Configuration Function"
+.pp
+Whenever a device driver needs to resolve an NSAP address to 
+an SNPA address, it calls \fIiso_snparesolve()\fR. This function first looks
+up the NSAP address in the SNPA cache. If a match is found, the
+corresponding SNPA address is returned. If a match is not found and the
+system is an end system, and there is a known intermediate system, then
+the SNPA address of the intermediate system is returned. It is assumed that
+the intermediate system will forward the packet and transmit a redirect back
+(see "Redirection Generation", below).
+If a match is not found and the system is an end system, but there is no
+known intermediate system, then \fIiso_snparesolve()\fR will return 
+the multicast address \fIall end systems\fR. 
+In all other cases, \fIiso_snparesolve()\fR will return an error.
+This is known as the query configuration function. 
+.sh 3 "Configuration Response Function"
+.pp
+In order for the query configuration function to be effective, the network
+entity that receives a CLNP DT sent to the \fIall end system\fR
+multicast address must transmit an ESH back to the sender of the DT.
+This is called the configuration response function and is accomplished by
+calling \fIsh_output()\fR from within \fIclnp_input()\fR.
+.sh 2 "Redirection Generation"
+.pp
+When an intermediate system forwards a packet onto the same interface 
+upon which 
+the packet arrived, a redirect (RD) NPDU is generated. This NPDU is
+transmitted by calling \fIesis_rdoutput()\fR from within \fIclnp_forward()\fR.
+Note that end systems may forward packets but they do not generate RD PDUs.
+.sh 2 "Redirection Receipt"
+.pp
+RD NPDUs direct an end system to create an SNPA cache entry 
+for an NSAP address, or, if such an entry exists, to change
+the SNPA address associated with the NSAP address.
+The receipt of RD NPDUs is handled by \fIesis_rdinput()\fR. 
+This function
+parses the RD NPDU and adds an entry to the SNPA cache for the corresponding
+destination NSAP address.
+If the redirect is toward an intermediate system,
+meaning that the RD NPDU contains an SNPA address
+of an intermediate system (gateway),
+a route is created for the destination NSAP with the intermediate system as
+the first hop, or gateway, in the route.
+.sh 2 "Multicast Addresses"
+.pp
+As specified by the December 1987 NBS agreements, the address
+\fIall end systems\fR is {0x09, 0x00, 0x2B, 0x00, 0x00, x04} and the address
+\fIall intermediate systems\fR is {0x09, 0x00, x02B, 0x00, 0x00, 0x05}. 
+These multicast addresses are only used on the 802.3 subnetwork (baseband).
+Broadcast addresses are used on the 802.5 subnetwork (token ring). See
+the comment in \fC/sys/netargo/iso_snpac.c\fR for more information on 
+multicast addresses.
+.sh 1 "Connection Oriented Network Service and Subnetwork Service"
+.pp
+The following sections describe the design of the Connection Oriented 
+Network Service (CONS) and the Connection Oriented Subnetwork Service
+(COSNS).
+The CONS and COSNS are provided by two functionally separate but related
+modules, a connection manager and the ISO 8208 (X.25) protocols.
+The connection manager is also known in OSI terminology as a 
+subnetwork dependent convergence function, or SNDCF.
+In ARGO it is used for more than an SNDCF, and it is a sort of 
+"glue" that binds a transport service, a network service, a
+subnetwork service, and a device driver together, so 
+hereinafter it is called "the glue".
+This code performs the some of the functions of ISO 8878,
+which specifies how ISO 8208 (X.25) can be used to provide the OSI 
+connection oriented network service.
+The X.25 protocols are implemented in a coprocessor
+made by Eicon Technology, Inc.
+The device driver \fBecn\fR is the Unix kernel interface to this
+coprocessor.
+The sections that follow describe the glue and the \fBecn\fR device
+driver.
+.sh 2 "The Glue"
+.pp
+The glue provides 
+services to several modules in the kernel:
+.ip "Subnetwork service" 5
+is provided to other network layer protocols, such as CLNP (ISO 8473).
+The ARGO CLNP uses this service.  
+The Internet IP could be made to use this service with 
+minimal effort, because this service interface is made to look
+like a standard Unix BSD link layer service (it has
+a device driver interface).
+.ip "Network service" 5
+is provided to transport layer protocols, such as TP (ISO 8073).
+This service interface looks like a standard Unix BSD 
+network service (a procedure call interface).
+.ip "Transport service" 5
+could be provided to the socket module. 
+While this is not provided with the ARGO software, the glue 
+is designed to permit
+such a service to be provided with little additional programming effort.
+.pp
+Higher layer protocols 
+that use a connection-oriented
+network or subnetwork service need to manage virtual
+circuits in a similar fashion. 
+Rather than put connection management functions into each higher
+layer protocol (HLP) entity
+that uses the CONS or COSNS,
+in ARGO the connection management is in one module, the glue.
+Other alternatives exist, for example in the OSI world,
+one may place in the TP entity the function of connection management for TP,
+and implement a network connection management subprotocol
+of the transport layer (ISO 8073 DAD1, NCMS). 
+In addition, connection management for CLNP may be implemented as part of 
+the CLNP entity.
+A subnetwork dependent convergence protocol (ISO 8878/A) may
+be implemented to support connection management for CLNP.
+The approach taken in ARGO is different from those suggested in ISO
+for two reasons.
+First, ARGO aims to minimize the amount of code written to perform a given
+task.
+Second, ARGO has several coexisting paths through the network layer,
+which the ISO approach does not address.
+For example, in both ISO 8878/A and in NCMS it is assumed that if
+an incoming call arrives from NSAP \(*b 
+while a call to NSAP \(*b is being placed,
+the two calls are resolved to one virtual circuit.
+This is not feasible in the ARGO scenario, since it may not be known
+until after
+the calls are established and higher level packets are exchanged 
+whether the two calls are to be used
+for the same path and for the same higher layer protocols.
+A possible alternative approach is to use an NSAP-address for each path
+through the network layer
+(or protocol suite).
+This was rejected in the ARGO design because it puts the burden
+on the calling application entity or network entity to 
+determine the proper NSAP-address to use to determine the protocol
+suite to be used to reach the destination end system.
+For this reason, none of the approaches suggested in ISO is adopted
+here.
+.pp
+The glue provided in the ARGO
+kernel does not provide the full OSI network service.
+It provides that subset of the network service that is used
+by ARGO TP and by ARGO CLNP.
+The OSI connection-oriented network service elements that are
+are provided are described in Chapter Four,
+in the section titled "Connection Oriented Network Service".
+.pp
+Each module using the glue has its own service
+interface to the glue.
+.\" When X.25 is used as a 
+.\"transport service, the standard protocol switch table is used, and the procedure
+.\"\fIcons_usrreq()\fR is the protosw entry for a
+.\"service in the iso protosw table that provides the 
+.\"SOCK_STREAM abstraction in the AF_ISO address family,
+.\"with protocol ISOPROTO_X25.
+.\"This service is called XTS in the glue code and hereafter
+.\"in this document.
+.\".pp
+When the transport layer uses the glue as a network service,
+the interface is the procedure
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+error = cons_output( isop, m, len, isdgm )
+.T&
+l l l.
+ +struct isopcb +*isop;
+ +struct mbuf +*m;
+ +int+error, len, isdgm;
+.TE
+\fR
+.)b
+.pp
+When the network layer uses the glue as a subnetwork service
+the interface is the device driver-like procedure
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+error = cosns_output( ifp, m, dst )
+.T&
+l l l.
+ +struct ifnet +*ifp;
+ +struct mbuf +*m;
+ +struct sockaddr_iso +*dst;
+ +int+error;
+.TE
+\fR
+.)b
+.pp
+When the glue is used as a connection-oriented service 
+(i.e., by TP 0, and by TP 4 during the transport 
+connection establishment phase, during which
+it is not yet known whether class 0 or class 4 will be used)
+the following procedures are used:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+error = cons_openvc( copcb, dstaddr, so )
+.T&
+l l l.
+ +struct cons_pcb +*copcb;
+ +struct sockaddr_iso +*dstaddr;
+ +struct socket+*so;
+.T&
+l s s s.
+ +++
+error = cons_netcmd( cmd, isop, vc, isdgm )
+.T&
+l l l.
+ +int+cmd;
+ +struct isopcb +*isop;
+ +int+channel, isdgm;
+.TE
+\fR
+.)b
+.pp
+The procedure \fIcons_openvc()\fR places a call.
+The procedure \fIcons_netcmd()\fR accepts, rejects, or clears
+a call. 
+There is no incoming call indication, because
+the glue uses the passive open model for accepting calls.
+The HLP simply sees a new incoming packet, and is given
+a virtual circuit number (channel) along with the incoming packet.
+If the HLP chooses to reject the call
+it may do so, which will cause the virtual circuit (VC) to be cleared.
+.pp
+The glue may reject (clear) an incoming call for its own reasons.
+The following table lists the reasons that the glue may
+clear a call and the ISO 8208 diagnostic code used on the X.25 clear packet
+in each case.
+For a complete list of the permissible diagnostic codes, see
+Figure 14-B of ISO 8208.
+.in -5
+.(b
+.TS
+center expand box tab(+);
+l l.
+Reason+Diagnosic code
+=
+The VC was opened for use with CLNP +Higher level initiated reset
+or TP 4 and has been idle for the   +user resynchronization
+maximum inactivity time.            +(0xfa)
+_
+The HLP closed                      +Higher level initiated disconnection
+this network connection.            +- normal (0xf1)
+_
+The HLP rejected                    +Higher level initiated connection
+this network connection.            +rejection - transient condition (0xf4)
+_
+The X.25 call packet contained      +Higher level initiated connection
+facilities that are not supported   +rejection - incompatible
+by the glue, or did not contain     +information in user data (0xf8)
+necessary information, e.g. calling +     
+or called DTE address.              +
+_
+The X.25 call packet contained      +Higher level initiated connection
+call user data that does not        +rejection - unrecognizable protocol
+indicate any HLP supported by ARGO  +identifier in user data
+HLP supported by ARGO               +(0xf9)
+_
+The given destination               +OSI Network service problem: NSAP
+NSAP-address is not supported       +address unknown (permanent
+						            +condition) (0xeb)
+_
+The X.25 packet or a facility       +Packet not allowed-
+therein was too long                +packet too long. (0x27)
+.TE
+.)b
+.in +5
+.pp
+The glue provides several functions common to all 
+modules (HLPs) that use the glue.
+Regardless of the HLP,
+the DTE addresses and NSAP addresses are associated in the same 
+manner.
+One same network layer protocol identification scheme
+(ISO PDTR 9577) for all HLPs.
+Several different HLPs need to close inactive X.25
+virtual circuits after a timer expires.
+The glue insulates the 
+device driver interface to the X.25 coprocessor 
+from the HLP.
+.pp
+TP class 0 connections
+.\" and the X.25 "transport service" 
+do not share X.25 VCs
+.\" with each other or among transport service-level circuits (sockets), 
+so
+.\" these two modules need to keep X.25
+the glue needs to maintain 
+a 1-1 correspondence between VCs
+and sockets.
+.\" For use by TP 0 and XTS,
+For use by TP 0, 
+one network-level pcb is needed for each socket, and that is a
+\fIcons_pcb\fR, described below.
+.pp
+TP class 4 connections may share VCs, 
+and TP 4 makes no correspondence between sockets and VCs.
+CLNP regards VCs similarly to TP 4.
+A given VC may be used simultaneously for many higher level connections,
+but all higher level connections using a given VC must use the same
+path or protocol suite.
+In other words, a TP4 connection running over CONS may not share a
+VC with a TP4 connection running over CLNS/COSNS.
+.pp
+To manage VCs and to maintain the separation of sharable and non-sharable
+VCs, the glue uses the following protocol control block:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct cons_pcb {
+.T&
+l l l.
+ +struct isopcb+_co_isopcb;
++u_short+co_state; 
++u_char+co_flags; 
++u_short+co_ttl;
++u_short+co_init_ttl;
++int+co_channel;
++struct ifnet+*co_ifp;
++struct protosw+*co_proto; 
++struct dte_addr+co_peer_dte;
++struct ifqueue+co_pending;
+};
+.T&
+l l s.
+#define co_next+_co_isopcb.isop_next
+#define co_prev+_co_isopcb.isop_prev
+#define co_head+_co_isopcb.isop_head
+#define co_laddr+_co_isopcb.isop_laddr
+#define co_faddr+_co_isopcb.isop_faddr
+#define co_lport+_co_isopcb.isop_laddr.siso_tsuffix
+#define co_fport+_co_isopcb.isop_faddr.siso_tsuffix
+#define co_route+_co_isopcb.isop_route
+#define co_socket+_co_isopcb.isop_socket
+}+
+.TE
+\fR
+.)b
+.pp
+The \fIcons_pcb\fR contains
+an \fIisopcb\fR so that TP 0 
+.\" and XTS 
+may use the routines that manipulate \fIisopcb\fR structures for allocating
+and 
+deallocating PCBs, binding addresses to PCBs,
+and finding routes.
+.pp
+A CONS PCB has states CLOSED, LISTENING, CLOSING, 
+CONNECTING, ACKWAIT, and  OPEN.
+This represents the state of the VC to the degree necessary to the glue.
+The glue uses the passive open model for opening VCs.
+The coprocessor device driver always accepts
+incoming calls and passes an indication to the glue when
+a call is accepted by the coprocessor.
+If the user of the glue (the HLP) or the glue itself decides
+that the VC is not desired, the VC is cleared.
+.pp
+The \fIcons_pcb\fR contains a bit mask, \fIco_flags\fR, with values:
+.(b
+\fC
+.TS
+tab(+);
+l l l l.
+#define+CONSF_OCRE+0x40+/* created on OUTPUT */
+#define+CONSF_ICRE+0x20+/* created on INPUT */
+#define+CONSF_DGM+0x04+/* for datagram use only */
+.TE
+\fR
+.)b
+.pp
+The flag 
+CONSF_DGM means that the VC is being used to provide a
+datagram (connectionless, unreliable, unsequenced) 
+service to the higher layer, and that requests for additional VCs
+from the same higher layer entity
+may be served by this VC, effectively 
+multiplexing higher layer connections on this VC.
+When this flag is set in a \fIcons_pcb\fR, there is no associated
+\fIco_socket\fR pointer.
+When CONSF_DGM is not set, there is an associated
+\fIco_socket\fR pointer, and the VC is being used for
+TP 0.
+.pp
+The flag 
+CONSF_ICRE means that the VC was created by 
+and incoming call indication.
+The flag 
+CONSF_OCRE means that the VC was created 
+on behalf of an outgoing call request.
+.pp
+The \fIstruct dte_addr\fR field, \fIco_peer_dte\fR,
+contains the peer's DTE address.
+The glue locates VCs by searching the list of protocol control
+blocks for a PCB with a DTE matching that desired.
+.pp
+The glue is given an NSAP-address by the HLP entity.
+The glue finds the desired DTE address by searching the
+ES-IS SNPA cache for an SNPA-address (DTE address) associated
+with the NSAP-address given by the HLP entity.
+This means that to use the CONS, an entry for each desired
+peer must appear in the SNPA cache.
+ARGO does not provide the ES-IS protocol for use with ISO 8208, so
+"permanent" or static entries must be placed in this cache by hand,
+using the utility program \fIclnlutil\fR.
+.pp
+When an incoming call is accepted, the peer's DTE address is
+placed in the SNPA cache along with
+an NSAP address generated as follows:
+.np
+If the incoming call contained the peer's NSAP-address
+in an Address Extension Facility (AEF, available with 1984 X.25),
+this NSAP-address is used, otherwise
+.np
+the glue creates a "type-37" address (the format defined by AFI 37
+in ISO 8348/AD 2).
+.pp
+TP 4 can have its outgoing packets sent on more than one VC.
+The glue presently contains no mechanism for fanning outgoing
+packets onto several VCs, however,
+it does not prohibit packets arriving for TP 4 on any VC that 
+opened with the protocol identifier for TP.
+.pp
+The glue has the ability to generate AEFs on outgoing calls, but
+this ability is turned off,
+since the public data network on which ARGO runs at Wisconsin
+does not support 1984 X.25, and so it rejects packets containing
+AEFs.
+The use of AEFs can be reinstated by making a kernel with the 
+option \fBX25_1984\fR or by adding the line
+.nf
+.in +5
+\fC
+#define X25_1984
+\fR
+.in -5
+.fi
+at the top of the file
+\fC/sys/netargo/if_cons.c\fR
+and rebuilding the kernel.
diff --git a/share/doc/iso/wisc/net_serv.nr b/share/doc/iso/wisc/net_serv.nr
new file mode 100644
index 0000000..4608f01
--- /dev/null
+++ b/share/doc/iso/wisc/net_serv.nr
@@ -0,0 +1,163 @@
+.NC "Network Service Interface"
+.sh 1 "Connectionless Network Service"
+.pp
+This section describes the interface to the ISO connectionless network service.
+There are really two interfaces to the CLNS: the internal interface
+and the IPC interface.
+The internal interface is based on
+procedure calls. It is used only within the kernel. The IPC interface
+allows a user process to access the CLNS directly. This is used only
+for testing and debugging purposes.
+.sh 2 "Primitives"
+.pp
+The CLNS is, by definition, connectionless. Therefore, there are no 
+primitives associated with connection establishment or connection release.
+There is one primitive associated with data transfer: N-UNITDATA.
+The parameters to a N-UNITDATA request are: source NSAP address,
+destination NSAP address, quality of service, and user data. 
+The parameters of a N-UNITDATA indication are identical to those of the
+request.
+In this implementation, the quality of service parameter is not supported.
+.sh 2 "Internal Interface"
+.pp
+Within the kernel, an N-UNITDATA request is effected by the procedure
+\fIclnp_output()\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+clnp_output(m0, isop, datalen, flags)
+.T&
+l l l.
+ +struct mbuf+*m0;+/* data */
+ +struct isopcb+*isop;+/* ISO protocol control block */
+ +int+datalen;+
+ +int+flags;+/* flags */
+.TE
+\fR
+.)b
+This procedure will construct a DT NPDU, route it, and transmit it on
+the appropriate subnetwork. \fIM0\fR is an mbuf chain containing the 
+user data portion of the N-UNITDATA request. \fIIsopcb\fR is the iso protocol
+control block previously allocated. \fIClnp_output\fR will use the following
+fields: \fIisop_laddr\fR, isop_faddr, isop_route, isop_options,
+isop_optindex, \fI and \fRisop_clnpcache\fR.
+\fIDatalen\fR specifies the number of bytes of user data.
+The \fIflags\fR parameter will be discussed in a subsequent chapter.
+.pp
+A N-UNITDATA indication occurs when a DT NPDU arrives. The indication is
+generated by calling the appropriate upper layer protocol input routine. 
+In the case of TP, the procedure \fItpclnp_input()\fR is called:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+tpclnp_input(m, src, dst, len)
+.T&
+l l l.
+ +struct mbuf+*m;+/* DT NPDU */
+ +struct iso_addr+*src;+/* source of packet */
+ +struct iso_addr+*dst;+/* destination of packet */
+ +int+len;+/* length of clnp header */
+.TE
+\fR
+.)b
+\fIM\fR contains the entire DT NPDU packet. \fILen\fR indicates the size
+of the CLNP header. In other words, the user data of the DT NPDU begins
+\fIlen\fR bytes into \fIm\fR. \fISrc\fR and \fIdst\fR indicate the
+source and destination NSAP addresses of the packet.
+.sh 3 "CLNP/Subnetwork Interface"
+.pp
+The design of the interface between the subnetwork and the CLNP is 
+determined by the design of the Unix network interface drivers. CLNP
+follows the conventional mechanisms for exchanging packets with a network
+interface. See the section on Network Interface Drivers in Chapter Five
+for more information on these conventions.
+.sh 2 "IPC (\*(lqRaw\*(rq) Interface"
+.pp
+The IPC interface to the CLNS allows direct (called \*(lqraw\*(rq) 
+access to CLNP. 
+This interface is intended for testing and debugging only. 
+Its use results in the
+transmission of CLNP datagrams with nonstandard identification fields.
+These raw packets may be rejected by a system not employing the same
+convention. See the section on network implementation for more information
+about the conventions.
+.pp
+In order to gain access to the raw interface
+a \fIsocket\fR, with address family AF_ISO and type SOCK_RAW must be created.
+With this socket in hand,
+the system calls \fIsendto()\fR and \fIrecvfrom()\fR can be used to 
+transmit and receive raw CLNP datagrams. 
+.sh 3 "Sending raw datagrams"
+.pp
+The format of the \fIsendto()\fR system call is:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+cc = sendto(s, msg, len, flags, to, tolen)
+.T&
+l l l.
+int+cc,s;
+char+*msg;
+int+len,flags;
+struct sockaddr+*to;
+int+to;
+.TE
+\fR
+.)b
+\f\fIS\fR is the socket previously created. \fIMsg\fR is a pointer to
+the data for the NPDU. CLNP will prepend a header to this data before
+transmission. \fILen\fR specifies the number of bytes of data. The
+\fIflags\fR parameter is unused and should be zero. \fITo\fR specifies the
+NSAP address to be used as the destination address. The size (in bytes)
+of \fIto\fR is given in \fItolen\fR. CLNP will automatically insert
+the source address based upon the route taken by the packet. The number of
+user data bytes transmitted is returned as \fIcc\fR. See \fIsendto(2)\fR
+for more information on this system call.
+.sh 3 "Receiving raw datagrams"
+.pp
+The format of the \fIrecvfrom()\fR system call is:
+.(b
+\fC
+.TS
+tab(+);
+l s s.
+cc = recvfrom(s, buf, len, flags, from, fromlen)
+.T&
+l l l.
+int+cc,s;
+char+*buf;
+int+len,flags;
+struct sockaddr+*from;
+int+*fromlen;
+.TE
+\fR
+.)b
+When used with a CLNP raw socket \fIs\fR, \fIrecvfrom()\fR will read a 
+NPDU from the CLNS. If no packet is available, the call will block.
+\fIBuf\fR specifies a buffer of \fIlen\fR bytes into which the NPDU will
+be read. The entire packet, including the header, will be read into the
+buffer. The \fIflags\fR parameter is unused, and should be zero. If 
+\fIfrom\fR is non-zero, the source address of the NPDU is filled in.
+\fIFromlen\fR is a value-result parameter, initialized to the size of
+the buffer associated with \fIfrom\fR, and modified on return to
+indicate the actual size of the address stored there. The total number
+of bytes received (header and data) is returned as \fIcc\fR.
+See \fIrecvfrom(2)\fR for more information about this system call.
+.sh 1 "Connection Oriented Network Service"
+.pp
+The ARGO Connection Oriented Network Service (CONS) is not a complete
+implementation of the
+OSI network service.
+It is that subset of the OSI network service that is used
+by ARGO Transport and by ARGO CLNP.
+.\" FIGURE
+.so figs/NS_primitives.nr
+.pp
+.CF
+shows which CONS service elements are provided.
diff --git a/share/doc/iso/wisc/parts.nr b/share/doc/iso/wisc/parts.nr
new file mode 100644
index 0000000..1cd70b1
--- /dev/null
+++ b/share/doc/iso/wisc/parts.nr
@@ -0,0 +1,39 @@
+.\"$Header: parts.nr,v 1.1 88/12/05 18:10:50 nhall Exp $
+.\"$Source: /usr/argo/doc/kernel/RCS/parts.nr,v $
+.\"
+.\"
+.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
+.\" to be sure you've updated everything before distributing this!
+.\"
+.\"This file uses -me and tbl macros.
+.so macros.nr
+.pn 1
+.IC
+.IF
+.(l C
+.sz 16
+Wisconsin ARGO Kernel Programmer's Guide for
+Academic Information Systems 4.3
+
+Current source: argo:/usr/argo/doc/kernel
+.sz 8
+.)l
+.so ../icon/ARGO.nr
+.he 'ARGO Kernel Programmer\'s Guide'''
+.fo '%''\*(td'
+.bp
+.\".so intro.nr
+.\".so def.nr
+.\".so trans_serv.nr
+.\".so net_serv.nr
+.\".so ipc.nr
+.\".so addr.nr
+.so trans_design.nr
+.\".so net_design.nr
+.\".so errors.nr
+.\".so debug.nr
+.\".so appendix_a.nr
+.\".so appendix_b.nr
+.\".fo ''Table of Contents''
+.bp
+.xp
diff --git a/share/doc/iso/wisc/preview b/share/doc/iso/wisc/preview
new file mode 100755
index 0000000..6069d4e
--- /dev/null
+++ b/share/doc/iso/wisc/preview
@@ -0,0 +1,7 @@
+#! /bin/csh -f
+echo $argv
+set dev=fa
+foreach m ($argv)
+	grn -P$dev $m.grn > $m.nr
+	ditroff -P$dev $m.nr
+end
diff --git a/share/doc/iso/wisc/program.nr b/share/doc/iso/wisc/program.nr
new file mode 100644
index 0000000..dfb3305
--- /dev/null
+++ b/share/doc/iso/wisc/program.nr
@@ -0,0 +1,51 @@
+.\"$Header: program.nr,v 1.1 88/12/05 18:10:57 nhall Exp $
+.\"$Source: /usr/argo/doc/kernel/RCS/program.nr,v $
+.\"
+.\"
+.\" FONT CONVENTIONS
+.\"
+.\" \fIprocedure()\fR
+.\" \fIsyscall()\fR
+.\" \fImanpage(3)\fR
+.\" \fIdata_structure_name\fR
+.\" \fC/file/or/directory/name\fR
+.\" \fC
+.\"    section of code
+.\" \fR
+.\"
+.\"
+.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
+.\" to be sure you've updated everything before distributing this!
+.\"
+.\"This file uses -me and tbl macros.
+.so macros.nr
+.pn 1
+.IC
+.IF
+.(l C
+.sz 16
+Wisconsin ARGO 1.0 Kernel Programmer's Guide for
+Academic Operating Systems 4.3
+.sz 8
+.)l
+.so ../icon/ARGO.nr
+.he 'ARGO 1.0 Kernel Programmer\'s Guide'''
+.fo '%''December 9, 1988'
+.bp
+.so intro.nr
+.so def.nr
+.so trans_serv.nr
+.so net_serv.nr
+.so ipc.nr
+.so addr.nr
+.so trans_design.nr
+.so net_design.nr
+.so eicon.nr
+.so errors.nr
+.so debug.nr
+.so appendix_a.nr
+.\" Leave manual pages out!
+.\".so appendix_b.nr
+.fo ''Table of Contents''
+.bp
+.xp
diff --git a/share/doc/iso/wisc/trans_design.nr b/share/doc/iso/wisc/trans_design.nr
new file mode 100644
index 0000000..6aeb54a
--- /dev/null
+++ b/share/doc/iso/wisc/trans_design.nr
@@ -0,0 +1,1466 @@
+.NC "The Design of the ARGO Transport Entity"
+.sh 1 "Protocol Hooks"
+.pp
+The design of the AOS kernel IPC support to some
+extent mandates the
+design of protocols. 
+Each protocol must provide the following 
+protocol hooks, which are procedures called through a
+protocol switch table
+(an array of type \fIprotosw\fR as described in
+Chapter Five.
+.ip "pr_input()" 5
+Called when data are to be passed up from a lower layer.
+.ip "pr_output()" 5
+Called when data are to be passed down from a higher layer.
+.ip "pr_init()" 5
+Called when the system is brought up.
+.ip "pr_fasttimo()" 5
+Called every 200 milliseconds by the clock functional unit.
+.ip "pr_slowtimo()" 5
+Called every 500 milliseconds by the clock functional unit.
+.ip "pr_drain()" 5
+This is meant to be called when buffer space is low.
+Each protocol is expected to provide this routine to free
+non-critical buffer space.
+This is not yet called anywhere.
+.ip "pr_ctlinput()" 5
+Used for exchanging information between
+protocols, such as notifying a transport protocol of changes
+in routing or configuration information.
+.ip "pr_ctloutput()" 5
+Supports the protocol-dependent 
+\fIgetsockopt()\fR
+and 
+\fIsetsockopt()\fR
+options.
+.ip "pr_usrreq()" 5
+Called by the socket code to pass along a \*(lquser request\*(rq -
+in other words a service primitive.
+This call is also used for other protocol functions.
+The functions served by the \fIpr_usrreq()\fR routine are:
+.ip "     PRU_ATTACH" 10
+Creates a protocol control block and attaches it to a given socket.
+Called as a result of a \fIsocket()\fR system call.
+.ip "     PRU_DISCONNECT" 10
+Called as a result of a 
+\fIclose()\fR system call.
+Initiates disconnection.
+.ip "     PRU_DETACH" 10
+Disassociates a protocol control block from a socket and recycles
+the buffer space used for the protocol control block.
+Called after PRU_DISCONNECT.
+.ip "     PRU_SHUTDOWN" 10
+Called as a result of a 
+\fIshutdown()\fR system call.
+If the protocol supports the notion of half-open connections,
+this closes the connection in one direction or both directions,
+depending on the arguments passed to
+\fIshutdown\fR.
+.ip "     PRU_BIND" 10
+Gives an address to a socket.
+Called as a result of a 
+\fIbind()\fR system call, also
+when 
+socket without a bound address is used.
+In the latter case, an unused transport suffix is located and
+bound to the socket.
+.ip "     PRU_LISTEN" 10
+Called as a result of a 
+\fIlisten()\fR system call.
+Marks the socket as willing to queue incoming connection
+requests.
+.ip "     PRU_CONNECT" 10
+Called as a result of a 
+\fIconnect()\fR system call.
+Initiates a connection request.
+.ip "     PRU_ACCEPT" 10
+Called as a result of an 
+\fIaccept()\fR system call.
+Dequeues a pending connection request, or blocks waiting for
+a connection request to arrive.
+In the latter case, it marks the socket as willing to accept
+connections.
+.ip "     PRU_RCVD" 10
+The protocol module is expected to have put incoming data
+into the socket's receive buffer, \fIso_rcv\fR.
+When a receive primitive is used
+(\fIrecv(), recvmsg(), recvfrom(),
+read(), readv(), \fRand 
+\fIrecvv()\fR system calls)
+the socket code module copies data from the
+\fIso_rcv\fR to the user's
+address space.
+The protocol module may arrange to be informed each time the socket code
+does this, in which case the socket code calls \fIpr_usrreq\fR(PRU_RCVD)
+after the data were copied to the user.
+.ip "     PRU_SEND" 10
+This performs the protocol-dependent part of a send primitive
+(\fIsend(), sendmsg(), sendto(), write(), writev(), 
+\fRand \fIsendv()\fR system calls).
+The socket code 
+(procedures \fIsendit() and \fIsosend()\fR)
+moves outgoing data from the user's
+address space into a chain of \fImbufs\fR.
+The socket code takes as much data from the user as it
+determines will fit into the outgoing socket buffer, so_snd. 
+It passes this much data in the form of an mbuf chain to the protocol
+via \fIpr_usrreq\fR(PRU_SEND).
+If there are more data than 
+the so_snd can accommodate,
+the socket code, which is running on behalf of a user process,
+puts the user process to sleep.
+The protocol module is expected to wake up the user process when
+more room appears in so_snd.
+.ip "     PRU_ABORT" 10
+Called when a socket is closed and that socket
+is accepting connections and has
+queued pending
+connection requests or
+partially open connections.
+.ip "     PRU_CONTROL" 10
+Called as a result of an 
+\fIioctl()\fR system call.
+.ip "     PRU_SENSE" 10
+Called as a result of an 
+\fIfstat()\fR system call.
+.ip "     PRU_RCVOOB" 10
+Performs the work of receiving \*(lqout-of-band\*(rq data.
+The socket module has already allocated an mbuf into which
+the protocol module is expected to put the incoming 
+\*(lqout-of-band\*(rq data.
+The socket code will then move the data from this mbuf
+to the user's address space.
+.ip "     PRU_SENDOOB" 10
+Performs the work of sending \*(lqout-of-band\*(rq data.
+The socket module has already moved the data
+from the user's address space into a chain of mbufs,
+which it now passes to the protocol module.
+.ip "     PRU_SOCKADDR" 10
+Supports the system call
+\fIgetsockname()\fR.
+Puts the socket's bound address into an mbuf.
+.ip "     PRU_PEERADDR" 10
+Supports the system call
+\fIgetpeername\fR().
+Puts the peer's address into an mbuf.
+.ip "     PRU_CONNECT2" 10
+This is used in the Unix domain to support pipes.
+It is not generally supported by transport protocols.
+.ip "     PRU_FASTTIMO, PRU_SLOWTIMO" 10
+These are superfluous.
+None of the transport protocols uses them.
+.ip "     PRU_PROTORCV, PRU_PROTOSEND" 10
+None of the transport protocols uses these.
+.ip "     PRU_SENDEOT" 10
+This was added to support TP.
+This indicates that the end of the data sent in this
+send primitive should
+be marked by the protocol as the end of the TSDU.
+.sh 1 "The Interface Between the Transport Entity and Lower Layers"
+.pp
+The transport layer may run over a network layer such as IP
+or the ISO connectionless network layer,
+or it may run over a multi-purpose layer such as the service
+provided by X.25.
+X.25 is viewed as a network layer when
+TP runs over X.25, and as a 
+subnetwork layer 
+when IP is running over X.25.
+The software interface between data link and network layers differs
+considerably from the software interface between transport and network
+layers in AOS.
+For this reason some modification of the transport-to-lower-layer
+interface is necessary to support the suite of protocols included in 
+ARGO.
+.pp
+In AOS it is assumed that the transport layer will run over one
+and only one network layer, and therefore it may call the
+network layer output procedure directly.
+In order to allow TP to run over a set of lower layers,
+all domain-specific functions have been put into a set of routines
+that are called indirectly through a domain-specific switch table.
+The primary reason for this is that the transport and network
+layers share information, mostly information pertaining to addresses.
+The protocol control blocks for different network layers
+differ, so the transport layer cannot just directly
+access the network layer's pcb.
+Similarly, a network layer may not directly access the transport
+pcb because a multitude of transport protocols can run over each
+of the network protocols.
+.pp
+To permit different network-layer protocol control blocks to coexist
+under one transport layer, all transport-dependent control
+information was put into a transport-specific protocol control block.
+A new field, \fIso_tpcb\fR,
+was added to the \fIsocket\fR structure to hold a pointer to
+the transport-layer protocol control block. 
+The existing
+field \fCso_pcb\fR is used for the network layer pcb.
+.pp
+The following structure was added to allow domain-specific
+functions to be called indirectly.
+All these functions operate on a network-layer pcb.
+.pp
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct nl_protosw {
+.T&
+l l l l.
++int+nlp_afamily;+/* address family */
++int+(*nlp_putnetaddr)();+/* puts addrs in pcb */
++int+(*nlp_getnetaddr)();+/* gets addrs from pcb */
++int+(*nlp_putsufx)();+/* transp suffix -> pcb */
++int+(*nlp_getsufx)();+/* gets t-suffix */
++int+(*nlp_recycle_suffix)();+/* zeroes suffix */
++int+(*nlp_mtu)();+/* get maximum
++++transmission unit size */
++int+(*nlp_pcbbind)();+/* bind to pcb */
++int+(*nlp_pcbconn)();+/* connect */
++int+(*nlp_pcbdisc)();+/* disconnect */
++int+(*nlp_pcbdetach)();+/* detach pcb */
++int+(*nlp_pcballoc)();+/* allocate a pcb */
++int+(*nlp_output)();+/* emit packet */
++int+(*nlp_dgoutput)();+/* emit datagram */
++caddr_t+nlp_pcblist;+/* list of pcbs 
++++for management 
++++of connections */
+};
+.TE
+\fR
+.)b
+.lp
+The switch is based on the address family chosen when the
+\fIsocket()\fR system call is made prior to connection establishment.
+This unfortunately ties the address family to the domain,
+but the only alternative is to add an argument to the \fIsocket()\fR
+system call to let the user specify the desired network layer.
+In the case of a connection oriented environment with no multi-homing,
+it would be possible to determine which network layer is to be
+used
+from routing
+information, but to do this requires unrealistic assumptions
+about the environment.
+For these reasons, linking the address family to the network
+layer protocol is seen as the least of the evils.
+The transport suffixes are kept in the network layer's pcb
+as well as in the transport layer because 
+full transport address pairs are used to identify a connection
+in the Internet domain.
+.sh 1 "The Architecture of the Transport Protocol Entity"
+.pp
+A set of protocol hooks is required
+by the AOS IPC architecture.
+These hooks are used by the protocol-independent parts of the kernel
+to gain entry to protocol-specific code.
+The protocol code can be entered in one of the following ways:
+.ip "1) " 5
+at boot time, when autoconfiguration
+initializes each protocol through
+the 
+\fIpr_init()\fR
+hook,
+.ip "2) " 5
+from above, either
+a user program making a system call, through
+the \fIpr_usrreq()\fR or \fIpr_ctloutput()\fR hooks, or
+from a higher layer protocol using the
+\fIpr_output()\fR hook,
+.ip "3) " 5
+from below, a device interrupt servicing an incoming packet
+through the \fIpr_input()\fR  and \fIpr_ctlinput()\fR hooks, and
+.ip "4) " 5
+from a clock interrupt through the \fIpr_slowtimo()\fR
+or the
+\fIpr_fasttimo()\fR hook.
+.\" FIGURE
+.so figs/trans_flow.nr
+.\".so figs/trans_flow.grn
+.pp
+The protocol code can be divided into
+the following modules, which are described in more detail below.
+.CF
+shows the flow of data and control 
+among these modules.
+.in +5
+.ip "Timers and References:" 5
+The code executed on behalf of \fIpr_slowtimo()\fR.
+The fast timeout is not used by TP.
+.ip "Driver:" 5
+This is the finite state machine for TP.
+.ip "Input:     " 5
+This is the module that decodes incoming packets,
+identifies or creates the pcb for which 
+the packet is destined, and creates an "event" to
+pass to the driver.
+.ip "Output:" 5
+This is the module that creates a packet header of a given type
+with fields containing 
+values that are appropriate to the connection
+on which the packet is being sent, appends data if necessary,
+and hands a packet
+to the lower layer, according to the transport-to-lower-layer
+interface.
+.ip "Send:      " 5
+This module packetizes data from the outbound
+socket buffer, \fIso_snd\fR,
+handles retransmissions of packetized data, and
+drops packetized data from the retransmission queue.
+.ip "Receive:" 5
+This module reorders packets if necessary,
+depacketizes data, passes it to the socket code module,
+and determines when acknowledgments should be sent.
+.in -5
+.sh 1 "Timers and References"
+.pp
+TP identifies sockets by \fIreference numbers\fR, or
+\fIreferences\fR,
+which are \*(lqfrozen\*(rq (may not be reassigned)
+until some locally defined time after
+a connection is broken and its protocol control block
+is discarded.
+An array of \fIreference blocks\fR is maintained by TP.
+The reference number of a reference block is its
+offset in the array.
+When a reference block is in use it contains 
+a pointer to the pcb for the socket to which the
+reference applies.
+.pp
+The system clock calls the \fIpr_slowtimo()\fR and 
+\fIpr_fasttimo()\fR hooks for each protocol in the protocol switch table
+every 500 and 200 microseconds, respectively.
+Each protocol handles its own timers its own way.
+The timers in TP take two forms
+- those that typically are cancelled and
+those that usually expire.
+The latter form may have more than one instantiation at any given
+time.
+The former may not.
+The two are implemented slightly
+differently for the sake of performance.
+.pp
+The timers that normally expire 
+are kept in a queue, their values all relative
+to the value of preceding timer.
+Thus all timer values are decremented by a single
+operation on the value of the first timer.
+The timer is represented by the Ecallout structure:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct Ecallout {
+.T&
+l l l l.
++int+c_time;+/* incremental time */
++int+c_func;+/* function to call */
++u_int+c_arg1;+/* argument to routine */
++u_int+c_arg2;+/* argument to routine */
++int+c_arg3;+/* argument to routine */
++struct Ecallout+*c_next;
+};
+.TE
+\fR
+.)b
+.lp
+When an Ecallout structure migrates to the head
+of the E timer list, and its \fIc_time\fR
+field is decremented to zero, 
+the function stored in \fIc_func\fR is
+called, with \fIc_arg1, c_arg2\fR, and \fIc_arg3\fR
+as arguments.
+Setting and cancelling these timers
+are accomplished by a linear search and one
+insertion or deletion from the timer queue.
+This queue is linked to the 
+reference block associated with a communication endpoint.
+This form used for the reference timer
+and for the retransmission timers for data TPDUs.
+.pp
+The second form of timer, the type that
+typically is cancelled, is used for several
+timers - the inactivity timer, the sendack timer,
+and the retransmission
+timer for all types of TPDUs except data TPDUs.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct Ccallout {
+.T&
+l l l l.
++int+c_time;+/* incremental time */
++int+c_active;+/* this timer is active? */
+};
+.TE
+\fR
+.)b
+.lp
+All of these timers are stored
+directly
+in the reference block.
+These timers are decremented in one linear scan of
+the reference blocks.
+Cancelling, setting, and both
+cancelling and resetting one of these timers is accomplished by a
+single assignment to an array element.
+.sh 1 "Driver"
+.pp
+This is the finite state machine for TP.
+A connection is managed by the finite state machine (fsm).
+All events that pertain to a connection cause the
+finite state machine driver to be called.
+The driver takes two arguments - the pcb for the connection
+and an event structure.
+The event structure contains a field that discriminates
+the different types of events, and a union of 
+structures that are specific to the event types.
+The driver evaluates a set of predicates based on the current
+state of the finite state machine (which is kept in the pcb) and the event type.
+The result of the predicate evaluation determines
+a set of actions to take and a state transition.
+The driver takes the actions and if they complete
+without errors, the driver makes the state transition.
+.pp
+The states, event types, predicates, actions, and state transitions are all
+specified as a \fIxebec transition file\fR.
+\fIXebec\fR is a utility that takes a human-readable description
+of a finite state machine
+and produces a set of tables and C source code for the driver.
+The driver procedure is called \fItp_driver()\fR.
+It is located in a file generated by xebec, 
+\fCtp_driver.c\fR.
+For more details about xebec, see the manual page \fIxebec(1)\fR.
+.pp
+The transition file for TP is \fCtp.trans\fR,
+and it is a good place to begin a perusal of the TP
+source code.
+.sh 1 "Input"
+.pp
+This is the module that decodes an incoming packet,
+locates or creates the pcb for which 
+the packet is destined, and creates an event to
+pass to the driver.
+The network layer passes a packet up to the appropriate
+transport layer by indirectly calling a transport input
+routine through the protocol switch table for the network
+domain.
+There is one protocol switch entry for TP for each domain in which
+TP will run (Internet, ISO).
+In the Internet domain, the protocol switch field \fIpr_input()\fR
+takes the value \fItpip_input()\fR.
+This procedure accepts a packet from IP, with the IP header
+still intact.
+It extracts the network addresses from the IP header,
+strips the IP header, and calls the domain-independent
+input procedure for TP,
+\fItp_input()\fR.
+\fITp_input()\fR
+decodes a TPDU.
+The multitude of options, the variable-length
+nature of the options, the semantics of the
+options, and the possible combinations of concatenated
+TPDUs make this a 
+complex procedure.
+It is sensitive to changes, and from 
+the point of view of a software maintenance, it is a
+potential hazard.
+Because it is in the 
+critical path of TP however, some compromise
+was made between maintainability and efficiency.
+Multiple copies of sections of code were avoided as much as
+possible,
+not for the sake of saving space, but rather for the sake
+of maintainability.
+Ironically,
+this detracts somewhat from the readability of the code.
+.pp
+Once a TPDU has been decoded and a pcb has been
+identified for the TPDU,
+the appropriate fields of the TPDU
+are extracted and their values are placed in
+an event structure.
+Finally, \fItp_driver()\fR is called with
+the event structure and the pcb as parameters.
+.sh 1 "Output"
+.pp
+This module creates a TPDU header of a given type
+with field values that are appropriate to the connection
+on which the TPDU is being sent, appends data if necessary,
+and hands a TPDU
+to the lower layer according to the transport-to-lower-layer
+interface.
+Whenever a TPDU is to be sent to the peer or prospective peer,
+the function \fItp_emit()\fR
+is called, passing as arguments the pcb a TPDU type and several miscellaneous
+other type-specific arguments, possibly including some data.
+The data are in the form of an mbuf chain.
+\fITp_emit()\fR prepends to the data an mbuf containing a TP header,
+fills in the fields of the header according to the parameters
+given, performs the checksum if appropriate, and
+calls a domain-specific output routine.
+For the Internet domain, this output routine is
+\fItpip_output()\fR, which takes
+as arguments the mbuf chain representing the TPDU,
+and a network level pcb.
+Some protocol errors cannot be associated with 
+a connection 
+but require that TP issue
+an ER TPDU or a DR TPDU. 
+When these errors occur the routine
+\fItp_error_emit()\fR is called.
+This procedure creates the appropriate type of TPDU
+and passes it to a domain-dependent routine for transmitting datagrams.
+In the Internet domain,
+\fItpip_output_dg()\fR is called.
+This takes as arguments an mbuf chain representing the TPDU,
+a source network address, and a destination network address.
+.sh 1 "Send"
+.\" FIGURE
+.so figs/mbufsnd.nr
+.\".so figs/mbufsnd.grn
+.pp
+This module packetizes data from the outbound
+socket buffer, \fIso_snd\fR,
+handles retransmissions of packetized data, and
+drops packetized data from the retransmission queue.
+The major routine in this module is \fItp_send()\fR, which
+takes a range of sequence numbers as arguments.
+For each sequence number in the range,
+it packetizes the an appropriate amount
+of outbound data, and places the resulting TPDU on 
+a retransmission control queue subject to the
+constraints imposed by the rules of expedited data,
+maximum packet sizes, and end-of-TSDU markers.
+.pp
+The most complicating factor is that of managing
+expedited data.
+A normal datum may not be sent (for its first time) before the
+acknowledgment of any expedited datum
+that was received from the user after the 
+normal datum was received. 
+In order to enforce this rule,
+each TPDU must be marked in some way
+so that it will be known which expedited datum
+must be delivered and acknowledged by the peer before this TPDU may be transmitted
+for the first time.
+Markers are placed in \fIso_snd\fR 
+when an
+outgoing expedited datum arrives from the user. 
+A marker is an mbuf structure with an \fIm_len\fR
+of zero, but with the data area nevertheless containing
+the sequence number of an expedited data TPDU.
+The \fIm_type\fR of a marker is a new type, MT_XPD.
+.pp
+\fITp_send()\fR stops packetizing data when it encounters a marker
+for an unacknowledged expedited datum.
+If it encounters a marker for an expedited TPDU that has already
+been acknowledged, the marker is jettisoned.
+.CF
+illustrates the structure of the sending socket buffer used
+for normal data.
+.pp
+When \fItp_send()\fR moves data from mbufs on \fIso_snd\fR to the retransmission
+control queue, it needs to know
+how many octets of data can be placed in each TPDU.
+The appropriate amount depends on, among other things,
+the maximum transmission unit of the network layer
+on the route the packet will take.
+To determine the maximum transmission unit,
+TP queries the network layer through
+the domain-dependent switch table's field, \fInl_mtu\fR.
+In the Internet domain, this resolves to \fItp_inmtu()\fR.
+The header sizes for the network and transport layers
+also affect the amount of data that can go into a packet,
+and these sizes depend on the connection's characteristics.
+.pp
+Once the maximum amount of data per TPDU is determined,
+\fItp_send()\fR can pull this amount off the \fIso_snd\fR queue to form
+a TPDU,
+assign a TPDU sequence number,
+and place the new TPDU on the 
+retransmission control queue.
+The retransmission control queue is a list of mbuf chains.
+Each mbuf chain represents one TPDU, preceded by an
+\fIrtc structure\fR:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct tp_rtc {
+.T&
+l l l l.
++struct tp_rtc+*tprt_next;+/* next rtc struct in list */
++SeqNum+tprt_seq;+/* seq # of this TPDU */
++int+tprt_eot;+/* end of TSDU? */
++int+tprt_octets;+/* # octets in this TPDU */
++struct mbuf+*tprt_data;+/* ptr to the octets of data */
+.\"/* Performance measurment info: */
+.\"int	tprt_window;	/* in which call to tp_send() was
+.\"			  * this TPDU formed? 
+.\"			  */
+.\"struct timeval	tprt_sess_time;	/* time session received the 
+.\"			* majority of the data for this packet on send;
+.\"			* on recv, this is the time it's given to session 
+.\"			*/
+.\"struct timeval	tprt_net_time;	/* time first copy was given to net layer
+.\"			* on send; on receive it's the time received from
+.\"			* the network 
+.\"			*/
+};
+.TE
+\fR
+.)b
+.lp
+Once TPDUs are on the retransmission control queue,
+they are retransmitted or dropped by the actions
+of timers.
+The procedure \fItp_sbdrop()\fR
+removes the TPDUs from the retransmission queue.
+It takes a sequence number as an argument and drops
+all TPDUs up to and including the TPDU with that sequence number.
+.pp
+When an AK TPDU arrives, the values from
+its credit and sequence number fields
+are passed to \fItp_goodack()\fR, which
+determines whether or not the AK brought any news with it,
+and therefore whether TP can send more data
+or expedited data.
+If this AK acknowledges something heretofore unacknowledged,
+\fItp_goodack()\fR drops the appropriate TPDU(s) from the retransmission
+control list, computes the smoothed average round trip time
+and standard deviation of the round trip time, 
+and updates
+the retransmission timer based on these statistics.
+It sets a flag in the pcb if the TP entity is obliged to
+send the flow control confirmation parameter on its next
+AK TPDU.
+\fITp_goodack()\fR returns true if the AK brought some news with it,
+either with respect to a change in credit or with respect to
+new acknowledgments.
+.pp
+The function \fItp_goodXack()\fR is called when an XAK TPDU
+arrives.
+It takes the XAK sequence number as an argument and
+determines if the XAK acknowledges the last XPD TPDU sent.
+If so, it drops the expedited data from the outgoing
+expedited data buffer.
+By its definition in the TP specification,
+the expedited data stream has a window
+of size 1,
+that is, 
+only one expedited datum (packet) can be buffered
+at a time.
+\fITp_goodXack()\fR returns true if the XAK acknowledged
+the last XPD TPDU sent and the data were dropped,
+and it returns false if the acknowledgment caused no action to be taken.
+.\" NEXT FIGURE
+.so figs/mbufrcv.nr
+.\".so figs/mbufrcv.grn
+.sh 1 "Receive"
+.pp
+This module reorders incoming TPDUs if necessary,
+depacketizes data, passes it to the socket code module,
+and determines when acknowledgments should be sent.
+The function 
+\fItp_stash()\fR
+takes an DT TPDU as an argument, and if the TPDU is not in
+sequence, it saves the TPDU in a \fItp_rtc\fR structure in
+a list, with the TPDUs
+kept in order.
+When the next expected TPDU arrives, the
+list of out-of-order TPDUs is scanned for 
+more TPDUs in sequence, updating
+a field in the pcb, \fItp_rcvnxt\fR which
+always contains the sequence
+number of 
+the next expected TPDU.
+If an acknowledgment is to be generated
+at any time, the value of tp_rcvnxt goes into the
+\fIYR-TU-NR\fR\** field of the acknowledgment TPDU.
+.(f
+\** 
+This is the name used in ISO 8073 for the field
+which indicates the sequence number of the next expected DT TPDU.
+.)f
+.pp
+\fITp_stash()\fR returns true if an acknowledgment needs to be generated
+immediately, false not.
+The acknowledgment strategy is therefore implemented in this routine.
+Acknowledgments may be generated for one or more of several reasons,
+listed below.
+\fITp_stash()\fR increments a counter for each of these reasons
+for which an acknowledgment is generated, and a counter for TPDUs
+that are not acknowledged immediately.
+.ip "ACK_STRAT_EACH" 5
+The acknowledgment strategy in use calls for acknowledging each 
+data packet with an AK TPDU.
+.ip "ACK_STRAT_FULLWIN" 5
+The acknowledgment strategy in use calls for acknowledging 
+upon receiving the DT TPDU that represents the upper window
+edge of the last advertised window.
+.ip "ACK_DUP" 5
+A duplicate data TPDU was received.
+.ip "ACK_REORDER" 5
+A DT TPDU arrived in the window but out of order.
+.ip "ACK_EOT" 5
+A DT TPDU arrived, and it had the end-of-TSDU flag set.
+.pp
+Upon receipt of a DT TPDU that is in order, and upon reordering
+DT TPDUs, 
+\fItp_stash()\fR
+places the TSDUs into the socket's receive
+socket buffer, \fIso->so_rcv\fR in mbuf chains, with
+TSDUs delimited by mbufs of the \fIm_type\fR MT_EOT,
+which is a new type with the ARGO kernel.
+.CF
+illustrates the structure of the receiving socket buffer used
+for normal data.
+.pp
+A separate socket buffer, \fItpcb->tp_Xrcv\fR,
+is used for
+buffering expedited data.
+Only one expedited data packet may reside in this buffer at a time
+because the TP standard limits the size of the window on expedited flow
+to be 1.
+This means the data structures are straightforward;
+there is no need to distinguish between separate TSDUs in this socket buffer.
+.pp
+Credit is determined 
+by dividing the total amount of available
+space in the receive buffer
+by the negotiated maximum TPDU size.
+TP can often offer a larger credit than this if it uses
+an average of the measured actual TPDU sizes.
+This strategy was once an option in the ARGO kernel,
+but it was removed because unless the actual TPDU size
+is constant, it leads to reneging of credit,
+retransmissions, and decreased performance.
+It does not work well when there is any fluctuation in the sizes
+of TPDUs and it carries the penalty of lengthening the critical path
+of the TP entity.
+.sh 1 "Major Data Structures and Types"
+.pp
+In addition to the types commonly used in the kernel,
+such as 
+.(b
+\fC
+.TS
+tab(+);
+l l l l.
+ +typedef+unsigned char+u_char;
+ +typedef+unsigned int+u_int;
+ +typedef+unsigned short+u_short;
+.TE
+\fR
+.)b
+TP uses the following types:
+.(b
+\fC
+.TS
+tab(+);
+l l l l.
+ +typedef+unsigned int+SeqNum
+ +typedef+unsigned short+RefNum;
+ +typedef+int+ProtoHook;
+.TE
+\fR
+.)b
+.pp
+Sequence numbers can be either 7 or 31 bits.
+An unsigned integer is used in all cases, and the proper type
+of arithmetic is performed with bit masks.
+Reference numbers are 16 bits.
+ProtoHook is the type of the procedures that are in switch
+tables, which,
+although they are not functions,
+are declared \fIint\fR rather than \fIvoid\fR
+to be consistent with the rest of the kernel.
+.pp
+The following structures are fundamental
+types used throughout TP,
+in addition to those already described in the 
+section,
+"The Design of the Transport Entity".
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct tp_ref {
+.T&
+l l l l.
++u_char+tpr_state;+/* REF_FROZEN...*/
++struct Ccallout+tpr_callout[N_CTIMERS];+/* C timers */
++struct Ecallout+tpr_calltodo;+/* E timers list */
++struct tp_pcb+*tpr_pcb;+/* --> PCB */
+};
+.TE
+\fR
+.)b
+.lp
+The reference structure is logically a part of the protocol
+control block and it is linked to a pcb, but it may outlive
+a pcb.
+When a connection is dissolved, the pcb may be recycled
+but the reference structure must remain until the reference
+timer goes off.
+The field \fItpr_state\fR takes the values
+REF_FROZEN (a reference timer is ticking),
+REF_OPEN (in use, has timers and an associated pcb),
+REF_OPENING (has a pcb but no timers), and
+REF_FREE (free to reallocate).
+.pp
+The TP protocol control block is too large to fit into
+one mbuf structure so it comprises two structures
+linked together, the 
+\fItp_pcb\fR structure and the.
+\fItp_pcb_aux\fR structure.
+The \fItp_pcb_aux\fR structure contains
+items that are used less frequently than those in
+the former structure, since each access to these
+items requires a second pointer dereference.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct tp_pcb_aux {
+.T&
+l l l s.
+ +struct sockbuf+tpa_Xsnd;+/* for expedited data */
++struct sockbuf+tpa_Xrcv;+/* for expedited data */
++u_char +tpa_vers;+/* protocol version */
++u_char +tpa_peer_acktime;+/* to compute DT TPDU
++++retrans timer value */
++SeqNum+tpa_Xsndnxt;+/* seq # of
++++next XPD to send */
++SeqNum+tpa_Xuna;+/* seq # of 
++++unacked XPD */
++SeqNum+tpa_Xrcvnxt;+/* next XPD seq #
++++expect to recv */
++/* addressing */
++u_short+tpa_domain;+/* domain AF_ISO,...*/
++u_short+tpa_fsuffixlen;+/* foreign suffix */
++u_char+tpa_fsuffix[MAX_TSAP_SEL_LEN];+
++u_short+tpa_lsuffixlen;+/* local suffix */
++u_char+tpa_lsuffix[MAX_TSAP_SEL_LEN];+
+.T&
+l s s s.
+ +/* AK subsequencing */
+.T&
+l l l s.
+ +u_short+tpa_s_subseq;+/* next subseq to send */
++u_short+tpa_r_subseq;+/* highest recv subseq */
+};
+.TE
+\fR
+.)b
+.pp
+The major portion of the protocol control block is in the
+\fItp_pcb\fR structure:
+.(b
+\fC
+.TS
+tab(%);
+l s s s.
+struct tp_pcb {
+.\" *************************************** 
+.T&
+l l l l.
+.\" The next line sets the spacing for the table: 1+3 17+3 17+3 13+3
+ %                 %                 %
+.\"456789 123456789- 123456789 123456-789 123456789 1234567890
+.\"
+ %struct tp_ref%*tp_refp;%    
+.T&
+l l l s.
+%%/* reference structure */%
+.\" *************************************** 
+.T&
+l l l l.
+ %struct tp_pcb_aux%*tp_aux;% 
+.T&
+l l l s.
+ %%/*rest of tpcb (auxiliary struct)*/%
+.\" *************************************** 
+.T&
+l l l l.
+ %caddr_t%tp_npcb;%/* to ll pcb */
+%struct nl_protosw%*tp_nlproto;%
+.T&
+l l l s.
+ % %/* domain-dependent routines */%
+.\" *************************************** 
+.T&
+l l l l.
+ %struct socket%*tp_sock;%/* back ptr */
+.\" *************************************** 
+.T&
+l s s s.
+
+/* local and foreign reference numbers: */
+.T&
+l l l l.
+ %RefNum%tp_lref;% 
+%RefNum%tp_fref;%
+.\" *************************************** 
+.T&
+l s s s.
+.\"456789 123456789 123456789 123456789 123456789 1234567890
+
+/* Stuff for sequence space arithmetic: 
+ * Maintaining 2 sequence spaces is a pain so we set these
+ * values once at connection establishment time. Sequence
+ * number arithmetic is a set of macros which uses these.
+ * Sequence numbers are stored as 32 bits.
+ * tp_seqmask tells which of the 32 bits is used.
+ * tp_seqibt  is the lsb that is not used.  When set,
+ *   it indicates wraparound has occurred.
+ * tp_seqhalf is the value that is half the sequence space.
+ *   (or half plus one).
+ */
+.T&
+l l l l.
+%u_int%tp_seqmask;%/* mask */
+%u_int%tp_seqbit;%/* wraparound */
+%u_int%tp_seqhalf;%/* half space */
+.\" *************************************** 
+.T&
+l s s s.
+
+/* flags:  values are defined in tp_user.h.
+ * Here we keep such info as which options 
+ * are in use: checksum, extended format,
+ * flow control in class 2, etc.
+ * See tp(4p) man page.
+ */
+.\" *************************************** 
+.T&
+l l l l.
+ %u_short%tp_state;%/* fsm */
+%short%tp_retrans;%
+.T&
+l l l s.
+ % % /* # times to retransmit */% 
+.\" *************************************** 
+.T&
+l s s s.
+
+/* credit & sequencing info for SENDING: */
+.T&
+l l l s.
+ %u_short%tp_fcredit;%
+ % %/* remote real window */%
+ %u_short%tp_cong_win;%
+ % %/* remote congestion window */%
+.\" *************************************** 
+%SeqNum%tp_snduna;%
+.T&
+l l l s.
+ % %/* seq # of lowest unacked DT */% 
+.\" *************************************** 
+.T&
+l l l l.
+ %struct tp_rtc    %*tp_snduna_rtc;% 
+.T&
+l l l s.
+ % %/* ptr to mbufs containing lowest% 
+%% * unacked TPDUs sent so far%
+%% */%
+.\" *************************************** 
+.T&
+l l l l.
+ %SeqNum%tp_sndhiwat;% 
+.T&
+l l l s.
+ % %/* highest DT sent yet */% 
+.\" *************************************** 
+.T&
+l l l l.
+ %struct tp_rtc%*tp_sndhiwat_rtc;% 
+.T&
+l l l s.
+ % %/* ptr to mbufs containing the last% 
+%% * DT sent - this is the last item %
+%% * on the list that starts%
+%% * at tp_snduna_rtc%
+%% */%
+.\" *************************************** 
+.T&
+l l l l.
+ %int %tp_Nwindow;%/* for perf. measmt */
+.\" *************************************** 
+.T&
+l s s s.
+
+/* credit & sequencing info for RECEIVING: */
+.\" *************************************** 
+.T&
+l l l s.
+ %SeqNum%tp_sent_lcdt;%
+ %%/* cdt according to last AK sent */%
+ %SeqNum%tp_sent_uwe;% 
+ % %/* upper window edge, according to% 
+%% * the last AK sent %
+%% */*
+ %SeqNum%tp_sent_rcvnxt;% 
+ % %/* rcvnxt, according to% 
+%% * the last AK sent%
+%% */*
+.\" *************************************** 
+.T&
+l l l l.
+ %short%tp_lcredit;%/* local */
+.\" *************************************** 
+.T&
+l l l l.
+ %SeqNum%tp_rcvnxt;% 
+.T&
+l l l s.
+ % %/* next DT seq# we expect to recv */% 
+.\" *************************************** 
+.T&
+l l l l.
+ %struct tp_rtc%*tp_rcvnxt_rtc;% 
+.T&
+l l l s.
+ % %/* ptr to mbufs containing unacked % 
+%% * DTs received out of order, and %
+%% * which we haven't acknowledged%
+%% */%
+.\" *************************************** 
+.TE
+.TS
+tab(%);
+l s s s.
+/* Items kept in the aux structure: */
+
+.\" *************************************** 
+.T&
+l s s l.
+#define  tp_vers%tp_aux->tpa_vers
+#define  tp_peer_acktime%tp_aux->tpa_peer_acktime
+#define  tp_Xsnd%tp_aux->tpa_Xsnd
+#define  tp_Xrcv%tp_aux->tpa_Xrcv
+#define  tp_Xrcvnxt%tp_aux->tpa_Xrcvnxt
+#define  tp_Xsndnxt%tp_aux->tpa_Xsndnxt
+#define  tp_Xuna%tp_aux->tpa_Xuna
+#define  tp_domain%tp_aux->tpa_domain
+#define  tp_fsuffixlen%tp_aux->tpa_fsuffixlen
+#define  tp_fsuffix%tp_aux->tpa_fsuffix
+#define  tp_lsuffixlen%tp_aux->tpa_lsuffixlen
+#define  tp_lsuffix%tp_aux->tpa_lsuffix
+#define  tp_s_subseq%tp_aux->tpa_s_subseq
+#define  tp_r_subseq%tp_aux->tpa_r_subseq
+.\" *************************************** 
+.T&
+l s s s.
+ % % % 
+/* parameters per-connection controllable by user: */
+.\" *************************************** 
+.T&
+l l l l.
+ %struct%tp_conn_param%_tp_param; 
+ % % %
+.\" *************************************** 
+.T&
+l s s l.
+#define  tp_Nretrans%_tp_param.p_Nretrans
+#define  tp_dr_ticks%_tp_param.p_dr_ticks
+#define  tp_cc_ticks%_tp_param.p_cc_ticks
+#define  tp_dt_ticks%_tp_param.p_dt_ticks
+#define  tp_xpd_ticks%_tp_param.p_x_ticks
+#define  tp_cr_ticks%_tp_param.p_cr_ticks
+#define  tp_keepalive_ticks%_tp_param.p_keepalive_ticks
+#define  tp_sendack_ticks%_tp_param.p_sendack_ticks
+#define  tp_refer_ticks%_tp_param.p_ref_ticks
+#define  tp_inact_ticks%_tp_param.p_inact_ticks
+#define  tp_xtd_format%_tp_param.p_xtd_format
+#define  tp_xpd_service%_tp_param.p_xpd_service
+#define  tp_ack_strat%_tp_param.p_ack_strat
+#define  tp_rx_strat%_tp_param.p_rx_strat
+#define  tp_use_checksum%_tp_param.p_use_checksum
+#define  tp_tpdusize%_tp_param.p_tpdusize
+#define  tp_class%_tp_param.p_class
+#define  tp_winsize%_tp_param.p_winsize
+#define  tp_netservice%_tp_param.p_netservice
+#define  tp_no_disc_indications%_tp_param.p_no_disc_indications
+#define  tp_dont_change_params%_tp_param.p_dont_change_params
+.\" *************************************** 
+.TE
+.\" *************************************** 
+.\" *************************************** 
+.\" *************************************** 
+.TS
+tab(%);
+l l l l.
+.\" The next line sets the spacing for the table: 1+3 17+3 17+3 13+3
+.\"456789 123456789- 123456789 123456-789 123456789 1234567890
+.\"
+.T&
+l l l s.
+ %%/* log2(the negotiated max size) */% 
+.T&
+l l l l.
+ %int%tp_l_tpdusize;%/* # bytes */
+.\" *************************************** 
+ %struct timeval%tp_rtt;% 
+.T&
+l l l s.
+ % %/* smoothed avg round-trip time */% 
+ %struct timeval%tp_rtv;% 
+ % %/* std deviation of round-trip time */% 
+%struct timeval%tp_rttemit[ TP_RTT_NUM + 1 ];%
+%%/* times that the last TP_RTT_NUM %
+%% * DT_TPDUs were transmitted %
+%% */%
+.\" *************************************** 
+ %unsigned % % 
+%  tp_sendfcc:1,%/* shall next ack %
+% %include flow control conf. param? */%
+.\" *************************************** 
+.T&
+l l l s.
+ %  tp_trace:1,%/* is this pcb being traced?% 
+%% * (not used yet) %
+%% */%
+.\" *************************************** 
+%  tp_perf_on:1,%/* statistics being kept? */% 
+.\" *************************************** 
+%  tp_reneged:1,%/* have we reneged on credit%
+%% * since the last AK TPDU was sent? %
+%% */%
+%  tp_decbit:4,%/* congestion experienced? */%
+%  tp_flags:8,%/* see #defines below */%
+.\" *************************************** 
+%  tp_unused:16;%%
+.T&
+l s s l.
+#define  TPF_XPD_PRESENT%TPFLAG_XPD_PRESENT
+#define  TPF_NLQOS_PDN%TPFLAG_NLQOS_PDN
+#define  TPF_PEER_ON_SAMENET%TPFLAG_PEER_ON_SAMENET
+%%%
+.\" *************************************** 
+.T&
+l l l l.
+ %struct tp_pmeas%*tp_p_meas;% 
+.T&
+l l l s.
+ % %/* ptr to mbuf to hold the perf.% 
+%% * statistics structure %
+%% */%
+.\" *************************************** 
+};
+.TE
+\fR
+.\"
+.\" end of tpcb structure (thank you)
+.\"
+.)b
+.fi
+.sh 1 "Sequence Number Arithmetic"
+.pp
+Sequence numbers in TP can be either 7 bits 
+(\*(lqnormal format\*(rq)
+or 31 bits
+(\*(lqextended format\*(rq).
+Sequence numbers are unsigned integers,
+regardless of their format.
+Three fields are kept in the pcb to manage the sequence
+number arithmetic:
+.(b
+\fC
+.TS
+tab(+);
+l l l l.
+ +u_int+tp_seqmask;+/* mask for seq space */
+ +u_int+tp_seqbit;+/* bit for seq # wraparound */
+ +u_int+tp_seqhalf;+/* half the seq space */
+.TE
+\fR
+.)b
+.lp
+\fITp_seqmask\fR 
+is a bit mask indicating which bits are legitimate 
+for a sequence number of either format.
+It takes the value 0x7f if 7-bit sequence numbers are in use,
+and 0x7fffffff if 31-bit sequence numbers are in use.
+\fITp_seqbit\fR 
+is the bit that becomes set when a sequence number wraps around
+while being incremented.
+Its value is 0x80 for normal format, 0x80000000 for extended format.
+\fITp_seqhalf\fR 
+takes the value which is in the middle of the sequence space,
+0x40 for normal format,
+and
+0x40000000 for extended format.
+.(b
+.nf
+The macro 
+.fi
+\fC
+.TS
+tab(+);
+l l l l.
+     SEQ(tpcb, x)
+.TE
+\fR
+.)b
+.lp
+extracts a sequence number from the location
+in which it is stored.
+.pp
+The macros
+.(b
+\fC
+.TS
+tab(+);
+l l s s l.
+ +SEQ_GT(tpcb, seq, t)+is seq > t?
+ +SEQ_GEQ(tpcb, seq, t)+is seq >= t?
+ +SEQ_LT(tpcb, seq, t)+is seq < t?
+ +SEQ_LEQ(tpcb, seq, t)+is seq <= t?
+ +SEQ_INC(tpcb, seq)+seq\+\+
+ +SEQ_DEC(tpcb, seq)+seq--
+ +SEQ_SUB(tpcb, seq, amt)+seq -= amt
+ +SEQ_ADD(tpcb, seq, amt)+seq \+= amt
+.TE
+\fR
+.)b
+.lp
+perform the indicated comparisons and arithmetic
+on their arguments.
+.pp
+An example of how these macros
+are used is as follows.
+To determine if a sequence
+number \fIseq\fR is in a receive window
+bounded by
+\fIlwe\fR and \fIuwe\fR,
+we define the
+macro
+.(b
+\fC
+.TS
+tab(+);
+l l.
+#define+IN_RWINDOW(tpcb, seq, lwe, uwe)\\
++( SEQ_GEQ(tpcb, seq, lwe) && SEQ_LT(tpcb, seq, uwe) )
+.TE
+\fR
+.)b
+.sh 1 "TP Implementation Options"
+.pp
+The transport protocol specification leaves several
+things to the discretion of the implementor,
+some of which may affect the performance
+of individual connections and
+aggregate performance.
+Wherever different strategies are likely to favor
+the performance of
+individual connections to the detriment of aggregate performance
+or vice versa, the
+various strategies are under the control of options via the
+\fIgetsockopt()\fR and
+\fIsetsockopt()\fR system calls (see the manual pages
+\fIgetsockopt(2)\fR,
+\fIsetsockopt(2)\fR  
+and
+\fItp(4p)\fR  
+for details).
+In some cases the preferred strategies differ for the different
+subnetworks, so the strategies chosen will be determined
+by the subnetwork in use.
+.sh 2 "TPDU size"
+.pp
+The limitation of the maximum TPDU size to a power of two is
+unfortunate in the LAN environment.
+For example, if the maximum NSDU size is around 1500, as in the case of an
+Ethernet,
+using a maximum TPDU size of 1024 reduces
+the possible throughput by approximately 30%.
+TP negotiates a maximum TPDU size of 2048 and
+generates TPDUs of size around 1500.
+Obviously this works well only when the peer is known to be 
+using the same scheme (so that the peer
+doesn't send TPDUs of size 2048 and cause its
+network layer to fragment the TPDUs).
+This is likely to be the case in a LAN where
+all protocol entities are under the same administrative
+control.
+The maximum TPDU size negotiated is under the control of the user,
+so
+it is possible to prevent this scheme from being used
+by default
+when the peer is not on the same LAN, by
+setting the \fItp.tpdusize\fR parameter in the ARGO directory service
+file to
+something less than the network's maximum transmission
+unit.
+.\"***********************************************************
+.sh 2 "Congestion Window Strategy"
+.pp
+The congestion window strategy from the
+DoD Internet 
+was adapted for use with TP.
+The strategy is intended to minimize the 
+adverse effect
+of transport's retransmission on an
+already congested network.
+.pp
+A TP entity keeps two notions of the peer's window:
+the real window, which is that advertised by the peer
+in AK TPDUs, and the congestion window, which is a locally
+controlled window.
+TP uses the smaller of the two windows when transmitting.
+The congestion window starts small, which keeps a
+new connection from overloading the network with a sudden
+burst of packets
+immediately after connection establishement.
+This is called \fIslow start\fR. 
+For each successful acknowledgment received, the congestion
+window grows by one, until eventually the real window
+is the one in use.
+If a retransmission timer expires, the congestion window
+is reset to size one.
+.pp
+The congestion window strategy is used for class 4 unless
+the transport user requests that it not be used.
+The slow start strategy is used for traffic over a PDN
+unless
+the transport user requests that it not be used.
+Slow start is not used for traffic over a LAN unless
+its use is requested by the transport user.
+.\"***********************************************************
+.sh 2 "Retransmission strategies"
+.pp
+A retransmission timer is invoked for each set of DT TPDUs
+sent in one send operation (call to \fItp_send()\fR).
+This set of packets is called the \fIsend window\fR for the purpose
+of this discusssion.
+.pp
+The number of TPDUs 
+in a send window
+depends on the remote credit and the amount of data
+in the local send buffers.
+When a retransmission timer goes off, the lower
+window edge 
+is reevaluated but the upper window edge is not reevaluated.
+.pp
+There are several retransmission strategies implemented in
+ARGO TP.
+The choice of strategies is the user's, and is made with the 
+\fIsetsockopt()\fR system call.
+The strategies are summarized here:
+.ip "Retransmit LWE TPDU only:" 5
+Only the TPDU representing the new lower window edge 
+is retransmitted.
+This is the default retransmission strategy.
+.ip "Retransmit whole send window:" 5
+Retransmission begins with the new lower window edge
+and continues up to the old upper window edge.
+.pp
+The value of the data retransmission timer
+adapts to the average round trip time and the standard deviation of
+the round trip time.
+A round trip time is the time that passes between
+the moment of a packet's first transmission and 
+the moment it is first acknowledged.
+The average round trip time
+is kept by the sending side of TP, using
+a formula for 
+smoothing the average:
+.(b
+\fC
+.TS
+tab(+);
+l l l l.
+#define+TP_RTT_ALPHA+3
+#define+TP_RTV_ALPHA+2
++++
+#define+SMOOTH(alpha, old, new) \\
++(((new-old) >> alpha ) \+ (old) )
+.TE
+\fR
+.)b
+.lp
+The times included in the average are chosen as follows.
+The time of 
+each packet's initial transmission is kept (for the last
+\fIN\fR packets, where \fIN\fR is a defined constant).
+When an AK TPDU arrives, ARGO TP subtracts the initial transmission
+time for the lowest unacknowledged sequence number that was
+acknowledged by this AK TPDU from the current time,
+and apply the resulting time to the average.
+Hence, not all packets are included in this average,
+which is as it should be since
+the purpose of this measurement is 
+to find a good value for the retransmission timer.
+.pp
+Each time part of a window is retransmitted,
+the retransmission timer for that window is increased.
+This does not affect the retransmission timers for other windows.
+.\"***********************************************************
+.sh 2 "Acknowledgment strategies"
+.pp
+The transport protocol specification
+requires acknowledgments to be sent immediately
+upon receipt
+of  CC TPDUs (in class 4), XPD TPDUs, and DT TPDUs containing an
+EOT marker, and at other times as required for flow control,
+otherwise acknowledgments may be delayed.
+In addition to the times when an acknowledgment is required,
+ARGO TP transmits an AK TPDU whenever the user receives some data,
+thereby increasing the size of the window.
+For those times when
+immediate acknowledgment is optional,
+ARGO TP offers two acknowledgment strategies:
+.ip "     Acknowledge each TPDU" 10
+Upon receipt of a DT TPDU and AK TPDU is sent.
+.ip "     Acknowledge full window" 10
+Acknowledgment is issued
+upon receipt of enough data to
+consume the last advertised credit.
+.pp
+The latter strategy
+requires a timer to trigger an acknowledgment
+in case the peer doesn't send the entire window 
+quickly.
+This timer is called the
+\fIsendack timer\fR.
+The upper bound on the value of this timer 
+is called the \fIlocal acknowledgment time\fR.
+The local acknowledgment time may be "advertised" to the 
+peer during connection establishment, and the
+peer may choose to use this value to
+adjust its retransmission timers.
+The ARGO TP entity advertises its local acknowledgment time
+on a CR TPDU, but it is not 
+constrained by 
+the remote acknowledge time, should the peer 
+advertise it.
+Instead,
+ARGO TP adapts its sendack timer
+to the behavior of the connection.
+.pp
+Under the assumption that the round trip time is
+often 
+symmetric,
+and lacking 
+a method to measure
+the round trip time in the other direction,
+ARGO TP uses the measured average round trip time
+to adjust the the sendack timer.
+.pp
+The choice of strategies is made with the
+\fIsetsockopt()\fR system call.
+The default strategy is
+to
+delay acknowledgments until the most recently advertised window is filled.
diff --git a/share/doc/iso/wisc/trans_serv.nr b/share/doc/iso/wisc/trans_serv.nr
new file mode 100644
index 0000000..462186e
--- /dev/null
+++ b/share/doc/iso/wisc/trans_serv.nr
@@ -0,0 +1,692 @@
+.NC "Transport Service Interface"
+.sh 1 "General"
+.pp
+It is assumed that the reader is acquainted with the
+set of system calls and library routines that
+compose the
+Berkeley
+Unix interprocess communication service (IPC).
+To every extent possible 
+the ARGO transport service is provided by the same IPC mechanisms
+that support
+the transport-level services 
+included in the
+AOS distribution.
+In some instances, the interface
+provided by AOS does not support
+the services required by ISO 8073,
+so system calls were added to support these services.
+It is felt that this is superior to modifying
+existing system calls, in order to avoid the
+recoding of existing Unix utilities. 
+.pp
+What follows is a description of the system calls
+that are used to provide the transport service.
+According to Unix custom,
+the return value of a system call is 0
+if the  call succeeds and -1 if
+the call fails for any reason.
+In the latter case,
+the global variable
+\fIerrno\fR contains more information
+about the error that caused the failure.
+In the descriptions of all the system calls for which
+this custom is followed,
+the return value is named
+\fIstatus\fR.
+.sh 1 "Connection establishment"
+.pp
+Establishing a TP connection is similar to
+establishing a connection using any other
+transport protocol supported by Unix.
+The same system calls are used, and the passive open
+is required.  
+Some of the parameters to the system calls differ. 
+.pp
+The following call creates a communication endpoint called a
+\fIsocket\fR.
+It returns
+a positive integer called a
+\fIsocket descriptor\fR, 
+which
+will be a parameter in all communication primitives.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+s = socket( af, type, protocol )
+.T&
+l l l.
+ +int+s,af,type,protocol;
+.TE
+\fR
+.)b
+.pp
+The \fIaf\fR parameter describes the format of addresses
+used in this communication.
+Existing formats include AF_INET (DoD Internet addresses), 
+AF_PUP (Xerox PUP-I Internet addresses), and AF_UNIX
+(addresses are Unix file names, for intra-machine IPC only).
+TP runs in either the Internet domain or the ISO domain (AF_ISO).
+When using the Internet domain, the network layer is the DoD Internet IP 
+with Internet-style addresses. The ISO domain uses the ISO
+network service and ISO-style addresses\**.
+.(f
+\**ISO/DP 8348/DAD2 Addendum to the Network
+Service Definition Covering Network Layer Addressing.
+.)f
+Regardless of the address family used, an address takes the
+general form,
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr {
+.T&
+l l l l.
+ +short+sa_family;+/* address family */
+ +char+sa_data[14];+/* space for an address */
+}+
+.TE
+\fR
+.)b
+.sp 1
+When viewed as an Internet address, it takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr_in {
+.T&
+l l l l.
+ +short+sin_family;+/* address family */
+ +u_short+sin_port;+/* internet port */
+ +struct in_addr+sin_addr;+/* network addr A.B.C.D */
+ +char+sin_zero[8];+/* unused */
+}
+.TE
+\fR
+.)b
+.sp 1
+When viewed as an ISO address, it takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+struct sockaddr_iso {
+.T&
+l l l l.
+ +short+siso_family;+/* address family */
+ +u_short+siso_tsuffix;+/* transport suffix */
+ +struct iso_addr+siso_addr;+/* ISO NSAP addr */
+ +char+siso_zero[2];+/* unused */
+}
+.TE
+\fR
+.)b
+The address described by a \fIsockaddr_iso\fR structure
+is a TSAP-address (transport service access point address).
+It is made of an NSAP-address (network service access point address)
+and a TSAP selector (also called a transport suffix or
+transport selector, hereafter called a TSEL).
+The structure \fIsockaddr_iso\fR contains a 2-byte TSEL.
+This is for compatibility with Internet addressing.
+ARGO supports
+TSELs of length 1-64 bytes.
+TSELs of any length other than 2
+are called \*(lqextended TSELs\*(rq.
+They are described in detail in the section \fB\*(lqExtended TSELs\*(rq\fR.
+If extended TSELs are not requested, 2-byte TSELs are used by default.
+.pp
+Refer to Chapter Five for more information about ISO NSAP-addresses.
+.pp
+The \fItype\fR parameter in the \fIsocket()\fR call
+distinguishes 
+datagram protocols, stream protocols, sequenced
+packet protocols, reliable datagram protocols, and
+"raw" protocols (in other words, the absence of a transport protocol).
+Unix provides manifest named constants for each of these types.
+TP supports the sequenced packet protocol abstraction, to which
+the manifest constant SOCK_SEQPACKET applies.
+.pp
+The \fIprotocol\fR
+parameter is an integer that identifies the protocol to be used.
+Unix provides a database of protocol names  and their associated
+protocol numbers.
+Unix also provides user-level tools
+for searching the database.
+The tools take the form of library routines.
+A protocol number for TP has been chosen
+by the Internet NIC to allow TP to run in the Internet domain, and this
+has been added to the Unix network protocol database.
+The standard Internet database tools that serve TCP users
+can
+also serve user of TP
+in the Internet domain, if the TP protocol number is added to the
+proper Internet database file, 
+\fC/etc/protocols\fR.
+This change must be made for TP to run in either the Internet or
+in the ISO domain.
+The ARGO package contains a set of tools and a database
+for use with TP in the ISO domain.
+This set of tools is described in the manual pages
+\fIisodir(5)\fR and
+\fIisodir(3)\fR.
+.pp
+When a socket is created, it is not given an address.
+Since a socket cannot be reached by a remote entity unless it has an address, 
+the user must request that a socket be given an address by
+using the \fIbind()\fR system call:
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = bind( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The address is expected to be in the format specified by the
+\fIaf\fR parameter to the \fIsocket()\fR
+call that yielded the socket descriptor \fIs\fR.
+If the user 
+passes an address parameter with a zero-valued transport suffix,
+the transport layer 
+assigns an unused 2-byte transport selector.
+This is a 4.3 Unix convention; it is not part of any ISO standard.
+.pp
+The \fIconnect()\fR system call effects an active open.
+It is used to establish a connection with an entity that is
+passively waiting for connection requests, and whose
+transport address is known.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = connect( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The first parameter is a socket descriptor.
+The \fIaddr\fR parameter is a transport address in the format
+specified by the \fIaf\fR parameter to the \fIsocket()\fR
+call that yielded the socket descriptor \fIs\fR.
+.pp
+A passive open is accomplished with two system calls,
+\fIlisten()\fR followed by \fIaccept()\fR.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = listen( s, queuelen )
+.T&
+l l l.
+ +int+s;
+ +int+queuelen;
+.TE
+\fR
+.)b
+.pp
+The \fIqueuelen\fR argument specifies the maximum
+number of pending connection
+requests that will be queued for acceptance by this user.
+Connections are then accepted by the
+system call \fIaccept()\fR.  
+There is no way to refuse connections.
+The functional equivalent of connection
+refusal is accomplished by accepting a connection and immediately
+disconnecting.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+new_s = accept( s, addr, addrlen )
+.T&
+l l l.
+ +int+new_s, s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+The \fIaccept()\fR call completes the connection
+establishment. If a connection request from a prospective peer
+is pending on the socket described by \fIs\fR, it is removed and
+a new socket is created for use with this connection.
+A socket descriptor for the new socket is returned by the
+system call.
+If no connection requests are pending, this call blocks.
+If the \fIaccept()\fR call fails, -1 is returned.
+The transport address of the entity requesting the connection
+is returned in the \fIaddr\fR parameter, and the length
+of the address is returned in the \fIaddrlen\fR parameter.
+The address associated with the new socket is inherited
+from the socket on which the \fIlisten()\fR and \fIaccept()\fR were performed.
+.pp
+It is possible for the \fIaccept()\fR call to be interrupted
+by an asynchronous event such as the arrival of expedited
+data.
+When system calls are interrupted, Unix returns the value -1
+to the caller and puts the constant
+EINTR in the global variable \fIerrno\fR.
+This can create problems with the system call \fIaccept()\fR.
+In the case of incoming expedited data, the interruption does
+not indicate a problem, but the data may have arrived before
+the caller has received the new socket descriptor, which is the
+socket descriptor on which the expedited data are to be received.
+In order to prevent this problem from occurring, the caller must
+prevent the issuance of asynchronous indications until the
+\fIaccept()\fR
+call has returned.
+Asynchronous indications are discussed below, in 
+the section titled
+"Indications from the transport layer to the transport user".
+.pp
+It is possible to discover the 
+address bound to a 
+socket with the 
+\fIgetsockname()\fR system call.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getsockname( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.pp
+If the socket has a peer, that is, it is connected,
+the system call
+\fIgetpeername()\fR
+is used to discover the peer's address.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getpeername( s, addr, addrlen )
+.T&
+l l l.
+ +int+s;
+ +struct sockaddr+*addr;
+ +int+addrlen;
+.TE
+\fR
+.)b
+.lp
+The names returned by 
+\fIgetsockname()\fR and \fIgetpeername()\fR 
+do not contain extended TSELs.
+Extended TSELs can be retrieved with 
+the \fIgetsockopt()\fR and 
+\fIsetsockopt()\fR system calls, described below.
+.pp
+Unix supports several protocol-independent options
+and protocol-specific options
+associated with sockets.
+These options can be inspected and changed by using
+the \fIgetsockopt()\fR and 
+\fIsetsockopt()\fR system calls.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = getsockopt( s, level, option, value, valuelen )
+.T&
+l l l.
+ +int+s, level, option;
+ +char+*value;
+ +int+*valuelen;
+.TE
+\fR
+.)b
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = setsockopt( s, level, option, value, valuelen )
+.T&
+l l l.
+ +int+s, level, option;
+ +char+*value;
+ +int+valuelen;
+.TE
+\fR
+.)b
+.pp
+The \fIlevel\fR argument may indicate
+either
+that this option applies to sockets or that it applies to
+a specific protocol.
+The constants SOL_SOCKET, SOL_TRANSPORT, and SOL_NETWORK
+are possible values for the \fIlevel\fR argument.
+The \fIoption\fR argument is an integer that identifies
+the option chosen.
+.\" LIST THE OPTIONS HERE
+The options available to TP users provide the 
+user with the ability to control various TP protocol options
+including but not limited to
+TP class, TPDU size negotiated, TPDU format used,
+acknowledgment and retransmission strategies.
+For a detail list of the options, see the manual page \fItp(4p)\fR.
+.sh 1 "Extended TSELs"
+.pp
+ARGO supports TSELs
+of length 1 byte - 64 bytes for sockets bound to addresses in the
+AF_ISO address family.
+The ARGO user program uses the
+\fIgetsockopt()\fR
+and 
+\fIsetsockopt()\fR
+system calls to 
+discover and assign extended TSELs.
+.pp
+To create a socket with an extended TSEL,
+the process 
+.ip \(bu 5
+opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
+.ip \(bu 5
+binds an NSAP-address to the socket with \fIbind()\fR.
+The address bound may contain a 2-byte selector (\fIiso_tsuffix\fR).
+.ip \(bu 5
+uses \fIsetsockopt()\fR with the command TPOPT_MY_TSEL,
+to assign a TSEL to the socket.
+.ip \(bu 5
+calls \fIlisten(), connect()\fR, or any other appopriate system calls
+to use the socket as desired.
+.lp
+To connect to a transport entity that is bound to a TSAP-address with
+an extended TSEL, the
+process 
+.ip \(bu 5
+opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
+.ip \(bu 5
+uses \fIsetsockopt()\fR, with the command TPOPT_PEER_TSEL,
+to assign a PEER TSEL to the socket.
+This TSEL is used by the transport entity 
+for all subsequent connect requests made on this socket, 
+unless the peer TSEL is changed by another call to
+\fIsetsockopt()\fR employing the command TPOPT_PEER_TSEL.
+.lp
+To discover the TSEL of the peer of a connected socket,
+the process 
+.ip \(bu 5
+uses \fIgetsockopt()\fR with the command TPOPT_PEER_TSEL.
+.lp
+To discover the TSEL of socket's own address,
+the process 
+.ip \(bu 5
+uses \fIgetsockopt()\fR with the command TPOPT_MY_TSEL.
+.sh 1 "Data transfer"
+.pp
+The system calls provided by AOS for data transfer have
+semantics that are unsuitable for TP,
+and in fact they are seriously deficient for the correct
+operation of any user program that uses out-of-band or expedited
+data in any way except to cause the program to abort.
+The problem lies in the manner in which the kernel
+handles interrupted system calls.
+The send and receive primitives
+may be interrupted by signals.
+A signal is the mechanism used to indicate
+the presence of expedited data or out-of-band data.
+If the send or receive primitive is interrupted before completion,
+the user needs to know how many octets of data were sent or received.
+The existing system call interface does not provide this
+information, nor does it permit TP to provide
+this information.
+All forms of the existing interface 
+(\fIsend()\fR, 
+\fIrecv()\fR, 
+\fIsendmsg()\fR, 
+\fIrecvmsg()\fR, 
+\fIsendto()\fR, 
+\fIrecvfrom()\fR, 
+\fIwrite()\fR, 
+\fIread\fR, 
+\fIwritev()\fR, 
+and \fIreadv()\fR system calls)
+return an octet count
+when the system call completes, and return an error
+indication (-1, \fIerrno\fR == EINTR) if the system call is interrupted. 
+To change the semantics
+of these calls would create havoc with existing user-level software.
+Instead two new system calls are provided to support data transfer.
+(The existing interface may be used if the user does not need the additional
+service provided by the new system calls.)
+.pp
+The two new system calls are patterned after 
+\fIreadv()\fR and \fIwritev()\fR,
+the scatter-gather or "vectored"
+versions of \fIread()\fR and \fIwrite()\fR.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+cc = sendv( s, iov, iovlen, flags )
+.T&
+l l l.
+ +int+s:
+ +io_vector+iov;
+ +int+iovlen;
+ +unsigned int+*flags;
+.TE
+\fR
+.)b
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+cc = recvv( s, iov, iovlen, flags )
+.T&
+l l l.
+ +int+s:
+ +io_vector+iov;
+ +int+iovlen;
+ +unsigned int+*flags;
+.TE
+\fR
+.)b
+.pp
+The \fIiov\fR argument is an \fIio_vector\fR,
+an array of pointers and lengths that
+describe the areas from (or to) which the data will be gathered (or scattered).
+The \fIiovlen\fR argument is an integer that tells how many parts are in
+the io_vector.
+The \fIflags\fR parameter serves several purposes.
+The TP specification requires that TSDUs be unlimited in size.
+System calls cannot pass unlimited amounts of data between the user
+and the kernel, so
+there cannot be a one-to-one correspondence between TSDUs and
+system calls. 
+The \fIflags\fR
+parameter is used to mark the end-of-TSDU on both sending and
+receiving.
+This way one TSDU can span several system calls.
+When sending, 
+the user sets
+this flag
+to indicate that this  request completes a TSDU.
+When receiving, 
+TP sets this flag when
+the end of a TSDU is reached.
+In the latter case, the end of the data received by the transport user
+with a given system call
+coincides with the end of the TSDU
+if 
+the TP has set the end-of-TSDU bit
+in the \fIflags\fR parameter of the \fIrecv()\fR system call.
+It is possible for the peer to send an empty TPDU with the end-of-TSDU
+flag set, in which case the transport user
+may receive zero octets with the end-of-TSDU flag set.
+See the manual pages 
+\fIrecvv(2)\fR 
+and
+\fIsendv(2)\fR 
+for details.
+.pp
+The \fIflags\fR parameter also serves to distinguish data transfer primitives
+from expedited data transfer primitives.
+The flag bit MSG_OOB is provided for "out of band data" in the
+DoD Internet protocols.  It is also used to provide the expedited data service
+of the ISO protocols.
+The transport layer will deliver one expedited datum (there will be a
+one-to-one correspondence between expedited TSDUs and XPD TPDUs)
+at a time.  
+The user must receive the datum before the transport
+layer will accept more expedited data.
+Each expedited datum my contain up to 16 octets.
+.pp
+.sh 1 "Disconnection"
+.pp
+The \fIclose\fR system call will disconnect any association
+between two TP entities.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+status = close( s )
+.T&
+l l l.
+ +int+s;
+.TE
+\fR
+.)b
+.pp
+The argument \fIs\fR is a socket descriptor.
+If a Unix user process terminates, Unix will close all files and
+sockets associated with the process, which means all transport
+connections associated with the process will be disconnected.
+.sh 1 "Indications from the transport layer to the transport user"
+.pp
+While the above set of system calls allows you to establish
+a connection, transfer data, and disconnect, 
+several elements of the transport service are not supported
+by these system calls alone.
+These system calls do not support 
+any way to indicate to the
+to the transport user
+the
+presence of expedited data or
+a disconnection initiated by the peer or by one of the
+cooperating TP entities.
+.pp
+The Unix signal mechanism is used to provide these
+service elements.
+When an expedited data TSDU arrives, the TP interrupts
+the user with a SIGURG signal ("urgent condition present on socket").
+The user must have previously registered a procedure to handle
+the signal by using the \fIsigvec()\fR system call or the
+\fIsignal()\fR library routine provided for that purpose.
+The signal handler takes the form
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+int  sighandler( signal_number)
+.T&
+l l l.
+ +int+signal_number;
+.TE
+\fR
+.)b
+.pp
+The \fIsignal_number\fR argument will be the well-known constant SIGURG.
+There are two reasons for 
+the transport layer to issue
+a SIGURG:  
+expedited data
+are present or
+disconnection was initiated by a transport entity or by the peer.
+Should the user have more than one transport connection open,
+another system call is used to determine to which socket(s)
+the urgent condition applies.
+This is the \fIselect()\fR system call, described below.
+.pp
+When the SIGURG indicates a disconnection, there may be
+user data from the peer present.
+TP 
+discards all queued normal data and expedited data.
+It saves the disconnect data for the user to receive via the
+\fIgetsockopt()\fR system call.
+Unfortunately, the socket is already considered closed
+by the kernel, so there is no way
+for the user to read the incoming disconnect data, so receipt
+of disconnect data is not supported.
+.\"
+.\"If the user does not receive the disconnect data before the
+.\"reference timer expires, the data will be discarded and the
+.\"socket will be closed.
+.pp
+Transport service users may use more than one transport
+connection at a time.
+The \fIselect()\fR system call facilitates this.
+.(b
+\fC
+.TS
+tab(+);
+l s s s.
+#include <sys/types.h>
++
+nfound = select( num_to_scan, recvmask, sendmask, 
++exceptmask, timeout )
+.T&
+l l l.
+ +int+nfound, num_to_scan;
+ +fd_set+*recvmask, *sendmask, *exceptmask;
+ +time+timeout;
+.TE
+\fR
+.)b
+.pp
+This system call takes as parameters a set of masks 
+that specify a subset of the socket descriptors that are in
+use by the user program.
+\fISelect()\fR inspects the sockets to see if they have data
+to be received, can service a send without blocking, or
+have an exceptional condition pending, respectively.
+The masks will be set upon return to indicate the socket descriptors
+for which the respective conditions exist.
+The \fInum_to_scan\fR argument limits the number of sockets that are
+inspected.
+The call will return within the amount of time given in the
+\fItimeout\fR parameter, or, if the parameter is zero, \fIselect()\fR
+will block indefinitely.
+.\" FIGURE
+.so figs/TS_primitives.nr
+.pp
+.CF
+summarizes the mapping of the transport service primitives
+to Unix facilities.
diff --git a/share/doc/iso/wiscman/arp.4p b/share/doc/iso/wiscman/arp.4p
new file mode 100644
index 0000000..f0fe2a0
--- /dev/null
+++ b/share/doc/iso/wiscman/arp.4p
@@ -0,0 +1,118 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"	@(#)arp.4p	6.2 (Berkeley) 5/15/86
+.\"
+.TH ARP 4P "May 15, 1986"
+.UC 5
+.SH NAME
+arp \- Address Resolution Protocol
+.SH SYNOPSIS
+.B "pseudo-device ether"
+.SH DESCRIPTION
+ARP is a protocol used to dynamically map between DARPA Internet
+and 10Mb/s Ethernet addresses.  It is
+used by all the 10Mb/s Ethernet interface drivers.
+It is not specific to Internet protocols or to 10Mb/s Ethernet,
+but this implementation currently supports only that combination.
+.PP
+ARP caches Internet-Ethernet address mappings.  When an interface
+requests a mapping for an address not in the cache, ARP queues the
+message which requires the mapping and broadcasts
+a message on the associated network requesting the address mapping.
+If a response is provided, the new mapping is cached and any pending
+message is transmitted.
+ARP will queue
+at most one packet while waiting for a mapping request to be responded to;
+only the most recently ``transmitted'' packet is kept.
+.PP
+To facilitate communications with systems which do not use ARP,
+.IR ioctl \^s
+are provided to enter and delete entries in the Internet-to-Ethernet tables.
+Usage:
+.LP
+.nf
+.ft B
+	#include <sys/ioctl.h>
+	#include <sys/socket.h>
+	#include <net/if.h>
+	struct arpreq arpreq;
+
+	ioctl(s, SIOCSARP, (caddr_t)&arpreq);
+	ioctl(s, SIOCGARP, (caddr_t)&arpreq);
+	ioctl(s, SIOCDARP, (caddr_t)&arpreq);
+.fi
+.ft R
+Each ioctl takes the same structure as an argument.
+SIOCSARP sets an ARP entry, SIOCGARP gets an ARP entry, and SIOCDARP
+deletes an ARP entry.  These ioctls may be applied to any socket descriptor
+.I s,
+but only by the super-user.
+The
+.I arpreq
+structure contains:
+.LP
+.RS
+.ta \w'#define\ \ 'u +\w'ATF_USETRAILERS\ \ 'u +\w'0x08\ \ \ \  'u
+.nf
+/*
+ * ARP ioctl request
+ */
+struct arpreq {
+	struct sockaddr	arp_pa;		/* protocol address */
+	struct sockaddr	arp_ha;		/* hardware address */
+	int	arp_flags;		/* flags */
+};
+/*  arp_flags field values */
+#define ATF_COM		0x02	/* completed entry (arp_ha valid) */
+#define	ATF_PERM	0x04	/* permanent entry */
+#define	ATF_PUBL	0x08	/* publish (respond for other host) */
+#define	ATF_USETRAILERS	0x10	/* send trailer packets to host */
+.fi
+.RE
+.LP
+The address family for the
+.I arp_pa
+sockaddr must be AF_INET; for the 
+.I arp_ha
+sockaddr it must be AF_UNSPEC.
+The only flag bits which may be written are ATF_PERM, ATF_PUBL
+and ATF_USETRAILERS.
+ATF_PERM causes the entry to be permanent if the ioctl call succeeds.
+The peculiar nature of the ARP tables may cause the ioctl to fail if more
+than 8 (permanent) Internet host addresses hash to the same slot.
+ATF_PUBL specifies that the ARP code should respond to ARP requests for the
+indicated host coming from other machines.  This allows a host to act as an
+``ARP server,'' which may be useful in convincing an ARP-only machine to talk
+to a non-ARP machine.
+.PP
+ARP is also used to negotiate the use of trailer IP encapsulations;
+trailers are an alternate encapsulation used to allow efficient packet
+alignment for large packets despite variable-sized headers.
+Hosts which wish to receive trailer encapsulations so indicate
+by sending gratuitous ARP translation replies along with replies
+to IP requests; they are also sent in reply to IP translation replies.
+The negotiation is thus fully symmetrical, in that either or both hosts
+may request trailers.
+The ATF_USETRAILERS flag is used to record the receipt of such a reply,
+and enables the transmission of trailer packets to that host.
+.PP
+ARP watches passively for hosts impersonating the local host (i.e. a host
+which responds to an ARP mapping request for the local host's address).
+.SH DIAGNOSTICS
+.B "duplicate IP address!! sent from ethernet address: %x:%x:%x:%x:%x:%x."
+ARP has discovered another host on the local network which responds to
+mapping requests for its own Internet address.
+.SH SEE ALSO
+ec(4), de(4), il(4), inet(4F), arp(8C), ifconfig(8C)
+.br
+``An Ethernet Address Resolution Protocol,'' RFC826, Dave Plummer,
+Network Information Center, SRI.
+.br
+``Trailer Encapsulations,'' RFC893, S.J. Leffler and M.J. Karels,
+Network Information Center, SRI.
+.SH BUGS
+ARP packets on the Ethernet use only 42 bytes of data; however, the smallest
+legal Ethernet packet is 60 bytes (not including CRC).
+Some systems may not enforce the minimum packet size, others will.
diff --git a/share/doc/iso/wiscman/clnp.4p b/share/doc/iso/wiscman/clnp.4p
new file mode 100644
index 0000000..07efd1a
--- /dev/null
+++ b/share/doc/iso/wiscman/clnp.4p
@@ -0,0 +1,91 @@
+.TH CLNP 4P "9 December 1988"
+.ds ]W Wisconsin ARGO 1.0
+.UC 4
+.SH NAME
+clnp \- Connectionless-Mode Network Protocol
+.SH SYNOPSIS
+.B #include <sys/socket.h>
+.br
+.B #include <netargo/iso.h>
+.br
+.B #include <netargo/clnp.h>
+.PP
+.B s = socket(AF_ISO, SOCK_RAW, 0);
+.SH DESCRIPTION
+CLNP is the connectionless-mode network protocol used by the 
+connectionless-mode network service. This protocol is specified in
+ISO 8473.
+It may be accessed
+through a \*(lqraw socket\*(rq for debugging purposes only.
+CLNP sockets are connectionless,
+and are normally used with the
+.I sendto 
+and
+.I recvfrom 
+calls, though the
+.IR connect (2)
+call may also be used to fix the destination for future
+packets (in which case the 
+.IR read (2)
+or
+.IR recv (2)
+and 
+.IR write (2)
+or
+.IR send (2)
+system calls may be used).
+.PP
+Outgoing packets automatically have a CLNP header prepended to
+them. Incoming packets received by the user contain the full CLNP header.
+The following \fIsetsockopt\fR options apply to CLNP:
+.TP
+CLNPOPT_FLAGS
+Sets the flags which are passed to clnp when sending a datagram.
+Valid flags are:
+.nf
+.br
+CLNP_NO_SEG-Do not allow segmentation
+CLNP_NO_ER-Suppress ER pdus
+CLNP_NO_CKSUM-Do not generate the CLNP checksum
+.br
+.fi
+.TP
+CLNPOPT_OPTS
+Sets CLNP options. The options must be formatted exactly as specified by
+ISO 8473, section 7.5 "Options Part." Once an option has been set, it will
+be sent on all packets until a different option is set.
+.SH DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.TP 15
+[EISCONN]
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.TP 15
+[ENOTCONN]
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.TP 15
+[ENOBUFS]
+when the system runs out of memory for
+an internal data structure;
+.TP 15
+[EADDRNOTAVAIL]
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists;
+.TP 15
+[EHOSTUNREACH]
+when trying to send a datagram, but no route to the destination
+address exists.
+.TP 15
+[EINVAL]
+when specifying unsupported options.
+.SH SEE ALSO
+send(2), recv(2), intro(4N), iso(4F)
+.SH BUGS
+Packets are sent with the type code of 0x1d (technically an invalid
+packet type) for lack of a better way to identify raw CLNP packets.
+.PP
+No more than MLEN bytes of options can be specified.
diff --git a/share/doc/iso/wiscman/cons.4 b/share/doc/iso/wiscman/cons.4
new file mode 100644
index 0000000..73bd3fc
--- /dev/null
+++ b/share/doc/iso/wiscman/cons.4
@@ -0,0 +1,241 @@
+.\"
+.\" 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1986,1987,1988
+.\" LICENSED MATERIALS - PROPERTY OF IBM
+.\" REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
+.\"
+.\"$Header:cons.4_ca 11.3$
+.\"$ACIS:cons.4_ca 11.3$
+.\"$Source: /ibm/acis/usr/man/man4/RCS/cons.4_ca,v $
+.\" This file uses -man macros.
+.TH CONS 4 "Sept 1988" "Space overwritten by .AC macro" " " 
+.AC 1 0 
+.SH NAME
+cons \- keyboard and console display interface
+.SH DESCRIPTION
+The keyboard and various possible displays combine to 
+provide a terminal-like
+interface to the system. Internally, these are separate devices which
+software combines to emulate a normal terminal. See the appropriate manual
+pages for information about each display and the keyboard.
+.PP
+The keyboard adapter also supports the speaker, which is activated 
+when the ASCII character \fBbel\fP (\fB^G\fP)
+is sent to the display with software.
+For additional information on speaker control, see \fIspeaker\fP(4).
+.PP
+.B Console Device Control
+.PP
+The display devices, 
+\fI/dev/ttyaed\fR, \fI/dev/ttyap16\fR, \fI/dev/ttyap8c\fR,
+\fI/dev/ttyapa8\fR, \fI/dev/ttyega\fR, \fI/dev/ttymono\fR, 
+\fI/dev/ttympel\fR, \fI/dev/ttyvga\fR, and \fI/dev/tty8514\fR are all
+minor devices under 
+\fI/dev/console\fR, and are all capable of displaying console output. 
+Unique to this system is the fact that you may have one or more of these
+displays on your workstation at a time and any one can act as a console.
+With only one keyboard and system mouse, the console driver
+multiplexes these input devices to the many displays.
+All of the displays may have simultaneous logins and the user
+can ``hot key'' between each display.
+At first, this 
+``input focus''
+is on
+the first device in the above sequence to 
+be found at initialization time.  The input focus
+can be manually switched to the next available display by pressing the
+default ``hot key'' <Alt><Scroll Lock>. 
+When the
+input focus
+is on a display, all keyboard and mouse data are sent to the process(es)
+that read from that display.
+.PP
+If no other console tty device is open, and only the default input 
+emulator is used (see \fIkbdemul\fP(4)), the input focus is set to
+\fI/dev/console\fP.  In this case, <Alt><Scroll Lock> only switches
+which display gets console output.
+In the case where one or more tty devices are open, or the default input
+emulator changes, \fI/dev/console\fP gets no input.  It tries to send output
+to the currently focused device.  A user can redirect these console messages
+to any tty devices with the TIOCCONS ioctl.
+.PP
+To support the many displays and the multiplexing between them, an
+emulator package was developed to work with the console driver.
+This package allows different types of emulation on input and output to
+be written independently of device.
+.PP
+The display devices \fI/dev/aed\fP, \fI/dev/apa16\fP, \fI/dev/apa8c\fP,
+\fI/dev/apa8\fP, \fI/dev/ega\fR, \fI/dev/mono\fP, 
+\fI/dev/mpel\fR, \fI/dev/vga\fR, and \fI/dev/ibm8514\fR 
+are also minor devices to 
+\fI/dev/console\fP.  They are typically used by window managers and other
+graphic applications.  When the focus is pointed to one of these display
+devices, the console messages are put in a circular buffer 
+(see \fIbufemul\fP(4))
+unless redirected with the TIOCCONS ioctl.
+The buffer is flushed to the screen upon closing the display device.
+.PP
+The following are generic console \fIioctls\fP defined in \fIscreen_cousf.u\fP:
+.TP 20
+CON_SELECT_SCREEN 
+Output focus is set to display number (arg > 0) or 
+to next display in list (arg < 0).  Previous display number is returned.  
+.TP 20
+CON_GET_SCREEN 
+Just returns the current output focus display number.  
+.TP 20
+EIGETD 
+Gets the number of the current input emulator for this display.  
+.TP 20
+EOGETD 
+Gets the number of the current output emulator for this display.  
+.TP 20
+EISETD 
+Sets the input emulator and returns the previous for this display.  
+.TP 20
+EOSETD 
+Sets the output emulator and returns the previous for this display.  
+.TP 20
+CON_INIT_SCREEN 
+Initializes the specified display (arg >=0) or this display
+(arg < 0).  
+.TP 20
+CON_GET_FOCUS_CODE 
+Gets the current keyboard code for setting the console 
+focus (affects xemul only).  
+.TP 20
+CON_SET_FOCUS_CODE 
+Sets the current keyboard code for setting the console
+focus (affects xemul only), and return the previous code.
+.PP
+All of the above commands take integer arguments.  
+.PP
+The following are generic console \fIioctls\fP defined in \fIconsio.h\fP: 
+.TP 20
+SCRIOCGETF 
+Gets the screen control flags for the given display number.  
+.TP 20
+SCRIOCSETC 
+Sets the screen control flags for the given display number.  
+.PP
+.in +10
+SCRIOCGETF and SCRIOCSETC use the following structure:
+.DT
+.nf
+struct screen_control { 
+			 int   device; /* which screen/display to control */  
+			 int   switches; /* Flags for this screen */
+};
+.fi
+.sp 2
+.RS 6
+.TP 20
+CONSDEV_PRESENT 
+Display is present on this system.  
+This bit cannot be changed by SCRIOSETC. 
+.TP 20
+CONSDEV_KERNEL 
+Display is available to the kernel.  
+.TP 20
+CONSDEV_USER 
+Display is available to the user.  
+.TP 20
+CONSDEV_INIT 
+Display has been initialized for output.  
+.TP 20
+CONSDEV_TTY 
+Diplay has been initialuzed for output.  
+This bit cannot be changed by SCRIOSETC.
+.TP 20
+CONSDEV_GRA 
+Graphics display has been opened directly by minor device number. 
+This bit cannot be changed by SCRIOSETC.
+.TP 20
+CONSDEV_NOINPUT 
+Prevents the "round-robin" console focus-switching from finding this 
+display.  This flag is cleared when \fIbuf_emul\fP is closed.  
+.TP 20
+SCRSETNIP 
+Sets the no-input bit in the screen control flags for the 
+display's current file description.  
+.TP 20
+SCRCLRNIP 
+Clears the no-input bit in the screen control flags for the 
+display's current file description.  
+.RE
+.PP
+The following \fIioctl\fP is defined in \fIbufemul.h\fP: 
+.TP 20
+BUFDISPINFO 
+\fIArg\fP returns the following information about the display: 
+.PP
+.RS 6
+.TP 20
+BUF_IS_ATR(arg) 
+True when the CPU is an IBM 6152 Academic System.  
+.TP 20
+BUF_IS_RTPC(arg) 
+True when the CPU is an IBM RT PC.  
+.TP 20
+BUF_GET_PCCODE(x) 
+Get PC-Code version/type byte (IBM 6152 only).  
+.bp
+.TP 20
+BUF_GET_VGA(arg) 
+Get the type of display connected to the VGA.  
+0=none, 1=color, 2=gray.  Valid only for the IBM 6152 Academic System.   
+.TP 20
+BUF_GET_8514(arg) 
+Get the type of display connected to the IBM 8514/A.  
+0=none, 1=color, 2=gray.  Valid only for the IBM 6152 Academic System.  
+.TP 20
+BUF_GET_EGA(arg) 
+Returns the value of the switches on the EGA display.  Valid only for the IBM RT PC with an EGA card installed.  
+.RE
+.PP
+All of the above \fIioctl\fP system calls are device-independent controls 
+for dealing with the emulators.  
+.PP
+Each emulator has its own set of \fIioctls\fP for its own emulation purposes.  
+These other \fIiotls\fP are used in window-manager emulators for operations 
+such as passing/positioning the mouse locator for/on the display.  
+See the man page for any particular emulator for more information.  
+.PP
+.SH NOTE
+On the IBM RT PC, the kernel flashes ``98'' on the LEDs if it cannot find any
+configured display during initialization, and then proceeds. 
+.SH DIAGNOSTICS
+None.
+.SH FILES
+.PP
+For the IBM RT PC:
+.br
+/dev/console 
+.br
+/dev/aed 
+.br
+/dev/apa16
+.br
+/dev/apa8c
+.br
+/dev/apa8
+.br
+/dev/ega
+.br
+/dev/mono
+.br
+/dev/mpel
+.br
+.PP
+For the IBM 6152 Academic System:
+.br
+/dev/vga
+.br
+/dev/ibm8514
+.SH "SEE ALSO"
+bufemul(4), bus(4), ibm5081(4), ibm5151(4), ibm6153(4), ibm6154(4),
+ibm6155(4), ibm8514(4), ibmaed(4), ibmemul(4), kbdemul(4), 
+speaker(4), stdemul(4), tty(4), vga(4), xemul(4), setscreen(8)
+.br
+``IBM/4.3 Console Emulators'', in Volume II, Supplementary Documents
+
+
diff --git a/share/doc/iso/wiscman/cons.4p b/share/doc/iso/wiscman/cons.4p
new file mode 100644
index 0000000..c8b152b
--- /dev/null
+++ b/share/doc/iso/wiscman/cons.4p
@@ -0,0 +1,196 @@
+.TH CONS 4P "9 December 1988"
+.ds ]W Wisconsin ARGO 1.0
+.UC 4
+.SH NAME
+CONS \- Connection Oriented Network Service 
+.SH SYNOPSIS
+For use as a network service (CONS):
+.nf
+.sp
+\fB#include <sys/socket.h>\fR
+\fB#include <sys/mbuf.h>\fR
+\fB#include <netargo/iso.h>\fR
+\fB#include <netargo/cons.h>\fR
+\fB#include <netargo/iso_errno.h>\fR
+.sp
+\fBint cons_output(isop, m, len, isdatagram)\fR
+.sp
+or for use as a subnetwork service (COSNS):
+.sp
+\fB#include <sys/socket.h>\fR
+\fB#include <sys/mbuf.h>\fR
+\fB#include <netargo/iso.h>\fR
+\fB#include <net/if.h>\fR
+\fB#include <netargo/cons.h>\fR
+\fB#include <netargo/iso_errno.h>\fR
+.sp
+\fBint cosns_output(ifp, m, dst)
+.fi
+.SH DESCRIPTION
+.PP
+The Connection Oriented Network Service (CONS) implemented for the AOS R2
+at the University of Wisconsin - Madison
+supports transport protocols, acting as a network service,
+and it also supports other network protocols, acting as a subnetwork
+service or link-layer service.
+Several software modules are combined to provide these services.
+.TP 10
+X.25
+The CCITT X.25 packet layer and link layer protocols run on
+a coprocessor (the EICON Network Adapter), which serves as a DTE.
+.TP 10
+Ecn driver
+A device driver manages the interaction between
+the coprocessor and the PC/RT.
+.TP 10
+CONS "glue"
+A software module implements portions of the OSI CONS (ISO 8878),
+which describes a way to use the X.25 protocols to support the
+OSI connection-oriented network service.
+.PP
+The OSI CONS contains several "service elements"
+that ARGO does not use or support.
+Expedited data,
+quality of service  maintenance, 
+call collision resolution,
+permanent virtual circuits,
+user data on connect and release,
+user-level acknowledgement
+("receipt confirmation" in CCITT/ISO argot), and reset/resynchronize
+are not supported.
+Several of the service primitives for connection establishment
+and release are not supported, and 
+numerous parameters to other primitives specified in the OSI CONS
+are not supported.
+The CONS glue does provide all the support necessary to run
+ISO transport classes 0 and 4 over X.25, and ISO CLNP (also called
+ISO IP) over X.25.
+The subnetwork dependent convergence functions implemented in the glue
+permit interoperability with
+OSINET and EAN at this writing.
+Interoperability with other networks will be established in the future.
+.PP
+The coprocessor that implements the X.25 link and packet layers
+is the Eicon Technologies Access/X.25 Stand-Alone Network Adaper 
+(see \fIecn(4)\fR).
+.PP
+The glue module provides two interfaces to higher layers:
+a "subnetwork service" (COSNS) used by network layer protocols, which
+has a typical BSD kernel device driver interface
+and
+a "network service" (CONS) used by transport protocols, which has
+a procedure call interface similar to that of IP and CLNP.
+.PP
+The network service is reliable and sequenced but does not
+provide a graceful close service; it provides only an abort service.
+.PP
+The subnetwork service is neither reliable nor sequenced.
+The subnetwork service implemented by the glue hides the
+connection-oriented aspects of the protocols; nevertheless, 
+we call it the "connection-oriented subnetwork service" (COSNS)
+here, for lack of a better name.
+.SS "LIBRARIES
+No libraries are needed to use the CONS, however,
+the numerous error values returned by X.25 cannot be accommodated
+by the standard \fIperror()\fR in the C library.
+The ISO library 
+.nf
+.sp
+.in +5
+\fC/usr/argo/lib/libisodir.a\fR
+.in -5
+.sp
+.fi
+provides an expanded perror() to handle the additional error return codes.
+.SS "ERROR VALUES
+.PP
+The error codes returned by the CONS are taken from
+the diagnostic code of the X.25 level 3 packets, as
+descibed in figure 14-B of ISO 8208 (the ISO standard which
+is equivalent to CCITT X.25).
+The actual error value returned in 
+\fIerrno\fR
+is the X.25 diagnostic code in the lower 10 bits
+logically "or"ed with the hexadecimal value 0x8400 (bits
+10 and 15 set, counting from zero at the the least significant bit).
+The error values can be found in 
+the file
+.nf
+.in +5
+.sp
+\fC<netargo/iso_errno.h>\fR
+.sp
+.in -5
+.fi
+.SS "PROTOCOL IDENTIFICATION
+.PP
+The purpose of this section is to describe how incoming packets
+are forwarded from the glue to the various higher
+layers (ISO transport, CLNP), how
+routes are chosen from the higher layers to the glue, and
+how NSAP-addresses are related to all this.
+.SS Outgoing path:
+The ARGO transport entity routes packets either to
+the CONS glue, to the CLNP module, or to the DARPA Internet IP
+module, based on the value of the network service parameter
+given to the transport layer by the user.
+The \fInetserv\fR property of records in the ARGO
+directory service database
+can be used to determine the network service to be used by the
+transport layer.  See also \fIisodir(5)\fR and \fIisodir(3)\fR.
+.PP
+The connectionless network layer entity routes packets to the 
+COSNS based on the routing table entries in the connectionless network layer.
+This means that any type of NSAP-address supported by the kernel
+may be used with a CLNP packet
+that is routed over X.25.
+.PP
+When the glue creates an X.25 Call Request packet, it
+places an X.121 address (DTE address)
+in both the Calling and Called DTE address fields.
+The X.121 addresses are extracted from the \fISNPA cache\fR,
+a table that maps NSAP-addresses to SNPA-addresses, and
+is maintained by the ES-IS protocol module of the OSI network layer.
+In addition to placing a DTE address in the X.25 packet,
+the "glue" may 
+uses the 1984 Called Address Extension facility to convey the 
+NSAP-addresses.
+Whether or not this is done depends on the compile-time option -DX25_1984.
+.SS Incoming path:
+The X.25 Call Request User Data field and the
+1984 X.25 Address Extension Facility are used
+to determing the incoming path through the network layer.
+The NSAP addresses passed up along with the packet are taken from the
+Address Extension facility, if present.
+If the facility is absent, the glue creates two type-37 NSAP-addresses,
+filling in the X.121 address from the called and
+calling DTE-addresses on the Call Request packet, if present.
+The glue then requests of the ES-IS module to add an entry to the 
+SNPA cache to associate the calling DTE address with its 
+derived NSAP-address.
+These cache entries have a holding of 5 minutes, and get
+refreshed as long as there is activity on the virtual circuit
+resulting from the call request.
+.PP
+If a Call Request packet contains a protocol identifier
+as described in ISO PTDR 9577, this protocol identifier is used
+to route the packet to the higher layers.
+If there is no protocol identifier, the higher layer is assumed to be ISO
+transport.
+.SH "BUGS
+.PP
+If an incoming X.25 Call Request contains no DTE-addresses and 
+no NSAP-addresses (in the Address Extension facility)
+the kernel panics.
+.SH "SEE ALSO
+.PP
+isodir(3),
+ecn(4),
+clnp(4),
+tp(4),
+isodir(5),
+isoroute(8),
+ifconfig(8),
+netstat(1),
+xstat(8),
+"ARGO 1.0 Kernel Programmer's Manual"
diff --git a/share/doc/iso/wiscman/if.4n b/share/doc/iso/wiscman/if.4n
new file mode 100644
index 0000000..ca6884c
--- /dev/null
+++ b/share/doc/iso/wiscman/if.4n
@@ -0,0 +1,136 @@
+#
+# 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1988
+# LICENSED MATERIALS - PROPERTY OF IBM
+# REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
+#
+.\"# $Header:if.4n_ca 1.5$ 
+.\"# $ACIS:if.4n_ca 1.5$ 
+.\"# $Source: /ibm/acis/usr/man/man4/RCS/if.4n_ca,v $ 
+.\" @(#)if.4n	1.2 87/08/23 3.2/4.3NFSSRC
+.\" @(#)if.4n	1.2 87/02/10 NFSSRC
+.\" @(#)if.4n 1.1 86/09/25 SMI;
+.TH IF 4N "Sept 1988" "Space overwritten" " "
+.AC 1 0
+.SH NAME
+if \- general properties of network interfaces (NFS only)
+.SH DESCRIPTION
+.IX  "if device"  ""  "\fLif\fP \(em network interface general properties"  ""  PAGE START
+Each network interface in a system corresponds to a
+path through which messages may be sent and received.  A network
+interface usually has a hardware device associated with it, but
+certain interfaces, such as the loopback interface
+.IR lo (4),
+do not.
+.LP
+At boot time each interface which has underlying hardware support
+makes itself known to the system during the autoconfiguration
+process.  Once the interface has acquired its address it is
+expected to install a routing table entry so that messages may
+be routed through it.  Most interfaces require some part of
+their address specified with an SIOCSIFADDR ioctl before they
+will allow traffic to flow through them.  On interfaces where
+the network-link layer address mapping is static, only the
+network number is taken from the ioctl; the remainder is found
+in a hardware specific manner.  On interfaces which provide
+dynamic network-link layer address mapping facilities (for example,
+10Mb/s Ethernets using
+.IR arp (4P),),
+the entire address specified in the ioctl is used.
+.LP
+The following 
+.I ioctl
+calls may be used to manipulate network interfaces.  Unless
+specified otherwise, the request takes an
+.I ifreq
+structure as its parameter.  This structure has the form
+.RS
+.nf
+struct	ifreq {
+	char	ifr_name[16];		/* name of interface (e.g. "ec0") */
+	union {
+		struct	sockaddr ifru_addr;
+		struct	sockaddr ifru_dstaddr;
+		short	ifru_flags;
+	} ifr_ifru;
+#define	ifr_addr		ifr_ifru.ifru_addr	/* address */
+#define	ifr_dstaddr	ifr_ifru.ifru_dstaddr	/* other end of p-to-p link */
+#define	ifr_flags		ifr_ifru.ifru_flags	/* flags */
+};
+.fi
+.RE
+.IP SIOCSIFADDR 5
+.IX  "ioctls for sockets"  "SIOCSIFADDR"  "\fLioctl\fP's for sockets"  "\fLSIOCSIFADDR\fP \(em set ifnet address"
+.IX  "SIOCSIFADDR set ifnet address"  ""  "\fLSIOCSIFADDR\fP \(em set ifnet address"
+.IX  set "ifnet address ioctl \(em \fLSIOCSIFADDR\fP"
+.IX  "network interface ioctls"  SIOCSIFADDR  "network interface \fLioctl\fP's" "\fLSIOCSIFADDR\fP \(em set ifnet address"
+Set interface address.  Following the address
+assignment, the ``initialization'' routine for
+the interface is called.
+.IP SIOCGIFADDR
+.IX  "ioctls for sockets"  "SIOCGIFADDR"  "\fLioctl\fP's for sockets"  "\fLSIOCGIFADDR\fP \(em get ifnet address"
+.IX  "SIOCGIFADDR get ifnet address"  ""  "\fLSIOCGIFADDR\fP \(em get ifnet address"
+.IX  get "ifnet address \fLioctl\fP \(em \fLSIOCGIFADDR\fP"
+.IX  "network interface ioctls"  SIOCGIFADDR  "network interface \fLioctl\fP's" "\fLSIOCGIFADDR\fP \(em get ifnet address"
+Get interface address.
+.IP SIOCSIFDSTADDR
+.IX  "ioctls for sockets"  "SIOCSIFDSTADDR"  "\fLioctl\fP's for sockets"  "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
+.IX  "SIOCSIFDSTADDR set p-p address"  ""  "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
+.IX  set "p-p address ioctl \(em \fLSIOCSIFDSTADDR\fP"
+.IX  "network interface ioctls"  SIOCSIFDSTADDR  "network interface \fLioctl\fP's" "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
+Set point to point address for interface.
+.IP SIOCGIFDSTADDR
+.IX  "ioctls for sockets"  "SIOCGIFDSTADDR"  "\fLioctl\fP's for sockets"  "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
+.IX  "SIOCGIFDSTADDR get p-p address"  ""  "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
+.IX  get "p-p address \fLioctl\fP \(em \fLSIOCGIFDSTADDR\fP"
+.IX  "network interface ioctls"  SIOCGIFDSTADDR  "network interface \fLioctl\fP's" "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
+Get point to point address for interface.
+.IP SIOCSIFFLAGS
+.IX  "ioctls for sockets"  "SIOCSIFFLAGS"  "\fLioctl\fP's for sockets"  "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
+.IX  "SIOCSIFFLAGS set ifnet flags"  ""  "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
+.IX  set "ifnet flags ioctl \(em \fLSIOCSIFFLAGS\fP"
+.IX  "network interface ioctls"  SIOCSIFFLAGS  "network interface \fLioctl\fP's" "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
+Set interface flags field.  If the interface is marked down,
+any processes currently routing packets through the interface
+are notified.
+.IP SIOCGIFFLAGS
+.IX  "ioctls for sockets"  "SIOCGIFFLAGS"  "\fLioctl\fP's for sockets"  "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
+.IX  "SIOCGIFFLAGS get ifnet flags"  ""  "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
+.IX  get "ifnet flags \fLioctl\fP \(em \fLSIOCGIFFLAGS\fP"
+.IX  "network interface ioctls"  SIOCGIFFLAGS  "network interface \fLioctl\fP's" "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
+Get interface flags.
+.IP SIOCGIFCONF
+.IX  "ioctls for sockets"  "SIOCGIFCONF"  "\fLioctl\fP's for sockets"  "\fLSIOCGIFCONF\fP \(em get ifnet list"
+.IX  "SIOCGIFCONF get ifnet list"  ""  "\fLSIOCGIFCONF\fP \(em get ifnet list"
+.IX  get "ifnet list \fLioctl\fP \(em \fLSIOCGIFCONF\fP"
+.IX  "network interface ioctls"  SIOCGIFCONF  "network interface \fLioctl\fP's" "\fLSIOCGIFCONF\fP \(em get ifnet list"
+Get interface configuration list.  This request takes an
+.I ifconf
+structure (see below) as a value-result parameter.  The 
+.I ifc_len
+field should be initially set to the size of the buffer
+pointed to by 
+.IR ifc_buf .
+On return it will contain the length, in bytes, of the
+configuration list.
+.RS
+.nf
+/*
+ * Structure used in SIOCGIFCONF request.
+ * Used to retrieve interface configuration
+ * for machine (useful for programs which
+ * must know all networks accessible).
+ */
+struct	ifconf {
+	int	ifc_len;		/* size of associated buffer */
+	union {
+		caddr_t	ifcu_buf;
+		struct	ifreq *ifcu_req;
+	} ifc_ifcu;
+#define	ifc_buf	ifc_ifcu.ifcu_buf	/* buffer address */
+#define	ifc_req	ifc_ifcu.ifcu_req	/* array of structures returned */
+};
+.RE
+.fi
+.IX  "if device"  ""  "\fLif\fP \(em network interface general properties"  ""  PAGE END
+.SH "SEE ALSO
+arp(4P), ec(4S), lo(4)
diff --git a/share/doc/iso/wiscman/iso.4f b/share/doc/iso/wiscman/iso.4f
new file mode 100644
index 0000000..5e7ca88
--- /dev/null
+++ b/share/doc/iso/wiscman/iso.4f
@@ -0,0 +1,87 @@
+.TH ISO 4F "9 December 1988"
+.ds ]W Wisconsin ARGO 1.0
+.UC  4
+.SH NAME
+iso \- ISO protocol family
+.SH SYNOPSIS
+.B #include <sys/types.h>
+.br
+.B #include <netargo/iso.h>
+.SH DESCRIPTION
+The ISO protocol family is a collection of protocols
+that uses the ISO address format.
+The ISO family provides protocol support for the
+SOCK_SEQPACKET abstraction through the TP protocol (ISO 8073), 
+and for the SOCK_RAW abstraction
+by providing direct access (for debugging) to the
+CLNP (ISO 8473) network layer protocol.
+.SH ADDRESSING
+ISO addresses are based upon ISO 8348/AD2, 
+"Addendum to the Network Service Definition Covering Network Layer Addressing."
+.PP
+Sockets bound to the OSI protocol family use
+the following address structure:
+.sp 1
+.nf
+._f
+struct sockaddr_iso {
+	short	siso_family;
+	u_short	siso_tsuffix;
+	struct	iso_addr siso_addr;
+};
+.sp 1
+.fi
+.PP
+This fields of this structure are:
+.TP 10
+\fIsiso_family:\fR
+Identifies the domain: AF_ISO or AF_INET.
+.TP 10
+\fIsiso_tsuffix:\fR
+The transport part of the address, described below.
+.TP 10
+\fIsiso_addr:\fR
+The network part of the address, described below.
+.SS TRANSPORT ADDRESSING
+.PP
+The above structure describes a simple form of 
+ISO \fItransport\fR addresses.
+An ISO transport address is similar to an Internet address in that
+it contains a network-address portion and a portion that the
+transport layer uses to multiplex its services among clients.
+In the Internet domain, this portion of the address is called a \fIport\fR.
+In the ISO domain, this is called a \fItransport selector\fR
+(also known at one time as a \fItransport suffix\fR).
+While ports are always 16 bits, 
+transport selectors may be
+of (almost) arbitrary size.
+ARGO supports two forms of transport selectors:
+"normal" or 16-bit selectors, and
+"extended" selectors, or selectors that may be from 1-64 bytes
+in length.
+The default mode of operation is to use 16-bit transport selectors.
+These addresses can be represented with the above structure.
+When transport selectors of any other size are used, the transport
+selector is kept in a separate structure.
+See the manual page \fItp(4p)\fR.
+.SS NETWORK ADDRESSING
+.PP
+ISO network addresses are limited to 20 bytes in length.
+ISO network addresses can take any format.
+ARGO 1.0 supports three formats.
+See \fIisodir(3)\fR and \fIisodir(5)\fR.
+.SH PROTOCOLS
+The ARGO 1.0 implementation of the 
+ISO protocol family comprises
+the Connectionless-Mode Network Protocol (CLNP), 
+and the Transport Protocol (TP), classes 4 and 0,
+and X.25.
+TP is used to support the SOCK_SEQPACKET
+abstraction.
+A raw interface to CLNP is available
+by creating an ISO socket of type SOCK_RAW.
+This is used for CLNP debugging only.
+.SH SEE ALSO
+tp(4P), cons(4p), clnp(4P), isodir(3), iso(4f), isodir(5),
+"The ARGO 1.0 Kernel Programmer's Guide",
+"Installing ARGO 1.0 on Academic Operating Systems 4.3 Release 2"
diff --git a/share/doc/iso/wiscman/rvd.4p b/share/doc/iso/wiscman/rvd.4p
new file mode 100644
index 0000000..44d7e84
--- /dev/null
+++ b/share/doc/iso/wiscman/rvd.4p
@@ -0,0 +1,90 @@
+.\"
+.\" 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1986,1987,1988
+.\" LICENSED MATERIALS - PROPERTY OF IBM
+.\" REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
+.\"
+.\"$Header:rvd.4p_ca 11.0$
+.\"$ACIS:rvd.4p_ca 11.0$
+.\"$Source: /ibm/acis/usr/man/man4/RCS/rvd.4p_ca,v $
+.\"This file contains -man macros.
+.TH RVD 4P "July 1987" "Space overwritten by .AC macro" " "
+.AC 1 0
+.SH NAME
+rvd \- Remote Virtual Disk protocol
+.SH DESCRIPTION
+RVD
+is a network service which allows several
+physical machines to share one
+physical mass storage device such as a hard disk.  The basic
+concept is to have the machine to which the device is physically attached
+act as a server to read and write blocks for all the other
+machines desiring use of the resource.
+.PP
+The server program apportions the
+physical blocks into \*(lqvirtual disk packs\*(rq based on a
+table maintained with
+.IR vddb (8).
+The packs can then be used separately by clients.  There are
+three modes of use: read-only, shared, and exclusive.
+Exclusive mode is used for
+read-write access, while read-only mode is as it sounds.
+Shared mode is not supported under IBM/4.3.
+If a disk pack is \*(lqspun up\*(rq in read-only mode,
+several clients may share the pack and read its information.  In
+exclusive mode, one client has exclusive use of the disk pack.
+.PP
+Packs are \*(lqspun up\*(rq and \*(lqspun down\*(rq with the 
+.I up
+and
+.I down
+commands (see
+.IR up (1)).
+This can be done 
+at reboot time within
+.I /etc/rc.local
+(see
+.IR rc (8))
+or
+at login time within
+.I ~/.login
+(see
+.IR csh (1)).
+Once a pack is spun up, it behaves like a disk physically attached to
+the local machine (excepting network latency).
+The client can do anything desired with the pack;
+both MS-DOS and UNIX operating system file systems have 
+been used on the same physical
+drive at the same time (on separate packs, of course).
+.PP
+RVD
+is implemented in two parts: server code and client code.  The server
+code is written as a
+.IR "user process" ,
+i.e. it does not require any special
+privileges beyond read/write access to the disks it manages.  The server
+opens a network socket and listens for UDP connections.  It also accepts
+all
+RVD
+packets and acts on them.
+RVD is a protocol different from both
+UDP and TCP,
+although similar in nature to the former.
+.PP
+The client code is implemented as a pseudo-device and corresponding
+device driver in the kernel.  It can handle up to 10
+remote virtual disks
+simultaneously, which are associated with the pseudo-devices below.
+.SH FILES
+.DT
+/dev/vd[0-9]a		block special file pseudo-device
+.br
+/dev/rvd[0-9]a		character special file pseudo-device
+.SH "SEE ALSO"
+up(1), rvddb(5), rvdtab(5),
+rvdflush(8), rvdchlog(8), rvddown(8),
+rvdexch(8), rvdflush(8), rvdlog(8), rvdsend(8), rvdshow(8),
+rvdshut(8), rvdsrv(8), savervd(8), 
+spinup(8), vddb(8), vdstats(8)
+.br
+``The Remote Virtual Disk System'' in Volume II, Supplementary Documents
+
diff --git a/share/doc/iso/wiscman/tp.4p b/share/doc/iso/wiscman/tp.4p
new file mode 100644
index 0000000..64dbf2f
--- /dev/null
+++ b/share/doc/iso/wiscman/tp.4p
@@ -0,0 +1,609 @@
+.TH TP 4P "9 December 1988"
+.ds ]W Wisconsin ARGO 1.0
+.UC 4
+.SH NAME
+TP \- ISO Transport Protocol
+.SH SYNOPSIS
+.nf
+\fB#include <sys/socket.h>\fR
+\fB#include <netargo/iso_errno.h>\fR
+\fB#include <netargo/tp_param.h>\fR
+\fB#include <netargo/tp_user.h>\fR
+.PP
+\fBs = socket( [ AF_INET, AF_ISO ] , SOCK_SEQPACKET, 0);\fR
+.SH DESCRIPTION
+.PP
+The ISO Transport Protocol implemented for AOS R2
+at the University of Wisconsin - Madison
+includes classes 0 and 4 
+of the ISO transport protocols
+as specified in
+the September 1984 version of DIS 8073.
+Class 4 of the protocol provides reliable, sequenced,
+flow-controlled, two-way
+transmission of data packets with an alternate stop-and-wait data path called
+the "expedited data" service.
+Class 0 is essentially a null transport protocol, which is used
+when the underlying network service provides reliable, sequenced,
+flow-controlled, two-way data transmission.
+Class 0 does not provide the expedited data service.
+The protocols are implemented as a single transport layer entity 
+that coexists with the Internet protocol suite.
+Class 0 may be used only in the ISO domain.
+Class 4 may be used in the Internet domain as well as in the ISO domain.
+.PP
+The user interface to this protocol is the Berkeley interprocess communication
+interface (see \fIsocket(2)\fR.)
+Two new system calls for sending and receiving
+were added to this interface to
+to permit the support the end-of-transport-service-data-unit (EOTSDU)
+indication. 
+See \fIsendv(2)\fR and \fIrecvv(2)\fR.
+If the EOTSDU is not needed, the Berkeley 4.3BSD interface
+can be used. 
+See \fIsend(2)\fR and \fIrecv(2)\fR.
+.PP
+Through the 
+\fIgetsockopt\fR and \fIsetsockopt\fR
+system calls,
+TP supports several options 
+to control such things as negotiable options
+in the protocol and protocol strategies.
+.\"These system calls are used
+.\"to submit data for inclusion on connect and disconnect TPDUs. 
+The options are defined in \fB<netargo/tp_user.h>\fR,
+and are described below.
+.\".PP
+.\"The options marked with a percent sign ( \fB%\fR )
+.\"are limited to use by the super-user.
+.PP
+In the tables below,
+the options marked with a pound sign ( \fB#\fR )
+may be used 
+with \fIsetsockopt()\fR
+after a connection is established.
+Others must be used before the connection
+is established, in other words,
+before calling
+\fIconnect()\fR or 
+\fIaccept()\fR.
+All options may be used 
+with \fIgetsockopt()\fR
+before or
+after a connection is established.
+.\"
+.\" .PP
+.\" The options marked with an exclamation point ( \fB!\fR )
+.\" may be used after a connection is released,
+.\" but before 
+.\" the TP reference timer (which generally
+.\" has a value in minutes) expires, and before
+.\" a \fIclose()\fR system call.
+.\" In other words, these commands may be used when the peer closes
+.\" a connection (possibly causing a disconnect indication), as long as the command
+.\" is issued "soon" after the disconnection occurred.  
+.\" Disconnect data may be sent by the side initiating the close
+.\" but not by the passive side ("passive" with respect to the closing
+.\" of the connection), so there is no need to read disconnect data
+.\" after calling \fIclose()\fR.
+.\" .PP
+.\" The implementation of data on connect and disconnect is incomplete
+.\" and is not supported.
+.sp 1
+.TP 25
+\fBName\fR
+\fBValue [default]\fR
+.IP
+\fBDescription\fR
+.\".TP 25
+.\"TPOPT_CONN_DATA
+.\"(char *) [none]
+.\".IP
+.\"Data to send on \fIconnect()\fR.
+.\".TP 25
+.\"TPOPT_DISC_DATA\fB # !\fR
+.\"(char *) [none]
+.\".IP
+.\"Data to send on \fIclose()\fR.
+.\".TP 25
+.\"TPOPT_CDDATA_CLEAR\fB #\fR
+.\"No associated value.
+.\".IP
+.\"Erase outgoing connect or disconnect data.
+.TP 25
+TPOPT_MY_TSEL\fB \fR
+1-64 bytes.
+.IP
+An "extended" transport selector (tsel) for this socket.
+This option is used to set or get the local tsel.
+When this option is used to set a tsel, 
+the default the 2-byte tsel
+that may have been allocated by \fIbind()\fR
+is retained, but this "extended" tsel is the
+tsel that is transmitted in a connection request
+When this option is used to get a tsel, 
+it will return whatever transport tsel exists;
+if no "extended" tsel was given to this socket,
+the 2-byte tsel is returned.
+.TP 25
+TPOPT_PEER_TSEL\fB \fR
+1-64 bytes.
+.IP
+An "extended" transport selector (tsel) for the
+peer transport entity.
+This option is used to get the peer's tsel after
+a connection is established. 
+When used before a connection
+is established, this option can set the tsel that
+will be transmitted as the "called" tsel
+in a connection request.
+.TP 25
+TPOPT_PERF_MEAS\fB #\fR
+Boolean.
+.IP
+When \fBtrue\fR, performance measurements will be kept
+for this connection.  
+When set before a connection is established, the
+active side will use a locally defined parameter on the
+connect request packet; if the peer is another ARGO
+implementation, this will cause performance measurement to be
+turned on 
+on the passive side as well.
+See \fItpperf(8)\fR.
+.TP 25
+TPOPT_PSTATISTICS\fB\fR
+No associated value on input.
+On output, struct tp_pmeas.
+.IP
+This command is used to read the performance statistics accumulated
+during a connection's lifetime.
+It can only be used with \fIgetsockopt()\fR.
+The structure it returns is described in \fB<netargo/tp_stat.h>\fR.
+See \fItpperf(8)\fR.
+.TP 25
+TPOPT_FLAGS
+unsigned integer. [ 0x0 ]
+.IP
+This command can only be used with \fIgetsockopt()\fR.
+See the description of the flags below.
+.TP 25
+TPOPT_PARAMS\fB\fR
+struct tp_conn_param.
+.IP
+Used to get or set a group parameters for a connection.
+The struct tp_conn_param is the argument used with the
+\fIgetsockopt()\fR or \fIsetsockopt()\fR system call. 
+It is described in 
+\fB<netargo/tp_user.h>\fR.
+.PP
+The fields of the \fItp_conn_param\fR structure are
+described below.
+.nf
+.sp 1
+\fIValues for TPOPT_PARAMS:\fR
+.fi
+.TP 25
+\fBField\fR
+\fBValue [default]\fR
+.IP
+\fBDescription\fR
+.\" ******************8
+.TP 25
+p_Nretrans
+nonzero short integer [ 1 ]
+.IP
+Number of times a TPDU will be retransmitted before the
+local TP entity closes a connection.
+.\" ******************8
+.TP 25
+p_dr_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of disconnect request TPDUs.
+.\" ******************8
+.TP 25
+p_dt_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of data TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_cr_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of connection request TPDUs.
+.\" ******************8
+.TP 25
+p_cc_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of connection confirm TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_x_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of expedited data TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_sendack_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks that the local TP entity
+will wait before sending an acknowledgment for normal data
+(not applicable if the acknowlegement strategy is TPACK_EACH).
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_ref_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks for which a reference will
+be considered frozen after the connection to which
+it applied is closed.
+This parameter applies to classes 4 and 0 in the 
+ARGO implementation, despite the fact that
+the frozen reference function is required only for
+class 4.
+.\" ******************8
+.TP 25
+p_inact_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks without an incoming packet from the peer after which 
+TP close the connection.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_keepalive_ticks
+nonzero short integer [ various ]
+.IP
+nonzero short integer [ various ]
+Number of clock ticks between acknowledgments that are sent
+to keep an inactive connection open (to prevent the peer's
+inactivity control function from closing the connection).
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_winsize
+short integer between 128 and 16384. [4096 bytes]
+.IP
+The buffer space limits in bytes for incoming and outgoing data.
+There is no way to specify different limits for incoming and outgoing
+paths.
+The actual window size at any time
+during the lifetime of a connection
+is a function of the buffer size limit, the negotiated
+maximum TPDU size, and the 
+rate at which the user program receives data.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_tpdusize
+unsigned char between 0x7 and 0xd. 
+[ 0xc for class 4 ] [ 0xb for class 0 ]
+.IP
+Log 2 of the maximum TPDU size to be negotiated.
+The TP standard (ISO 8473) gives an upper bound of 
+0xd for class 4 and 0xb for class 0.
+The ARGO implementation places upper bounds of
+0xc on class 4 and 0xb on class 0.
+.\" ******************8
+.TP 25
+p_ack_strat
+TPACK_EACH or TPACK_WINDOW.  [ TPACK_WINDOW ]
+.IP
+This parameter applies only to class 4.
+Two acknowledgment strategies are supported:
+.IP
+TPACK_EACH means that each data TPDU is acknowledged
+with an AK TPDU.
+.IP
+TPACK_WINDOW
+means that upon receipt of the packet that represents
+the high edge of the last window advertised, and AK TPDU is generated.
+.\" ******************8
+.TP 25
+p_rx_strat
+4 bit mask
+[ TPRX_USE_CW | TPRX_FASTSTART over
+connectionless network protocols ]
+[ TPRX_USE_CW over
+connection-oriented network protocols ]
+.IP
+This parameter applies only to class 4.
+The bit mask may include the following values:
+.IP
+TPRX_EACH: When a retransmission timer expires, retransmit
+each packet in the send window rather than
+just the first unacknowledged packet.
+.IP
+TPRX_USE_CW: Use a "congestion window" strategy borrowed
+from Van Jacobson's congestion window strategy for TCP.
+The congestion window size is set to one whenever
+a retransmission occurs.
+.IP
+TPRX_FASTSTART: Begin sending the maximum amount of data permitted
+by the peer (subject to availability).
+The alternative is to start sending slowly by 
+pretending the peer's window is smaller than it is, and letting
+it slowly grow up to the real peer's window size.
+This is to smooth the effect of new connections on a congested network
+by preventing a transport connection from suddenly 
+overloading the network with a burst of packets.
+This strategy is also due to Van Jacobson.
+.\" ******************8
+.TP 25
+p_class
+5 bit mask
+[ TP_CLASS_4 | TP_CLASS_0 ]
+.IP
+Bit mask including one or both of the values TP_CLASS_4 and TP_CLASS_0.
+The higher class indicated is the preferred class.
+If only one class is indicated, negotiation will not occur
+during connection establishment.
+.\" ******************8
+.TP 25
+p_xtd_format
+Boolean.
+[ false ]
+.IP
+Boolean indicating that extended format shall be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_xpd_service
+Boolean.
+[ true ]
+.IP
+Boolean indicating that 
+the expedited data transport service will be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_use_checksum
+Boolean.
+[ true ]
+.IP
+Boolean indicating the the use of checksums will be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_use_nxpd
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_use_rcc
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_use_efc
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_no_disc_indications
+Boolean.
+[ false ]
+.IP
+Boolean indicating that the local TP entity shall not issue
+indications (signals) when a TP connection is disconnected.
+.\" ******************8
+.TP 25
+p_dont_change_params
+Boolean.
+[ false ]
+.IP
+If \fBtrue\fR the TP entity will not override
+any of the other values given in this structure.
+If the values cannot be used, the TP entity will drop, disconnect,
+or refuse to establish the connection to which this structure pertains.
+.\" ******************8
+.TP 25
+p_netservice
+One of { ISO_CLNS, ISO_CONS, ISO_COSNS, IN_CLNS }.
+[ ISO_CLNS ]
+.IP
+Indicates which network service is to be used.
+.IP
+ISO_CLNS indicates the connectionless network service provided
+by CLNP (ISO 8473).
+.IP
+ISO_CONS indicates the connection-oriented network service provided
+by X.25 (ISO 8208) and ISO 8878.
+.IP
+ISO_COSNS indicates the 
+connectionless network service running over a
+connection-oriented subnetwork service : CLNP (ISO 8473) over X.25 (ISO 8208).
+.IP
+IN_CLNS indicates the 
+DARPA Internet connectionless network service provided by IP (RFC 791).
+.\" ******************8
+.TP 25
+p_dummy
+Reserved for future use.
+.sp 1
+.PP
+The TPOPT_FLAGS option is used for obtaining
+various boolean-valued options.
+Its meaning is as follows.
+The bit numbering used is that of the PC/RT, which means that bit
+0 is the most significant bit, while bit 8 is the least significant bit.
+.nf
+.sp 1
+\fIValues for TPOPT_FLAGS:\fR
+.fi
+.TP 10
+\fBBits\fR
+\fBDescription [Default]\fR
+.TP 10
+0
+TPFLAG_NLQOS_PDN : set when the quality of the 
+network service is
+similar to that of a public data network.
+.TP 10
+1
+TPFLAG_PEER_ON_SAMENET : set when the peer TP entity
+is considered to be on the same network as the local
+TP entity.
+.TP 10
+2
+Not used.
+.TP 10
+3
+TPFLAG_XPD_PRES : set when expedited data are present
+[ 0 ]
+.TP 10
+4..7
+Reserved.
+.\".TP 10
+.\"4
+.\"Reserved.
+.\".TP 10
+.\"5
+.\"TPFLAG_DISC_DATA_IN : read only flag, if set indicates that
+.\"data from a disconnect TPDU are present.
+.\".TP 10
+.\"6
+.\"Reserved.
+.\".TP 10
+.\"7
+.\"TPFLAG_CONN_DATA_IN : read only flag, if set indicates that
+.\"data from a connect TPDU are present.
+.SH "LIBRARIES
+.PP
+The new system calls \fIrecvv\fR and \fIsendv\fR are supported by a
+library, \fIlibtp.a\fR (rather than a modified C library).  
+Also in this
+library are new optional interfaces to the \fIconnect\fR and \fIaccept\fR
+system calls.  See LIBTP(3).
+.SH FILES
+.PP
+The following files in have entries necessary for the correct operation
+of the TP utilities.
+.nf
+\fC
+	/etc/isodir
+	/etc/protocols
+\fR
+.fi
+.PP
+The symbolic link is needed for users to write programs using IPC
+with TP:
+.nf
+\fC
+	/usr/include/netargo@  ->  /sys/netargo
+\fR
+.fi
+.PP
+The following utilities have changed:
+.nf
+	netstat
+	ifconfig
+	config
+.fi
+.PP
+The following are new utilities and daemons:
+.nf
+	isoroute
+	rlogin.iso, rcp.iso, rsh.iso, isod, rlogind
+	tpdiscard
+	tpping
+	tppt (for maintenance and debugging)
+	bark (for maintenance and debugging)
+	tpfileget, tpfileput (for debugging)
+	tpstat, tpmon
+	tpset
+	tppkt
+	viid
+.fi
+.PP
+In the kernel source, many files have changed or been added.
+For a list of these, see the installation guide,
+"Installing Wisconsin ARGO 1.0 on Academic Operating System 4.3
+Release 2".
+.SH "ERROR VALUES
+.PP
+The TP entity returns \fIerrno\fR error values as defined in
+\fB<sys/errno.h>\fR
+and
+\fB<netargo/iso_errno.h>\fR.
+User programs may print messages associated with these value by
+using an expanded version of \fIperror()\fR
+found in the ISO library, \fIlibisodir.a\fR.
+.PP
+If the TP entity encounters asynchronous events
+that will cause a transport connection to be closed,
+such as
+timing out while retransmitting a connect request TPDU,
+or receiving a DR TPDU,
+the TP entity issues a SIGURG signal, indicating that
+disconnection has occurred.
+If the signal is issued during a 
+a system call, the system call may be interrupted,
+in which case the
+\fIerrno\fR value upon return from the system call is EINTR.
+If the signal SIGURG
+is being handled by reading
+from the socket, and it was a \fIaccept()\fR that
+timed out, the read may result in ENOTSOCK,
+because the \fIaccept()\fR call had not yet returned a
+legitimate socket descriptor when the signal was handled.
+ETIMEDOUT (or a some other errno value appropriate to the
+type of error) is returned if SIGURG is blocked
+for the duration of the system call.
+A user program should take one of the following approaches:
+.IP "Block SIGURG." 5
+If the program is servicing
+only one connection, it can block or ignore SIGURG during connection 
+establishment.
+The advantage of this is that the \fIerrno\fR value
+returned is somewhat meaningful.
+The disadvantage of this is that
+if ignored, disconnection and expedited data indications could be
+missed.
+For some programs this is not a problem.
+.IP "Handle SIGURG." 5
+If the program is servicing more than one connection at a time
+or expedited data may arrive or both, the program must
+service SIGURG.
+It can use the \fIgetsockopt(...TPOPT_FLAGS...)\fR system 
+call to see if the signal
+was due to the arrival of expedited data or due to a disconnection.
+In the latter case, 
+\fIgetsockopt()\fR
+will return ENOTCONN.
+.SH BUGS
+.PP
+When running TP over the token ring, if checksumming
+is NOT used, the TP entity sents packets to the lan driver faster than
+the driver can reasonably handle them.
+A bug in the lan driver causes it to reorder the packets in this
+situation, causing an overall degradation of TP performance.
+In general, this is not a problem because very few applications
+will actually be able to send packets this fast.
+Nevertheless,
+in order to prevent this reordering, 
+one may induce a delay in the TP entity by setting the 1-byte
+value
+\fItp_delay\fR
+to 1
+using the debugger.
+Hit the <pause> key, then
+type \fB/b tp_delay\fR followed by the <enter key>.
+The debugger will print the value 00.  
+You then type \fB1\fR followed by the <enter key>.
+Then type \fBend\fR <enter key>.
+Then type \fBgo\fR <enter key>.
+.SH SEE ALSO
+.PP
+tcp(4P), sendv(2), recvv(2), libtp(3),
+isodir(3), isodir(5), netstat(1),
+iso(4F), clnp(4P), viid(8)
+tppt(8), tpstat(8), bark(8), tppkt(8), tpset(8), tpperf(8)
+isoroute(8), ifconfig(8), isod(8), rlogin.iso(1),
+"Installing Wisconsin ARGO 1.0 on Academic Operating System 4.3
+Release 2",
+"ARGO 1.0 Kernel Programmer's Manual"