("But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses."\ITALIC) (-- Bruce Leverett, "Register Allocation in Optimizing Compilers"\BOLD)

("No, no, no, don't tug on that. You never know what it might be attached to."\ITALIC) (-- Buckaroo Banzai\BOLD) (The Cast of Characters\CMUIP_ORG_1) (IPDriver\CMUIP_ORG_2) (IPDriver)

From a conceptual point of view, CMU-OpenVMS/IP can be seen as a sophisticated VMS device, IP:. All requests are sent to the IP device which processes them and returns the results to the client. In addition to processing user requests such as reads and writes, the IP device also handles the delivery of ASTs, the setting of event flags, and other tasks normally associated with a device driver. Before CMU-OpenVMS/IP can be made operational, the IP driver must be loaded and connected (using SYSGEN).

The IP driver actually does very little of the work associated with TCP/IP. Instead, it hands off the user requests to the TCP/IP demon process, the IPACP which does most of the work. The system was designed this way to allow the TCP/IP code to exist in a process space of its own, instead of being located in the kernel with the IP driver. Since the TCP/IP code is in its own process, it can use all of the system calls and libraries normally available to a normal process. Keeping the code in user space also makes debugging much easier (using DEBUG, instead of XDELTA). (IPACP\CMUIP_ORG_3) (IPACP)

The IP Ancillary Control Process (IPACP) is the heart of CMU-OpenVMS/IP. It forms the bridge between the outside world and the client processes. The IPACP communicates with the external world through IP transports which are described below. (NamRes\CMUIP_ORG_4) (NamRes)

The CMU-OpenVMS/IP Name Resolver performs three functions. Primarily the Name Resolver does just that, resolves names. The IPACP asks the Name Resolver to translate between Domain Names and IP addresses. The Name Resolver also maintains a cache of Domain Names for future reference. A third function of the Name Resolver of translation between Domain Names and Resource Records. (IP transports\CMUIP_ORG_5) (Transports)

Beginning with CMU-Tek/IP 6.5, device-specific support for the transmission of IP datagrams over physical mediums has been moved into medium specific modules. These modules are VMS shared run-time loadable images. The device-specific code no longer needs to exist within the IPACP image. This means that support for new interfaces can be added to the package at run-time, instead of link-time, or even compilation time.

IP transports are also responsible for routing the IP addresses they are given into the appropriate physical network addresses they must use. This may be a simple job for point-to-point transports like SLIP which only have one destination address available, or it can be very complicated, as is the case with the EtherNet transport which needs to do an ARP query to find the physical EtherNet address which corresponds to a given IP address. (Component Interaction\CMUIP_ORG_6) (client (DOUBLE_LONGLEFTRIGHTARROW) IP device \CMUIP_ORG_7)

Communication between the client and the IP device is performed by assigning a channel to the IP: device (with the SYS$ASSIGN service) and using the standard VMS QIO mechanism to send requests. For more information regarding this, see the description of the SYS$QIO system service as well as the (VMS Systems Programming I/O manual). (IP device (DOUBLE_LONGLEFTRIGHTARROW) IPACP\CMUIP_ORG_8)

The IP device receives requests through any of several entry points which correspond to the various function codes accepted by the SYS$QIO call, like the NET$OPEN code, or the NET$SEND code. Control is given to the appropriate entry point along with a vector of six long words, P1-P6, which correspond to the six user arguments passed into the SYS$QIO call. Also available at this time is the channel's UCB (Unit Control Block) and an IRP (I/O Request Packet) created specifically for this request. The IP device first checks the user-supplied parameters to make sure they are reasonable and accessible. It then allocates a UArg (User Arguments) block from the system's Non-paged pool and fills it in, using the parameters passed by the user. It links the UArg with the IRP and calls EXE$QIOACPPKT which places the IRP in a queue accessible to the IPACP and then tells the IPACP to wake-up and do some work.

The IP device does no further processing or even post-processing of the request because there is no further IP-specific processing required; it can all be performed by the standard VMS IO$POST interrupt when the IPACP is finished with the request. Note that it is possible for the IP driver to perform I/O post processing on a request by placing the address of one of its entry points in the IRP's PID field. Such an entry point exists in the IP driver, IP_FINISHIO, but is not used at this time. See the book ("Advanced Device Driver Techniques") for details. (IPACP (DOUBLE_LONGLEFTRIGHTARROW) NamRes\CMUIP_ORG_9)

When the NamRes process is started up, it creates a mailbox through which it can receive and answer requests. Normally only the IPACP uses this mailbox but it is available for use by anyone. The NamRes routines within the IPNCP are an example of how to directly access the Name Resolver.

The Name Resolver communicates with Name Servers on the internet through a UDP connection to the IPACP. (IPACP (DOUBLE_LONGLEFTRIGHTARROW) IP transport\CMUIP_ORG_10)

The IPACP creates a Device Configuration Entry for each interface it has to the outside world. The dev_config entry contains all of the device-independent information regarding that interface. Attached to every dev_config entry is block of device-specific data which is owned and interpreted by one of the IP transports loaded into the system. The dev_config entry contains a list of entry points into the transport which it uses to manipulate that transport's interfaces. Functions which must be provided by every transport are: (UNNUMBERED) Initialize yourself, Transmit an IP datagram, Tell me about yourself, and Confirm that you are functioning.

The IP transport communicates back to the IPACP through the IPACP Interface Block (IPACP_Int). The IPACP_Int is a collection of entry points and pointers into the IPACP which perform the following functions: (UNNUMBERED) Accept an incoming IP datagram from the IP transport. Log a significant events which occurred within the transport. Find the Maximum Buffer size that IPACP will accept. (IP transport (DOUBLE_LONGLEFTRIGHTARROW) outside world\CMUIP_ORG_11)

For a detailed description of the IP transport mechanism, see (transport_appendix).

The manner in which the transport determines where to send an IP datagram is independent of the IPACP but is worth discussing never-the-less. The EtherNet transport, XEDRV.EXE, contains an implementation of ARP (Address Resolution Protocol) which it uses to query other IP nodes about their hardware addresses. The results are cached to avoid preceding each IP transmission with an ARP query.