summaryrefslogtreecommitdiff
path: root/share/man
diff options
context:
space:
mode:
authorJason McIntyre <jmc@cvs.openbsd.org>2004-07-15 23:25:07 +0000
committerJason McIntyre <jmc@cvs.openbsd.org>2004-07-15 23:25:07 +0000
commit256a382eaf7f8963beace5967407b17c0b55f9d3 (patch)
tree742c031dc48a17e0771426326bb6b57208d798e9 /share/man
parentef6c2c98d54b454383df18e29316fbbaf9b3bda6 (diff)
remove after iso removal;
ok henning@
Diffstat (limited to 'share/man')
-rw-r--r--share/man/man4/clnp.4150
-rw-r--r--share/man/man4/cltp.4124
-rw-r--r--share/man/man4/esis.4214
-rw-r--r--share/man/man4/iso.4184
-rw-r--r--share/man/man4/tp.4721
5 files changed, 0 insertions, 1393 deletions
diff --git a/share/man/man4/clnp.4 b/share/man/man4/clnp.4
deleted file mode 100644
index 0af667f0103..00000000000
--- a/share/man/man4/clnp.4
+++ /dev/null
@@ -1,150 +0,0 @@
-.\" $OpenBSD: clnp.4,v 1.8 2003/06/02 23:30:12 millert Exp $
-.\" $NetBSD: clnp.4,v 1.4 1994/11/30 16:22:07 jtc Exp $
-.\"
-.\" Copyright (c) 1990, 1991, 1993
-.\" The Regents of the University of California. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\" may be used to endorse or promote products derived from this software
-.\" without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" @(#)clnp.4 8.2 (Berkeley) 4/2/94
-.\"
-.Dd April 2, 1994
-.Dt CLNP 4
-.Os
-.Sh NAME
-.Nm clnp
-.Nd Connectionless-Mode Network Protocol
-.Sh SYNOPSIS
-.Fd #include <sys/socket.h>
-.Fd #include <netiso/iso.h>
-.Fd #include <netiso/clnp.h>
-.Ft int
-.Fn 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
-.Dq raw socket
-for debugging purposes only.
-CLNP sockets are connectionless, and are normally used with the
-.Xr sendto 2
-and
-.Xr recvfrom 2
-calls, though the
-.Xr connect 2
-call may also be used to fix the destination for future
-packets (in which case the
-.Xr read 2
-or
-.Xr recv 2
-and
-.Xr write 2
-or
-.Xr 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
-.Xr setsockopt 2
-options apply to CLNP:
-.Bl -tag -width CLNPOPT_FLAGS
-.It Dv CLNPOPT_FLAGS
-Sets the flags which are passed to clnp when sending a datagram.
-Valid flags are:
-.Pp
-.Bl -tag -width "CLNP_NO_CKSUM" -offset indent -compact
-.It Dv CLNP_NO_SEG
-Do not allow segmentation.
-.It Dv CLNP_NO_ER
-Suppress ER pdus.
-.It Dv CLNP_NO_CKSUM
-Do not generate the CLNP checksum.
-.El
-.Pp
-.It Dv CLNPOPT_OPTS
-Sets CLNP options.
-The options must be formatted exactly as specified by ISO 8473, section 7.5.
-.Dq Options Part.
-Once an option has been set, it will be sent on all packets until
-a different option is set.
-.El
-.Sh CONGESTION EXPERIENCE BIT
-Whenever a packet is transmitted, the globally unique quality of
-service option is added to the packet.
-The sequencing preferred bit and the low transit delay bit are set in
-this option.
-.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
-.Em congest_threshold ,
-then the congestion experienced bit is set in the quality of service option.
-.Pp
-The threshold value stored in
-.Em congest_threshold
-may be tuned.
-.Pp
-When a packet is received with the
-globally unique quality of service option present, and the
-congestion experienced bit is set, then the transport congestion
-control function is called.
-.Sh DIAGNOSTICS
-A socket operation may fail with one of the following errors returned:
-.Bl -tag -width [EADDRNOTAVAIL]
-.It Bq Er 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;
-.It Bq Er ENOTCONN
-When trying to send a datagram, but
-no destination address is specified, and the socket hasn't been
-connected;
-.It Bq Er ENOBUFS
-When the system runs out of memory for
-an internal data structure;
-.It Bq Er EADDRNOTAVAIL
-When an attempt is made to create a
-socket with a network address for which no network interface
-exists;
-.It Bq Er EHOSTUNREACH
-When trying to send a datagram, but no route to the destination
-address exists.
-.It Bq Er EINVAL
-When specifying unsupported options.
-.El
-.Sh SEE ALSO
-.Xr recv 2 ,
-.Xr send 2 ,
-.Xr iso 4 ,
-.Xr netintro 4
-.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
-.Dv MLEN
-bytes of options can be specified.
diff --git a/share/man/man4/cltp.4 b/share/man/man4/cltp.4
deleted file mode 100644
index d368d1b5c03..00000000000
--- a/share/man/man4/cltp.4
+++ /dev/null
@@ -1,124 +0,0 @@
-.\" $OpenBSD: cltp.4,v 1.8 2003/06/02 23:30:12 millert Exp $
-.\" $NetBSD: cltp.4,v 1.3 1994/11/30 16:22:08 jtc Exp $
-.\"
-.\" Copyright (c) 1990, 1991, 1993
-.\" The Regents of the University of California. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\" may be used to endorse or promote products derived from this software
-.\" without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" @(#)cltp.4 8.1 (Berkeley) 6/9/93
-.\"
-.Dd June 9, 1993
-.Dt CLTP 4
-.Os
-.Sh NAME
-.Nm cltp
-.Nd ISO Connectionless Transport Protocol
-.Sh SYNOPSIS
-.Fd #include <sys/socket.h>
-.Fd #include <netiso/iso.h>
-.Ft int
-.Fn socket AF_ISO SOCK_DGRAM 0
-.Sh DESCRIPTION
-.Tn CLTP
-is a simple, unreliable datagram protocol which is accessed
-via the
-.Dv SOCK_DGRAM
-abstraction for the
-.Tn ISO
-protocol family.
-.Tn CLTP
-sockets are connectionless, and are
-normally used with the
-.Xr sendto 2
-and
-.Xr recvfrom 2
-calls, though the
-.Xr connect 2
-call may also be used to fix the destination for future
-packets (in which case the
-.Xr recv 2
-or
-.Xr read 2
-and
-.Xr send 2
-or
-.Xr write 2
-system calls may be used).
-.Pp
-.Tn CLTP
-address formats are identical to those used by TP.
-In particular
-.Tn CLTP
-provides a service selector in addition
-to the normal
-.Tn ISO NSAP .
-Note that the
-.Tn CLTP
-selector
-space is separate from the TP selector space (i.e. a
-.Tn CLTP
-selector
-may not be
-.Dq connected
-to a TP selector).
-.Pp
-Options at the
-.Tn CLNP
-network level may be used with
-.Tn CLTP ;
-see
-.Xr clnp 4 .
-.Sh DIAGNOSTICS
-A socket operation may fail with one of the following errors returned:
-.Bl -tag -width [EADDRNOTAVAIL]
-.It Bq Er 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;
-.It Bq Er ENOTCONN
-when trying to send a datagram, but
-no destination address is specified, and the socket hasn't been
-connected;
-.It Bq Er ENOBUFS
-when the system runs out of memory for
-an internal data structure;
-.It Bq Er EADDRINUSE
-when an attempt
-is made to create a socket with a selector which has already been
-allocated;
-.It Bq Er EADDRNOTAVAIL
-when an attempt is made to create a
-socket with a network address for which no network interface
-exists.
-.El
-.Sh SEE ALSO
-.Xr getsockopt 2 ,
-.Xr recv 2 ,
-.Xr send 2 ,
-.Xr socket 2 ,
-.Xr clnp 4 ,
-.Xr iso 4 ,
-.Xr netintro 4
diff --git a/share/man/man4/esis.4 b/share/man/man4/esis.4
deleted file mode 100644
index 10cf7f33a3c..00000000000
--- a/share/man/man4/esis.4
+++ /dev/null
@@ -1,214 +0,0 @@
-.\" $OpenBSD: esis.4,v 1.10 2004/03/21 19:47:59 miod Exp $
-.\" $NetBSD: esis.4,v 1.3 1994/11/30 16:22:12 jtc Exp $
-.\"
-.\" Copyright (c) 1990, 1991, 1993
-.\" The Regents of the University of California. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\" may be used to endorse or promote products derived from this software
-.\" without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" @(#)esis.4 8.2 (Berkeley) 11/30/93
-.\"
-.Dd November 30, 1993
-.Dt ESIS 4
-.Os
-.Sh NAME
-.Nm ES-IS
-.Nd End System to Intermediate System Routing Protocol
-.Sh SYNOPSIS
-.Cd "pseudo-device ether" Op Ar count
-.Sh DESCRIPTION
-The
-.Nm ES-IS
-routing protocol is used to dynamically map between
-.Tn ISO NSAP
-addresses and
-.Tn ISO SNPA
-addresses; to permit End and Intermediate Systems
-to learn of each other's existence; and to allow Intermediate Systems
-to inform End Systems of (potentially) better routes to use when
-forwarding
-.Tn NPDU Ns s
-to a particular destination.
-.Pp
-The mapping between
-.Tn NSAP
-addresses and
-.Tn SNPA
-addresses is accomplished by
-transmitting hello
-.Tn PDU Ns s
-between the cooperating Systems.
-These
-.Tn PDU Ns s
-are transmitted whenever the
-.Em configuration
-timer expires.
-When a hello
-.Tn PDU
-is received, the
-.Tn SNPA
-address that it conveys is stored in the routing table for as long as the
-.Em holding time
-in the
-.Tn PDU
-suggests.
-The default
-.Em holding time
-(120 seconds) placed in the hello
-.Tn PDU ,
-the configuration timer value,
-and the system type (End System or Intermediate System) may be changed by
-issuing an
-.Dv SIOCSSTYPE
-.Xr ioctl 2 ,
-which is defined in
-.Pa /sys/netiso/iso_snpac.h .
-.Pp
-The protocol behaves differently depending on whether the System is
-configured as an End System or an Intermediate System.
-.Sh END SYSTEM OPERATION
-When an interface requests a mapping for an address not in the cache,
-the
-.Tn SNPA
-of any known Intermediate System is returned.
-If an Intermediate System is not known, then the
-.Em all end systems
-multicast address
-is returned.
-It is assumed that the intended recipient of the NPDU will immediately
-transmit a hello
-.Tn PDU
-back to the originator of the
-.Tn NPDU .
-.Pp
-If an
-.Tn NPDU
-is forwarded by the End System, a redirect
-.Tn PDU
-will not be
-generated.
-However, redirect
-.Tn PDU Ns s
-received will be processed.
-This processing consists of adding an entry in the routing table.
-If the redirect is towards an Intermediate System, then an entry is
-made in the routing table as well.
-The entry in the routing table will mark the
-.Tn NSAP
-address contained in the redirect
-.Tn PDU
-as the gateway for the destination
-system (if an NET is supplied), or will create a route with
-the NSAP address as the
-destination and the
-.Tn SNPA
-address (embodied as a link-level sockaddr) as the
-gateway.
-.Pp
-If the System is configured as an End System, it will report all the
-.Tn NSAP Ns s
-that have been configured using the ifconfig command, and no others.
-It is possible to have more than one
-.Tn NSAP
-assigned to a given interface,
-and it is also possible to have the same
-.Tn NSAP
-assigned to multiple
-interfaces.
-However, any
-.Tn NSAP
-containing an NSEL that is consistent with the
-nsellength option (default one) of any interface will be accepted as
-an
-.Tn NSAP
-for this System.
-.Sh INTERMEDIATE SYSTEM OPERATION
-When an interface requests a mapping for an address not in the routing table,
-an error is returned.
-.Pp
-When an
-.Tn NPDU
-is forwarded out on the same interface that the
-.Tn NPDU
-arrived upon,
-a redirect
-.Tn PDU
-is generated.
-.Sh MANUAL ROUTING TABLE MODIFICATION
-To facilitate communications with systems which do not use
-.Nm ES-IS ,
-one may add a route whose destination is a sockaddr_iso containing
-the
-.Tn NSAP
-in question, and the gateway being a link-level sockaddr,
-either by writing a special purpose program, or using the
-.Xr route 8
-command e.g.:
-.Bd -literal
-route add -iface -osi 49.0.4.8.0.2b.b.83.bf -link qe0:8.0.2b.b.83.bf
-.Ed
-.Pp
-If the
-System is configured as an End System and has a single network interface
-which does not support multicast reception,
-it is necessary to manually configure the location of an
-.Tn IS ,
-using the route command in a similar way.
-There, the destination address should be
-.Dq default
-(spelled
-out literally as 7
-.Tn ASCII
-characters), and the gateway should be
-once again be a link-level sockaddr specifying the
-.Tn SNPA
-of the
-.Tn IS .
-.Sh SEE ALSO
-.Xr iso 4 ,
-.Xr ifconfig 8 ,
-.Xr route 8
-.Rs
-.%T "End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service"
-.%R ISO
-.%N 9542
-.Re
-.Sh BUGS
-Redirect
-.Tn PDU Ns s
-do not contain options from the forwarded
-.Tn NPDU
-which generated
-the redirect.
-The multicast address used on the 802.3 network is taken from the
-.Tn NBS
-December 1987 agreements.
-This multicast address is not compatible with the 802.5 (Token Ring)
-multicast addresses format.
-Therefore, broadcast addresses are used on the 802.5 subnetwork.
-Researchers at the University of Wisconsin are constructing an implementation
-of the
-.Tn IS-IS
-routing protocol.
diff --git a/share/man/man4/iso.4 b/share/man/man4/iso.4
deleted file mode 100644
index ae2b220704c..00000000000
--- a/share/man/man4/iso.4
+++ /dev/null
@@ -1,184 +0,0 @@
-.\" $OpenBSD: iso.4,v 1.11 2003/06/02 23:30:12 millert Exp $
-.\" $NetBSD: iso.4,v 1.3 1994/11/30 16:22:20 jtc Exp $
-.\"
-.\" Copyright (c) 1990, 1991, 1993
-.\" The Regents of the University of California. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\" may be used to endorse or promote products derived from this software
-.\" without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" @(#)iso.4 8.2 (Berkeley) 11/30/93
-.\"
-.Dd November 30, 1993
-.Dt ISO 4
-.Os
-.Sh NAME
-.Nm iso
-.Nd ISO protocol family
-.Sh SYNOPSIS
-.Fd #include <sys/types.h>
-.Fd #include <netiso/iso.h>
-.Sh DESCRIPTION
-The
-.Tn ISO
-protocol family is a collection of protocols
-that uses the
-.Tn ISO
-address format.
-The
-.Tn ISO
-family provides protocol support for the
-.Dv SOCK_SEQPACKET
-abstraction through the
-.Tn TP
-protocol
-.Pf ( Tn ISO
-8073),
-for the
-.Dv SOCK_DGRAM
-abstraction through the connectionless transport
-protocol
-.Pf ( Tn ISO
-8602),
-and for the
-.Dv SOCK_RAW
-abstraction
-by providing direct access (for debugging) to the
-.Tn CLNP
-.Pf ( Tn ISO
-8473) network layer protocol.
-.Sh ADDRESSING
-.Tn ISO
-addresses are based upon
-.Tn ISO
-8348/AD2,
-.Rs
-.%T "Addendum to the Network Service Definition Covering Network Layer Addressing"
-.Re
-.Pp
-Sockets bound to the OSI protocol family use
-the following address structure:
-.Bd -literal
-struct iso_addr {
- u_char isoa_len; /* length, not including this byte */
- char isoa_genaddr[20]; /* general opaque address */
-};
-
-struct sockaddr_iso {
- u_char siso_len; /* size of this sockaddr */
- u_char siso_family; /* addressing domain, AF_ISO */
- u_char siso_plen; /* presentation selector length */
- u_char siso_slen; /* session selector length */
- u_char siso_tlen; /* transport selector length */
- struct iso_addr siso_addr; /* network address */
- u_char siso_pad[6]; /* space for gosip v2 SELs */
-};
-#define siso_nlen siso_addr.isoa_len
-#define siso_data siso_addr.isoa_genaddr
-.Ed
-.Pp
-The fields of this structure are:
-.Bl -tag -width Ds
-.It Ar siso_len :
-Length of the entire address structure, in bytes, which may grow to
-be longer than the 32 bytes shown above.
-.It Ar siso_family :
-Identifies the domain:
-.Dv AF_ISO .
-.It Ar siso_tlen :
-Length of the transport selector.
-.It Ar siso_slen :
-Length of the session selector.
-This is not currently supported by the kernel and is provided as
-a convenience for user level programs.
-.It Ar siso_plen :
-Length of the presentation selector.
-This is not currently supported by the kernel and is provided as
-a convenience for user level programs.
-.It Ar siso_addr :
-The network part of the address, described below.
-.El
-.Sh TRANSPORT ADDRESSING
-An
-.Tn 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
-.Em port .
-In the
-.Tn ISO
-domain, this is called a
-.Em transport selector
-(also known at one time as a
-.Em transport suffix ) .
-While ports are always 16 bits,
-transport selectors may be
-of (almost) arbitrary size.
-.Pp
-Since the C language does not provide convenient variable
-length structures, we have separated the selector lengths
-from the data themselves.
-The network address and various selectors are stored contiguously,
-with the network address first, then the transport selector, and so
-on.
-Thus, if you had a network address of less than 20 bytes,
-the transport selector would encroach on space normally reserved
-for the network address.
-.Sh NETWORK ADDRESSING
-.Tn ISO
-network addresses are limited to 20 bytes in length.
-.Tn ISO
-network addresses can take any format.
-.Sh PROTOCOLS
-The
-.Tn ARGO
-1.0 implementation of the
-.Tn ISO
-protocol family comprises
-the Connectionless-Mode Network Protocol
-.Pq Tn CLNP ,
-and the Transport Protocol
-.Pq Tn TP ,
-classes 4 and 0,
-and
-.Tn X.25 .
-.Tn TP
-is used to support the
-.Dv SOCK_SEQPACKET
-abstraction.
-A raw interface to
-.Tn CLNP
-is available
-by creating an
-.Tn ISO
-socket of type
-.Dv SOCK_RAW .
-This is used for
-.Tn CLNP
-debugging only.
-.Sh SEE ALSO
-.Xr clnp 4 ,
-.Xr cltp 4 ,
-.Xr tp 4
diff --git a/share/man/man4/tp.4 b/share/man/man4/tp.4
deleted file mode 100644
index 9d9c390ce90..00000000000
--- a/share/man/man4/tp.4
+++ /dev/null
@@ -1,721 +0,0 @@
-.\" $OpenBSD: tp.4,v 1.21 2003/06/06 10:29:41 jmc Exp $
-.\" $NetBSD: tp.4,v 1.4 1994/11/30 16:22:38 jtc Exp $
-.\"
-.\" Copyright (c) 1990, 1991, 1993
-.\" The Regents of the University of California. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\" may be used to endorse or promote products derived from this software
-.\" without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" @(#)tp.4 8.4 (Berkeley) 4/19/94
-.\"
-.Dd April 19, 1994
-.Dt TP 4
-.Os
-.Sh NAME
-.Nm tp
-.Nd ISO Transport Protocol
-.Sh SYNOPSIS
-.Fd #include <sys/socket.h>
-.Fd #include <netiso/iso_errno.h>
-.Fd #include <netiso/tp_param.h>
-.Fd #include <netiso/tp_user.h>
-.Ft int
-.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0
-.Sh DESCRIPTION
-The
-.Tn TP
-protocol provides reliable, flow-controlled, two-way
-transmission of data and record boundaries.
-It is a byte-stream protocol and is accessed according to
-the
-.Dv SOCK_SEQPACKET
-abstraction.
-The
-.Tn TP
-protocol makes use of a standard
-.Tn ISO
-address format,
-including a Network Service Access Point, and a Transport Service Entity
-Selector.
-Subclass 4 may make use of the
-Internet address format.
-.Pp
-Sockets utilizing the tp protocol are either
-.Dq active
-or
-.Dq passive .
-Active sockets initiate connections to passive
-sockets.
-By default
-.Tn TCP
-sockets are created active; to create a
-passive socket the
-.Xr listen 2
-system call must be used
-after binding the socket with the
-.Xr bind 2
-system call.
-Only passive sockets may use the
-.Xr accept 2
-call to accept incoming connections.
-Only active sockets may use the
-.Xr connect 2
-call to initiate connections.
-.Pp
-Passive sockets may
-.Dq underspecify
-their location to match
-incoming connection requests from multiple networks.
-This technique, termed
-.Dq wildcard addressing ,
-allows a single
-server to provide service to clients on multiple networks.
-To create a socket which listens on all networks, the
-.Tn NSAP
-portion
-of the bound address must be void (of length zero).
-The Transport Selector may still be specified
-at this time; if the port is not specified the system will assign one.
-Once a connection has been established the socket's address is
-fixed by the peer entity's location.
-The address assigned the socket is the address associated with
-the network interface through which packets are being transmitted
-and received.
-.Pp
-The
-.Tn ISO
-Transport Protocol implemented for
-.Tn AOS R2
-at the University of Wisconsin - Madison,
-and modified for inclusion in the Berkeley Software Distribution,
-includes classes 0 and 4
-of the
-.Tn ISO
-transport protocols
-as specified in
-the June 1986 version of
-.Tn IS
-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
-.Tn ISO
-domain.
-Class 4 may be used in the Internet domain as well as in the
-.Tn ISO
-domain.
-.Pp
-Two system calls were modified from the previous
-release of the Berkeley Software Distribution
-to permit the support of the end-of-transport-service-data-unit
-.Pq Dv EOTSDU
-indication, and for the receipt and transmission of user
-connect, confirm, and disconnect data.
-See
-.Xr sendmsg 2
-and
-.Xr recvmsg 2 ,
-and further discussion
-below for the formats of the data in the ancillary data buffer.
-If the
-.Dv EOTSDU
-is not needed, the normal
-.Xr read 2 ,
-and
-.Xr write 2
-system calls may be used.
-.Pp
-Through the
-.Xr getsockopt 2
-and
-.Xr setsockopt 2
-system calls,
-.Tn TP
-supports several options
-to control such things as negotiable options
-in the protocol and protocol strategies.
-The options are defined in
-.Aq Pa netiso/tp_user.h ,
-and are described below.
-.Pp
-In the tables below,
-the options marked with a pound sign
-.Ql \&#
-may be used
-with
-.Xr setsockopt 2
-after a connection is established.
-Others must be used before the connection
-is established, in other words,
-before calling
-.Xr connect 2
-or
-.Xr accept 2 .
-All options may be used
-with
-.Xr getsockopt 2
-before or
-after a connection is established.
-.Bl -tag -width TPOPT_PSTATISTICS
-.It Dv TPOPT_CONN_DATA
-(char *) [none]
-.br
-Data to send on
-.Xr connect 2 .
-The passive user may issue a
-.Xr getsockopt 2
-call to retrieve a connection request's user data,
-after having done the
-.Xr accept 2
-system call without implying confirmation of the connection.
-.Pp
-The data may also be retrieved by issuing a
-.Xr recvmsg 2
-request for ancillary data only,
-without implying confirmation of the connection.
-The returned
-.Va cmsghdr
-will contain
-.Dv SOL_TRANSPORT
-for the
-.Va csmg_level
-and
-.Dv TPOPT_CONN_DATA
-for
-.Va cmsg_type .
-.It Dv TPOPT_DISC_DATA \&#
-(char *) [none]
-.br
-Data to send on
-.Xr close 2 .
-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
-.Xr close 2 .
-This may be sent by a
-.Xr setsockopt 2
-system call, or by issuing a
-.Xr sendmsg 2
-request specifying ancillary data only.
-The user-provided
-.Va cmsghdr
-must contain
-.Dv SOL_TRANSPORT
-for
-.Va csmg_level
-and
-.Dv TPOPT_DISC_DATA
-for
-.Va cmsg_type .
-Sending of disconnect data will in of itself tear down (or reject)
-the connection.
-.It Dv TPOPT_CFRM_DATA \&#
-(char *) [none]
-.br
-Data to send when confirming a connection.
-This may also be sent by a
-.Xr setsockopt 2
-system call, or by issuing a
-.Xr sendmsg 2
-request, as above.
-Sending of connect confirm data will cause the connection
-to be confirmed rather than rejected.
-.It Dv TPOPT_PERF_MEAS \&#
-Boolean.
-.br
-When true, 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
-.Tn ARGO
-implementation, this will cause performance measurement to be
-turned
-on the passive side as well.
-.\" See
-.\" .Xr tpperf 8 .
-.It Dv TPOPT_PSTATISTICS
-No associated value on input.
-On output,
-.Ar struct tp_pmeas .
-.Pp
-This command is used to read the performance statistics accumulated
-during a connection's lifetime.
-It can only be used with
-.Xr getsockopt 2 .
-The structure it returns is described in
-.Aq Pa netiso/tp_stat.h .
-.\" See
-.\" .Xr tpperf 8 .
-.It Dv TPOPT_FLAGS
-unsigned integer.
-[0x0]
-.br
-This command can only be used with
-.Xr getsockopt 2 .
-See the description of the flags below.
-.It Dv TPOPT_PARAMS
-.Ar struct tp_conn_param
-.br
-Used to get or set group parameters for a connection.
-The
-.Ar struct tp_conn_param
-is the argument used with the
-.Xr getsockopt 2
-or
-.Xr setsockopt 2
-system call.
-It is described in
-.Aq Pa netiso/tp_user.h .
-.Pp
-The fields of the
-.Ar tp_conn_param
-structure are
-described below.
-.El
-.Pp
-.Em Values for TPOPT_PARAMS :
-.Bl -tag -width p_sendack_ticks
-.It Ar p_Nretrans
-nonzero short integer [1]
-.br
-Number of times a TPDU
-will be retransmitted before the
-local TP entity closes a connection.
-.It Ar p_dr_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks between retransmissions of disconnect request
-TPDUs.
-.It Ar p_dt_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks between retransmissions of data
-TPDUs.
-This parameter applies only to class 4.
-.It Ar p_cr_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks between retransmissions of connection request
-TPDUs.
-.It Ar p_cc_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks between retransmissions of connection confirm
-TPDUs.
-This parameter applies only to class 4.
-.It Ar p_x_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks between retransmissions of expedited data
-TPDUs.
-This parameter applies only to class 4.
-.It Ar p_sendack_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks that the local TP entity
-will wait before sending an acknowledgment for normal data
-(not applicable if the acknowledgement strategy is
-.Dv TPACK_EACH ) .
-This parameter applies only to class 4.
-.It Ar p_ref_ticks
-nonzero short integer [various]
-.br
-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
-.Tn ARGO
-implementation, despite the fact that
-the frozen reference function is required only for
-class 4.
-.It Ar p_inact_ticks
-nonzero short integer [various]
-.br
-Number of clock ticks without an incoming packet from the peer after which
-.Tn TP
-close the connection.
-This parameter applies only to class 4.
-.It Ar p_keepalive_ticks
-nonzero short integer [various]
-.br
-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.
-.It Ar p_winsize
-short integer between 128 and 16384.
-[4096 bytes]
-.br
-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.
-.It Ar p_tpdusize
-unsigned char between 0x7 and 0xd.
-[0xc for class 4] [0xb for class 0]
-.br
-Log 2 of the maximum TPDU size to be negotiated.
-The
-.Tn TP
-standard
-.Pf ( Tn ISO
-8473) gives an upper bound of
-0xd for class 4 and 0xb for class 0.
-The
-.Tn ARGO
-implementation places upper bounds of
-0xc on class 4 and 0xb on class 0.
-.It Ar p_ack_strat
-.Dv TPACK_EACH
-or
-.Dv TPACK_WINDOW .
-.Bq Dv TPACK_WINDOW
-.br
-This parameter applies only to class 4.
-Two acknowledgment strategies are supported:
-.Pp
-.Dv TPACK_EACH means that each data TPDU
-is acknowledged
-with an AK TPDU.
-.Pp
-.Dv TPACK_WINDOW
-means that upon receipt of the packet that represents
-the high edge of the last window advertised, an AK TPDU is generated.
-.It Ar p_rx_strat
-4 bit mask
-.Bq Dv TPRX_USE_CW No \&|\ Dv TPRX_FASTSTART
-over
-connectionless network protocols]
-.Pf [ Dv TPRX_USE_CW
-over
-connection-oriented network protocols]
-.br
-This parameter applies only to class 4.
-The bit mask may include the following values:
-.Pp
-.Dv TPRX_EACH :
-When a retransmission timer expires, retransmit
-each packet in the send window rather than
-just the first unacknowledged packet.
-.Pp
-.Dv 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.
-.Pp
-.Dv 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 peer window's real 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.
-.It Ar p_class
-5 bit mask
-.Bq Dv TP_CLASS_4 No \&|\ Dv TP_CLASS_0
-.br
-Bit mask including one or both of the values
-.Dv TP_CLASS_4
-and
-.Dv TP_CLASS_0 .
-The higher class indicated is the preferred class.
-If only one class is indicated, negotiation will not occur
-during connection establishment.
-.It Ar p_xtd_format
-Boolean.
-[false]
-.br
-Boolean indicating that extended format is negotiated.
-This parameter applies only to class 4.
-.It Ar p_xpd_service
-Boolean.
-[true]
-.br
-Boolean indicating that
-the expedited data transport service will be negotiated.
-This parameter applies only to class 4.
-.It Ar p_use_checksum
-Boolean.
-[true]
-.br
-Boolean indicating the use of checksums will be negotiated.
-This parameter applies only to class 4.
-.It Ar p_use_nxpd
-Reserved for future use.
-.It Ar p_use_rcc
-Reserved for future use.
-.It Ar p_use_efc
-Reserved for future use.
-.It Ar p_no_disc_indications
-Boolean.
-[false]
-.Pp
-Boolean indicating that the local
-.Tn TP
-entity will not issue
-indications (signals) when a
-.Tn TP
-connection is disconnected.
-.It Ar p_dont_change_params
-Boolean.
-[false]
-.br
-If
-.Em true
-the
-.Tn TP
-entity will not override
-any of the other values given in this structure.
-If the values cannot be used, the
-.Tn TP
-entity will drop, disconnect,
-or refuse to establish the connection to which this structure pertains.
-.It Ar p_netservice
-One of {
-.Dv ISO_CLNS ,
-.Dv ISO_CONS ,
-.Dv ISO_COSNS ,
-.Dv IN_CLNS } .
-.Pf [ Dv ISO_CLNS ]
-.br
-Indicates which network service is to be used.
-.Pp
-.Dv ISO_CLNS
-indicates the connectionless network service provided
-by CLNP
-.Pf ( Tn ISO
-8473).
-.Pp
-.Dv ISO_CONS
-indicates the connection-oriented network service provided
-by X.25
-.Pf ( Tn ISO
-8208) and
-.Tn ISO
-8878.
-.Pp
-.Dv ISO_COSNS
-indicates the
-connectionless network service running over a
-connection-oriented subnetwork service: CLNP
-.Pf ( Tn ISO
-8473) over X.25
-.Pf ( Tn ISO
-8208).
-.Pp
-.Dv IN_CLNS
-indicates the
-DARPA Internet connectionless network service provided by IP (RFC 791).
-.It Ar p_dummy
-Reserved for future use.
-.El
-.Pp
-The
-.Dv TPOPT_FLAGS
-option is used for obtaining
-various boolean-valued options.
-Its meaning is as follows.
-The bit numbering used is that of the RT PC, which means that bit
-0 is the most significant bit, while bit 8 is the least significant bit.
-.sp 1
-.Em Values for TPOPT_FLAGS :
-.Bl -tag -width Bitsx
-.It Sy Bits
-.Sy Description [Default]
-.It \&0
-.Dv TPFLAG_NLQOS_PDN :
-set when the quality of the
-network service is
-similar to that of a public data network.
-.It \&1
-.Dv TPFLAG_PEER_ON_SAMENET :
-set when the peer
-.Tn TP
-entity
-is considered to be on the same network as the local
-.Tn TP
-entity.
-.It \&2
-Not used.
-.It \&3
-.Dv TPFLAG_XPD_PRES :
-set when expedited data are present.
-[0]
-.It 4\&..7
-Reserved.
-.El
-.Sh ERRORS
-The
-.Tn TP
-entity returns
-.Va errno
-error values as defined in
-.Aq Pa sys/errno.h
-and
-.Aq Pa netiso/iso_errno.h .
-.\" User programs may print messages associated with these value by
-.\" using an expanded version of
-.\" .Xr perror 3
-.\" found in the
-.\" .Tn ISO
-.\" library,
-.\" .Pa libisodir.a .
-.br
-.Pp
-If the
-.Tn 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
-.Tn TP
-entity issues a
-.Dv SIGURG
-signal, indicating that
-disconnection has occurred.
-If the signal is issued during a
-system call, the system call may be interrupted,
-in which case the
-.Va errno
-value upon return from the system call is
-.Er EINTR .
-If the signal
-.Dv SIGURG
-is being handled by reading
-from the socket, and it was an
-.Xr accept 2
-that
-timed out, the read may result in
-.Er ENOTSOCK ,
-because the
-.Xr accept 2
-call had not yet returned a
-legitimate socket descriptor when the signal was handled.
-.Dv ETIMEDOUT
-(or some other
-.Va errno
-value appropriate to the type of error) is returned if
-.Dv SIGURG
-is blocked
-for the duration of the system call.
-A user program should take one of the following approaches:
-.Bl -tag -width Ds
-.It Block Dv SIGURG
-If the program is servicing
-only one connection, it can block or ignore
-.Dv SIGURG
-during connection
-establishment.
-The advantage of this is that the
-.Va errno
-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.
-.It Handle Dv SIGURG
-If the program is servicing more than one connection at a time
-or expedited data may arrive or both, the program may elect to
-service
-.Dv SIGURG .
-It can use the
-.Fn getsockopt ...TPOPT_FLAGS...
-system
-call to see if the signal
-was due to the arrival of expedited data or due to a disconnection.
-In the latter case,
-.Xr getsockopt 2
-will return
-.Er ENOTCONN .
-.El
-.Sh SEE ALSO
-.Xr netstat 1 ,
-.Xr clnp 4 ,
-.Xr cltp 4 ,
-.Xr iso 4 ,
-.Xr tcp 4 ,
-.Xr ifconfig 8
-.Sh BUGS
-The protocol definition of expedited data is slightly problematic,
-in a way that renders expedited data almost useless,
-if two or more packets of expedited data are send within
-time epsilon, where epsilon
-depends on the application.
-The problem is not of major significance since most applications
-do not use transport expedited data.
-The problem is this:
-the expedited data acknowledgment TPDU
-has no field for conveying
-credit, so it is not possible for a
-.Tn TP
-entity to inform its peer
-that "I received your expedited data but have no room to receive more."
-The
-.Tn TP
-entity has the choice of acknowledging receipt of the
-XPD TPDU:
-.Bl -tag -width Ds
-.It "when the user receives the" XPD TSDU
-which may be a fairly long time,
-which may cause the sending
-.Tn TP
-entity to retransmit the packet,
-and possibly to close the connection after retransmission, or
-.It "when the" Tn TP No "entity receives it"
-so the sending entity does not retransmit or close the connection.
-If the sending user then tries to send more expedited data
-.Dq soon ,
-the expedited data will not be acknowledged (until the
-receiving user receives the first XPD TSDU).
-.El
-.Pp
-The
-.Tn ARGO
-implementation acknowledges XPD TPDUs
-immediately,
-in the hope that most users will not use expedited data frequently
-enough for this to be a problem.