cons.4p

早期freebsd实现

.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"