.\" $Id$ .\" .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 \fR \fB#include \fR \fB#include \fR \fB#include \fR \fB#include \fR .sp \fBint cons_output(isop, m, len, isdatagram)\fR .sp or for use as a subnetwork service (COSNS): .sp \fB#include \fR \fB#include \fR \fB#include \fR \fB#include \fR \fB#include \fR \fB#include \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 least significant bit). The error values can be found in the file .nf .in +5 .sp \fC\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"