1 0 Ref. B1 - NCP : FUNCTIONAL SPECIFICATION (Ref. B1) + ___ __________ _____________ ___ __ 0 Version 2 + _______ _ 0 8 March 1982 + _ _____ ____ 0 P M Girard + _ _ ______ 0 1. Introduction + ____________ 0 The Network Control Program's function could be summarised roughly as follows: To provide a network interface for applications software, allowing it to communicate with applications elsewhere on a network or multi-network system. 0 The purpose of this paper is to spell out the implications of the above statement, and to outline how, and to what extent, it has been realised in practice. - 2. Versions + ________ 0 The original version, known as DKNCP, was designed to run under MVT and is still in production use. The new version, known as VMNCP, was derived from this by transplanting the original into a CMS environment under VM, stripping out the obsolete protocols and interfaces (EPSS, MAST/ELECTRIC, etc) and generally tuning it up. VMNCP has been in production use since the middle of 1981. 0 This specification relates to VMNCP. - 3. Protocols + _________ 0 NCP is primarily concerned with the implementation of Levels 2, 3 and 4 of the ISO 7-Layer Model, but in the case of interactive terminal protocols it also concerns itself to some extent with Levels 5 and 6 because of the need to minimise direct modifications to the manufacturer's terminal support software. Level 1, of course, is handled by manufacturer's hardware and is of no direct concern to NCP. 0 NCP is designed to support, in principle, any number of physical links, using one or more Level 2 protocols. In practice, the existing software will support up to 4 links (or up to 8 with some minor changes), and it would require a moderate amount of work to extend it beyond this. Currently, only one Level 2 protocol is implemented, namely IBM Binary Synchronous, in the restricted form used - NCP : FUNCTIONAL SPECIFICATION PAGE 1 1 0 Ref. B1 0 by HASP for MULTILEAVING workstations. This is described in sufficient detail in Ref. A1. Level 3 packets may be carried in the data part of the BSC block, each packet being preceded by a 2-byte prefix containing length information. The software can support multiple packets per BSC block, but only one packet per block has ever been used in practice. The maximum length of a block containing one maximum-sized packet (256 bytes + header) is 270 bytes. 0 NCP's structure is capable of supporting more than one Level 3 protocol, and indeed the MVT version actually drives both EPSS and X25 simultaneously. The EPSS protocol has, however, been removed from the new version of NCP, and the latter now supports only X25 at Level 3. The X25 is PSS-compatible, but does not (yet) support some features of PSS X25 such as RESET packets (receipt of a RESET packet causes clearance of the call). LCN assignment is now fully PSS-compatible, and the ranges used can be selected by setting a couple of constants. FAST SELECT is always used for outgoing calls, but is optional for incoming calls. 0 In principle, any number of simultaneous calls can be supported, the only effective constraints being the storage required for control blocks and the number of LCNs available. 0 At Level 4, NCP supports a subset of the Yellow Book Transport Service (Refs. A6, A4, A5). This includes CONNECT, ACCEPT, DISCONNECT, DATA, PUSH, EXPEDITED and ADDRESS primitives. RESET is currently not supported. The code supports incoming CONNECT messages which conform to the simplified scheme advocated in the JNT recommendation dated 23rd December 1980 (Ref. M1). The overflow of CONNECT parameters into subsequent packets is not supported. The ADDRESS primitive can carry addresses of up to 63 bytes only. A DISCONNECT from the Application or from the network causes a Clear Request packet to be sent out. - 4. Interfaces + __________ 0 There are five interfaces from NCP to the outside world. 0 (1) To the network + __ ___ _______ 0 NCP currently drives up to 4 lines using IBM Binary Synchronous protocol. The lines are physically connected to a Memorex 1270 controller (which emulates an IBM 2703), and thence to a byte multiplexor channel on the mainframe. - 0 NCP : FUNCTIONAL SPECIFICATION PAGE 2 1 0 Ref. B1 0 NCP contains a routine that issues the necessary SIO and TIO instructions directly and examines the resulting channel status conditions. 0 (2) To applications software in the mainframe + __ ____________ ________ __ ___ _________ 0 The normal interface is provided by IBM's Virtual Machine Communication Facility (VMCF), used according to a protocol defined at RAL. The latter is described in detail in Ref. A2, and the particular form of it used by NCP is described in Ref. A3. This interface is used by all applications except incoming terminal calls. 0 The interface to the Operating System for incoming terminal calls is provided by IBM's Logical Device Support Facility (LDSF), used in the manner described in Ref. B3. Some modifications to the ASCII terminal support provided by VM were needed to make effective use of this. 0 Further details are given in a later section of this paper, in connection with applications protocols. 0 (3) To the operators + __ ___ _________ 0 NCP is designed to run almost entirely without operator intervention, which has proved a successful strategy under MVT in the past. The VM version will send a message to its VM console if the number of line errors has exceeded a threshold value over a period of time, or if some other serious malfunction has occurred. Such messages are merely warnings however, and the program will continue running regardless. The operator may type a variety of commands to NCP to do such things as turn on full line diagnostics or drain a line. In practice, the only command an operator is likely to need regularly is the TERMINATE command, which terminates the program. This should always be used rather than merely logging off the virtual machine, as it closes everything down cleanly and terminates all the calls in a regular manner. 0 Communication with the console is achieved via the CMS RDTERM and WRTERM macros. 0 (4) To the statistics/logging file + __ ___ __________ _______ ____ 0 The VM version of NCP uses a CMS-compatible minidisk formatted into 4096-byte blocks. The first 15 blocks are used for holding statistics: a block for each day for two weeks, plus a control block. The rest of the data set is used for holding logging information output by NCP. Logging information is written in 56-byte records, and it is possible to fit up to 73 such records in each block. 0 Further details will be found in Ref. B5. - NCP : FUNCTIONAL SPECIFICATION PAGE 3 1 0 Ref. B1 - Writing to the minidisk is done by a small package (the DEFI package) which is described in Ref. C3. 0 (5) To the Network Address Table + __ ___ _______ _______ _____ 0 This may be held on a CMS minidisk, in which case it is read into main storage (using FSOPEN, FSREAD, etc) during NCP initialisation. Alternatively, it may be directly compiled into the program as in the past. - 5. Structure + _________ 0 NCP is composed of a set of "processes" which run effectively asynchronously under the dispatcher provided by the Inter-Process Communications Package (IPC). The latter also provides timer facilities, inter-process messages, an 'access method' to the VMCF-based application interface, buffer management and monitoring facilities, and other features. The IPC package is fully documented in Ref. C1. 0 Each Level 2 link is handled by a separate process, and so is each Level 3 call. Level 4 facilities are bolted on to the call handler processes. Finally, there are a number of special-purpose processes devoted to such activities as statistics collection, command handling, and so on. - 6. Asynchronism + ____________ 0 Communications with the network are completely asynchronous, in the sense that other processing continues while a channel program is being executed. 0 Communications via VMCF and LDSF are also fully asynchronous. 0 Input from the console is handled by looking at the console stack every few seconds, and continuing normal operation if it is empty. If a command is found, it is handled by NCP's command process. Output to the console is not asynchronous: it uses the CMS WRTERM macro. If NCP is running 'disconnected', output sent to the console is thrown away. 0 Communication with the statistics/logging file is also not asynchronous. For this reason, it is desirable to avoid frequent accesses to the disc, and in practice up to 73 lines of logging are accumulated in store before being written away. Statistics collection sometimes requires a number of consecutive disc accesses, for instance at the - NCP : FUNCTIONAL SPECIFICATION PAGE 4 1 0 Ref. B1 0 beginning of a new week, but normally only one block is written at the end of each 15-minute interval, and an additional (control) block at the end of each 2-hour period. 0 Communication with the Network Address Table disc (if used) is synchronous, but this takes place once only, during program initialisation. 0 We can thus say that all interfaces to the outside world are driven asynchronously, except for output to the console (which should be rare) and access to the statistics/logging disc (which should be fairly infrequent apart from the regular single access every 15 minutes). - 7. Dependencies + ____________ 0 (1) Dependency on IBM-compatible architecture + __________ __ ___ __________ ____________ 0 Dependency on this is total, as a substantial part of the program is written in IBM Assembler. 0 (2) Dependency on IBM-compatible software products + __________ __ ___ __________ ________ ________ 0 Most of the program is written in FORTRAN, but heavy use is made of the byte-handling (LOGICAL*1) capabilities of the IBM FORTRAN H Extended Plus compiler. Use is also made of the bit-manipulation functions supported directly by that compiler. The FORTRAN library is not required at all. 0 (3) Dependency on virtual machine operating system + __________ __ _______ _______ _________ ______ 0 NCP currently runs under the IBM-supplied CMS virtual machine operating system. Dependency on this is limited, and it would not be a very major undertaking to make it work under a different operating system. The program is at present dependent on CMS for initial loading from a CMS 'MODULE' file. It also makes use of the OS STAE macro and of OS GETMAIN/FREEMAIN and ABEND facilities, which are all simulated by CMS. Communication with the console uses the CMS RDTERM and WRTERM macros, and the STAE exit uses the CMS DMSKEY macro. Communication with the Network Address Table disc (if present) uses the CMS FSOPEN, FSREAD and FSCLOSE functions. 0 NCP could be run under any virtual machine operating system capable of carrying out functions equivalent to the above. All CMS-dependent code in NCP is concentrated in the routines IEAVM and TABLE. - - NCP : FUNCTIONAL SPECIFICATION PAGE 5 1 0 Ref. B1 0 (4) Dependency on the VM Control Program (CP) + __________ __ ___ __ _______ _______ __ 0 This is fairly extensive, because the application interfaces use the VMCF and LDSF DIAGNOSE functions provided by CP. The VMCF functions are used only from the IPC package, so replacement of a VMCF interface by something else should involve changes to IPC only. Nevertheless this could be quite difficult to do, unless the new mechanism provided very similar features. The LDSF functions are used by routines in NCP's 'FETCH' module, and LDSF interrupts are handled by the 'NCPCMS' process. 0 Most other usage of DIAGOSES provided by CP is confined to the IEAVM module: for instance DIAGNOSE X'0C' is used for obtaining the date, and DIAGNOSE X'08' is used for issuing commands to CP. 0 To run NCP under VM, the virtual machine must use the REAL TIMER and ECMODE options. - 8. Packages Incorporated in NCP + ________ ____________ __ ___ 0 (1) Inter-Process Communications Package (IPC) + _____ _______ ______________ _______ ___ 0 This is an indispensible component, providing the process structure and dispatcher around which NCP is built. It also contains the software required for driving the VMCF- based protocol used by the application interface. This package comprises a single module written in Assembler, and is fully specified in Ref. C1. 0 (2) Disc Access Package (DEFI) + ____ ______ _______ ____ 0 This minor package comprises three small routines: DEFI, DRIN and DROUT. DEFI performs initialisation, and DRIN and DROUT read and write 4096-byte blocks only. The virtual device address of the minidisk is 201. The package is specified in Ref. C3. 0 (3) VMCF/LDSF Package + ____ ____ _______ 0 This package was originally written as a nucleus-resident module for use under MVT, but it is now used under CMS. It is concerned with the detailed use of VMCF and LDSF DIAGNOSES and with the handling of VMCF and LDSF interrupts. The code needed for interfacing to it is in module IEAVM. The package is specified in Ref. C2. - - 0 NCP : FUNCTIONAL SPECIFICATION PAGE 6 1 0 Ref. B1 0 9. Auxiliary Procedures + _________ __________ 0 (1) NLOG + ____ 0 NCP writes its logging information to disc in a special format, which requires interpretation at the time of printing. NLOG may be run at any time from any virtual machine. It 'links' to NCP's disc, reads the blocks (using the DEFI package, which it contains), and prints the output using appropriate FORTRAN WRITE and FORMAT statements. 0 If no parameters are supplied, the procedure prints roughly the last 1000 lines which have been logged. However, the disc is likely to contain several days of logging information, and it is possible to supply parameters asking for any particular set of blocks to be printed. 0 (2) LOGINDX + _______ 0 This procedure prints an index of the disc contents, indicating the date and time of the start of each disc block. 0 (3) DEFILOG + _______ 0 This procedure formats the entire minidisk (statistics and logging parts) by filling each block with 4096 zero bytes. This of course should need to be done only once, and never again. It cannot be run at the same time as NCP. 0 (4) NSTAT + _____ 0 This procedure can be run at any time from any virtual machine. Normally it prints off the weekly statistics for the previous week, but if supplied with the parameter 'C' it prints off the current week's statistics instead. 0 Statistics are analysed by day of the week, by application protocol, and by time of day. Totals are produced for (successful) calls and for packets, segments and bytes. 0 (5) TABSIZE + _______ 0 This procedure can be run to find out whether the VMNCP TITLES file (containing the network addresses) is valid, and if so how much space needs to be configured into VMNCP's BLOCK DATA subroutine. If an error reply is returned, the listing of the 'TABLE' subroutine in VMNCP should be consulted to interpret the various codes. - - NCP : FUNCTIONAL SPECIFICATION PAGE 7 1 0 Ref. B1 0 10. Applications Protocols + ____________ _________ 0 The 'Transport-Level Interface' that NCP provides for applications is not identical for all existing applications. The normal interface uses a VMCF connection with 4 subchannels (Refs A2 and A3), giving two subchannels for data and two for Transport Service control information. The application software is thus assumed to have a built-in Transport Service capability. 0 File Transfer applications will use this normal interface, and ideally every application should do likewise. In practice, it is sometimes not sensible to tamper with existing manufacturer's software to the extent of inserting a Transport Service interface, and it is to provide for such cases that NCP is also able to support VMCF connections with two sub-channels only. The Transport Service functions are in this case handled internally by NCP, while data is passed to and from the application transparently. NCP supports RSCS-Networking (also known as VNET) in this manner, and it is important to note that VNET as used at RAL is therefore NOT capable + ___ of making outgoing network calls. To do that, it would require substantial changes, amounting to the incorporation of Transport-Level software. A description of the interface to VNET is given in Ref. B4. 0 Terminals constitute another special case because NCP must convert from the network terminal protocol to the protocol understood by the manufacturer's Operating System. NCP currently supports three network terminal protocols: ITP, XXX and TS29. The ITP and TS29 protocols are fully network-independent and can be used over multiple networks by means of the Transport Service. XXX, unfortunately, is dependent on X25 facilities (such as the Q-bit), and is not compatible with the normal Transport Service in other respects. 0 The applications that NCP is currently able to support can be summarised as follows: 0 (1) RSCS-Networking (=VNET): Incoming calls only, using two-subchannel VMCF connections to VNET (the latter required modifications to support this). 0 (2) ITP, XXX and TS29: Incoming calls only. The user is given a "logical device" which can be used for logging on to a virtual machine (e.g: to the user's CMS machine), or for DIALing to certain special multi-access virtual machines. 0 (3) Bootstrap: This is a special RAL application, providing facilities for down-line loading a GEC 2050 from the mainframe. - NCP : FUNCTIONAL SPECIFICATION PAGE 8 1 0 Ref. B1 - (4) General Applications: These include FTP (incoming and outgoing calls) and any other applications provided with a proper Transport Service interface. Some of the above protocols are documented in Refs. A1, A7 and M2. 0 (5) Full-screen Terminal Support: There are experimental facilities for handling 3270 protocol over X29 and TS29, but a service is not provided at the present time, and the method of carrying the protocol is still under review and likely to change. Further details are given in Ref. B7. - 11. References + __________ 0 Consult the Index to Documentation (Ref. I1) for all references used in this paper. - - - - - - - - - - - - - NCP : FUNCTIONAL SPECIFICATION PAGE 9