Software Product Description ___________________________________________________________________ PRODUCT NAME: DECnet/OSI Version 6.1 for OpenVMS AXP SPD 50.45.05 1 DESCRIPTION DECnet/OSI V6.1 for OpenVMS AXP is an implementation of Phase V of the Digital Network Architecture (DNA) for the OpenVMS Operating System for AXP hardware. DECnet/OSI integrates DECnet and OSI network pro- tocols allowing both stacks to share integrated network functions up to the Transport Layer. Upper Layers have been implemented as sepa- rate "towers" allowing existing DECnet and OSI applications to share the integrated Transport Layer. Existing DECnet Phase IV and new DEC- net and OSI applications are supported by DECnet/OSI. In combination with TCP/IP protocol stacks, OpenVMS systems can participate in mul- tivendor, multiprotocol networks adhering to Open Networking standards. New features for V6.1 include: o The ability to run DECnet and OSI applications over TCP/IP trans- ports o Expanded naming options, allowing the use of a new and larger lo- cal namespace, DECdns, and/or DNS/bind as naming services o The Graphical Network Management User Interface for improved net- work management. Other DECnet/OSI for OpenVMS features include: o Routing Segregated mode to allow the routing layer to choose a Phase IV router for those packets having a Phase IV compatible address. (Packets having a Phase V extended address will be sent to a Phase V router by default.) This is a configurable option. o Reverse Path Caching to capture path information for later use in reaching remote systems. o Increased network size, supported through the use of ISO OSI ad- dressing. o Simplified Installation and Configuration process o The Network Control Language (NCL). Network management is based on DNA CMIP, Digital's implementation of the OSI international stan- dard Common Management Information Protocol. o An NCP Emulator to facilitate installation of Layered Products writ- ten for DECnet Phase IV. o Installation using the POLYCENTER Software Installation utility. DIGITAL February 1995 AE-Q198F-TE o Network naming, allowing the use of either Local Naming or fully distributed name services. Note that the use of DECdns requires the presence of an OpenVMS VAX or ULTRIX MIPS system to host the DECdns Server. The Server is not supported on AXP systems. o Support for topologies using multicircuit and multihomed end nodes o Dynamic connections over X.25 networks. o OSI implementation in accordance with US and UK GOSIPs - Application, Presentation, and Session Layers . File Transfer Access and Management (FTAM) application . Virtual Terminal application . ASEs, including ACSE (Association Control Service Element) - Transport Layer, Classes 0, 2, and 4 - Lower Layers . OSI Addressing formats, supporting very large network topolo- gies . End System to Intermediate System (ES-IS) routing . Connectionless mode Network Service (CLNS) over local area network (LAN), wide area network (WAN), and X.25 . LLC2 for CONS over LAN . Data Link Layer, supporting HDLC for wide area communications, ISO 8802-3 (Ethernet CSMA/CD) and FDDI LANs, and DDCMP for backwards compatibility. HDLC support includes the LAPB pro- tocol for X.25 communications. . Physical Layer, with CSMA/CD, HDLC, and FDDI devices supported. DECnet/OSI for OpenVMS is available in two forms: End System and Ex- tended Function. Extended Function provides all the features of End System plus the OSI Application Gateways (FTAM - DAP gateway, VT-Telnet, VT-LAT) and Cluster Alias. See the SOFTWARE LICENSING section for more details. DECnet/OSI for OpenVMS offers task-to-task communications, file man- agement, downline system and task loading, network command terminals, and network resource sharing capabilities using DNA, ISO and TCP/IP protocols. DECnet/OSI for OpenVMS communicates with adjacent and non- adjacent DECnet Phase IV, PATHWORKS, DECnet/OSI implementations on other OpenVMS, ULTRIX, and DEC OSF/1[R] systems, as well as OpenVMS systems running TCP/IP transports. OpenVMS programs written in native mode programming languages can use DECnet/OSI for OpenVMS capabilities. 2 Depending on the system configuration, networks combining DECnet/OSI for OpenVMS systems with other DECnet, OSI and TCP/IP products may limit the functions available if all products do not support equal features. 1.1 Data Link Layer DECnet/OSI for OpenVMS uses synchronous, Ethernet, and FDDI communi- cations controllers to interface with other network nodes. LAN connectivity is provided by the CSMA/CD and FDDI controllers and drivers supporting ISO 8802-2 Logical Link Control (LLC) type 1 con- nectionless service. DECnet/OSI also supports Ethernet V2 packets on CSMA/CD devices. Use of FDDI packets larger than 1500 bytes requires a Phase V router on the FDDI LAN. As with Cluster Alias support, the Phase V router may be configured to run the Phase IV distance vector routing protocol or the Phase V link state routing protocol. WAN connectivity is provided by WAN Device Drivers supporting host- based synchronous communications options for wide area networking. All the data link devices support HDLC/LAPB and SDLC protocols. WAN Device Drivers are required by X.25 to establish host-based wide area connections. DECnet/OSI for OpenVMS allows up to four circuits to be defined and operational on an End System. This capability allows a single end sys- tem to be connected to up to four separate LANs or WANs. Note that all circuits must be equal in capacity and connectivity. 1.2 X.25 The X.25 software allows DECnet/OSI for OpenVMS AXP systems to con- nect to PSDNs conforming to CCITT Recommendation X.25 (1980, or 1984) and/or ISO 7776 and 8208, and to support CONS over Local Area Networks using LLC2 as the Datalink protocol for X.25. It allows process-to- process as well as terminal-to-process communications between AXP sys- tems and a remote DTE over a PSDN. Use of the X.25 software to provide direct access to a PSDN (using the supported WAN device drivers) requires a X.25 license. See the OPTIONAL SOFTWARE section. For more details on the X.25 software for OpenVMS AXP systems, refer to the X.25 V1.0 for OpenVMS AXP Software Product Description (SPD 47.37.xx). 1.3 Network Layer DECnet/OSI for OpenVMS supports both the Connectionless mode Network Service (CLNS) and the Connection mode Network Service (CONS). DEC- net/OSI supports end system routing only. 3 Exchange of routing information between end systems and routers uses the ISO 9542 ES-IS routing protocol. This allows DECnet/OSI systems to autoconfigure as end systems with supported others supporting ISO 9542. Addresses conform to the ISO 8348 Addendum 2 specification allowing the support of large network topologies. As long as the system address stays within the addressing range of Phase IV systems (up to 1,023 sys- tems per area and up to 63 areas per network), and uses the same Ini- tial Domain Part (IDP), Phase IV or Phase V routers may be used. The network layer supports the capability of an end system to be mul- ticircuited and multihomed. Multicircuit support allows multiple cir- cuits to be active simultaneously. This increases network reliabil- ity and data throughput. Multihomed end system support allows a sys- tem to have up to three Network Entity Titles. Segregated Routing Mode is a settable attribute. It will direct rout- ing to choose a Phase IV router for those packets having a destina- tion address that can be translated to the Phase IV format. All other packets will be sent to a Phase V router, if available. The routing layer is able to cache information about the paths that are used to reach remote nodes. 1.4 Transport Layer DECnet/OSI for OpenVMS provides support for: o OSI Transport protocol as specified in ISO 8073 o RFC 1006 and 1006 Extensions (Internet Draft) to allow DECnet and OSI applications to run over TCP/IP o Network Services Protocol (NSP) NSP, RFC 1006 and OSI transports support communications between DEC- net, TCP/IP and OSI systems. NSP provides backwards compatibility with Phase IV DECnet systems. RFC 1006 support for DECnet applications is provided via a kernel in- terface that has been implemented on all TCP/IP stacks available for use on OpenVMS. The supported applications include all licensed DEC- net applications as well as layered products, and user-written appli- cations that conform to the documented DECnet programming interfaces. Internet RFC1006 defines a specification for running OSI applications over TCP/IP. Operation of the FTAM and Virtual Terminal applications over a TCP/IP network is supported along with other layered OSI ap- plications such as X.400 and X.500. A separate TCP/IP stack is required on the same system with DECnet/OSI. See the OPTIONAL SOFTWARE section of this SPD for information on sup- ported TCP/IP products. OSI Transport supports Transport Classes 0, 2, and 4 on Connection Ori- ented networks and Class 4 on Connectionless networks. 4 OSI Transport uses two types of network service: o The Connectionless-mode Network Service (CLNS) using the Internet protocol (ISO 8473) and ES-IS protocol (ISO 9542) to communicate across linked subnetworks. The inactive subset of ISO 8473 (null internet) is also supported for communications over a single ISO 8802-3 local area network. o The Connection Oriented Network Service (CONS). 1.5 Upper Layers DECnet/OSI for OpenVMS software provides the OSI upper layer stack con- sisting of Session, Presentation and Application layers. The Appli- cation layer provides Association Control Service Element (ACSE), File Transfer, Management and Access (FTAM), and Virtual Terminal (VT). DECnet/OSI for OpenVMS also provides a range of DECnet applications and services including file and record access, remote terminal access, mail, and phone. 1.6 Applications Transport Options for Applications Applications written to the DECnet upper layers can now be run over NSP, OSI or TCP/IP transports via RFC 1006. This includes the network applications that are licensed with DECnet/OSI as well as user writ- ten applications that adhere to the documented DECnet programming in- terfaces. The use of TCP/IP transports via RFC 1006 does not require any modification to the existing application. Applications written to the OSI upper layers can now be run over OSI or TCP/IP transports. Remote File Transfer DECnet/OSI for OpenVMS supports two upper layer protocols for remote file transfer: the OSI Protocol File Transfer, Access and Management (FTAM), and the DECnet Data Access Protocol (DAP). FTAM FTAM supports file transfer, access and management between a DECnet /OSI for OpenVMS system and other systems with software adhering to ISO 8571. In addition, FTAM is conformant with NIST Phase II and Phase III agreements and is certified as being conformant to the released specifications of US GOSIP, UK GOSIP and ENV41204. In addition, FTAM: o provides users the ability to create, delete, rename, view, and copy files using DCL commands. o is implemented as an Application Service Element (ASE) of the OSI Application layer. 5 o acts as the initiator or as the responder in a connection. o accesses and transfers files with both binary and character data. FTAM-1, FTAM-2, FTAM-3, and NBS-9 document types are supported. DECnet/OSI for OpenVMS also supports gateway services between FTAM and DAP, and between FTAM and the TCP/IP File Transfer Protocol (FTP). A full description of the FTAM services in DECnet/OSI for OpenVMS is provided in Appendix A of this document. DAP The DECnet Data Access Protocol supports task-to-task communications, file and record access, and proxy access. Task-to-Task Communications - For most applications, task-to-task com- munications can be programmed in a transparent manner where the re- mote task is treated as a full-duplex, record-oriented device. Trans- parent operation is provided with the following interfaces: System Ser- vice calls, RMS calls (OPEN, GET, PUT, and CLOSE) and high-level lan- guage I/O statements (which are mapped to RMS calls). A nontranspar- ent mode of task-to-task communications is offered by means of the Sys- tem Service interface that extends the capabilities provided by the transparent mode. These capabilities include support for interrupt mes- sages and multiple inbound connect requests. Using DECnet/OSI for OpenVMS an OpenVMS program written in a native mode programming language can exchange messages with other user pro- grams. File Access: File access is supported to and from remote DECnet/OSI for OpenVMS systems transparent to native mode high-level language pro- grams using RMS. User programs can sequentially read, create, and delete files on a remote node. Record Access: User programs can perform record level operations such as GET, PUT, UPDATE, DELETE, FIND, and REWIND to access and modify files residing on a remote OpenVMS node. In addition to sequential access to a file, several other access methods are supported through RMS us- ing DECnet/OSI for OpenVMS. These methods include random access by rel- ative record number, random access by key value, random access by Record File Address (RFA), and block I/O access by virtual block number. Proxy Access: Remote users can have access to up to 15 proxy accounts on a specific remote system. One proxy account should be designated as the default proxy account on the remote system. Command Language File Management: Most OpenVMS Digital Command Lan- guage (DCL) commands can be used to perform remote file operations. These commands include: ANALYZE, APPEND, BACKUP, CLOSE, CONVERT, COPY, CREATE, DELETE, DIFFERENCES, DIRECTORY, DUMP, OPEN, PRINT, PURGE, READ, SEARCH, SUBMIT, TYPE, and WRITE. The operation of these commands is transparent except for commands that invoke processing on a specific system (for example, SUBMIT/REMOTE and PRINT/REMOTE). Only a node name 6 added to a file specification is required to invoke the network ca- pabilities via one of these commands. Using the COPY command, a user can transfer sequential, relative, and indexed-sequential (ISAM) files between DECnet/OSI for OpenVMS nodes that support compatible file structures and record formats. Sequen- tial or relative files with fixed length, variable length, or vari- able length with fixed control field records can be transferred be- tween two DECnet/OSI for OpenVMS systems. Similarly, multikeyed in- dexed files with variable or fixed length records are supported. The SUBMIT/REMOTE command allows command files residing on a remote node to be submitted for execution at the remote node. The command file must be in the format expected by the node responsible for execution. DECnet/OSI for OpenVMS allows OpenVMS command files to be received from other systems and executed. The DCL command, EXCHANGE/NETWORK, allows the transfer of files to or from heterogeneous systems. This command gives users the option to trans- fer file types between MS-DOS[R] or ULTRIX systems and OpenVMS sys- tems regardless of record semantics. Unlike the COPY command, which preserves file and record organization during a file transfer, this command enables the user to modify file and record attributes during file transfer. Network Virtual Terminal DECnet/OSI supports two upper layer protocols for terminal access: the OSI Virtual Terminal protocol and the DECnet Command Terminal proto- col. VT Virtual Terminal (VT) supports the ISO Virtual Terminal Protocol (ISO 9041). This protocol allows remote logins and access to remote appli- cations between DECnet/OSI for OpenVMS systems and any remote system, including multivendor systems, that also run an ISO-compliant Virtual Terminal implementation. Virtual Terminal is implemented as an Application Service Element (ASE) of the OSI Application layer. Virtual Terminal may act as the terminal/initiator (for a local user) or as the host/responder (for the remote user). A full description of Virtual Terminal features is provided in Appendix B of this SPD. SET HOST The DCL command SET HOST allows a terminal user on one DECnet/OSI for OpenVMS node to establish a logical connection to another DECnet/OSI node that uses the Command Terminal Protocol (CTERM). This connection makes the terminal appear to be physically connected to the remote sys- tem and the operator can use all the standard system and network util- ities supported by that remote node. This capability is particularly useful for doing remote program development and allows the terminal 7 users on smaller application-oriented systems to use the resources of larger development-oriented systems. Application Interfaces The OSI upper layer interfaces enable users to develop OSI applica- tions using FTAM, ACSE, and presentation services to run on any DEC- net/OSI system. These applications may communicate with similar ap- plications running on other vendors OSI systems. Other interfaces are standard parts of DECnet/OSI for OpenVMS. Users can develop programs and procedures based upon these interfaces for such functions as file access and task-to-task communications on in- dividual systems. Since the DECnet/OSI for OpenVMS interfaces stay the same, the programs and procedures developed on an individual system can be used in a network environment without being modified. 1.7 Services Downline Loading DECnet/OSI for OpenVMS allows for the loading of an unattended sys- tem using the services provided by the Maintenance Operations Module (MOM). MOM provides a set of maintenance operations over various types of circuits by using the Maintenance Operations Protocol (MOP). A load- able system is a system that has a load device enabled for MOP ser- vice functions and for which a properly formatted load file is sup- plied. Downline loading involves transferring a copy of the load file image to a remote target node. Load requests can come from the local DECnet/OSI for OpenVMS operator or from the target node. Downline load- ing is supported for Digital server products. Downline Task Loading Initial task images for loadable systems can be stored on OpenVMS file system devices and loaded into remote nodes. Programs already execut- ing on loadable systems can be checkpointed to the host OpenVMS file system and later restored to main memory in the node. These features simplify the operation of network systems that do not have mass stor- age devices. Upline Dumping Memory images of adjacent nodes connected by DECnet/OSI for OpenVMS can be written or dumped into a file on an OpenVMS system. This fa- cility provides assistance in troubleshooting in the event of a sys- tem crash. This facility is also supported for Digital server prod- ucts. Mail OpenVMS MAIL utility allows transmission of text messages between users on systems supporting MAIL-11. The DECnet/OSI for OpenVMS software al- lows users to exchange mail with users of other DECnet/OSI systems. PHONE 8 The OpenVMS PHONE utility allows users to send and receive data in- teractively from one user's terminal to another user's terminal. DEC- net/OSI allows users on different systems in the same DECnet/OSI net- work to exchange information. VMScluster Alias DECnet/OSI for OpenVMS supports the ability to access nodes in a VM- Scluster using a separate alias node address, while retaining the abil- ity to address each node in the cluster individually. Not all network objects may be accessed using this mechanism. The maximum number of nodes supported for for a cluster alias is 94. Refer to the VMSclus- ter Software Product Description (SPD 42.18.xx) for relevant restric- tions. DECnet/OSI no longer requires a cluster member to be configured as a router. Clusters in a DECnet/OSI environment do require a reachable IS-IS compliant router on the LAN. Network Management Network Management is provided with the Network Control Language (NCL). Network management implements the DECnet/OSI layered model, based on the Digital hierarchical structure called Enterprise Management Ar- chitecture (EMA). NCL can be accessed through either a command line interface or a Graph- ical User Interface (GUI). The GUI allows network managers to view the status of network components and control those components from a mo- tif based window interface. The DECnet/OSI for OpenVMS network management software allows: o system or network managers to control and monitor the operation of a network and provide information related to network traffic and performance; o network operating parameters to be configured; o the manager to startup and shutdown network components as needed; o network problems to be detected, isolated, and returned to service once repaired. In addition, network management can provide information warning net- work managers of faulty or failing network components, both hardware and software. Network Command Language (NCL) is provided as a utility to the net- work manager to perform the operations described above. NCL can also be used to test specific components of the network. NCL enables transmission and reception of test messages either between sys- tems or through controller loopback arrangements. The messages can then be compared for possible errors. NCL aids in isolating network prob- lems. 9 DECnet/OSI for OpenVMS provides network event logging to a terminal device, disk file, or remote system. NCL can be used to enable and dis- able the event logging facility as well as to optionally filter spe- cific events. NCL uses the DNA Common Management Information Protocol (CMIP) which permits entity management from a single location anywhere in the DEC- net/OSI network. The Common Trace Facility (CTF) allows the network manager to collect and display information about specific protocol exchanges between sys- tems. DECnet/OSI for OpenVMS supports an ISO CMISE Application Programming Interface (API) conforming to the Service Definitions in ISO 9595. The API allows for development of applications that can communicate with other management applications conforming to ISO 9595 on remote nodes in the network. DECnet/OSI supports the DECnet Phase IV NCP for remote management of Phase IV DECnet systems. Name Service Options DECnet/OSI V6.1 allows the use of one or more naming services. The avail- able services are DECdns, DNS/bind and a new local namespace. Node name and addressing information is stored in the native name service; TCP /IP information is maintained in DNS/bind and DECnet and OSI infor- mation is maintained in DECdns or the local namespace. When more than one name service is being used, a configurable search list defines the order in which the existing services are to be ac- cessed. New Local Namespace The New Local Namespace replaces the Local Name Option. Using the New Local Namespace, up to 100,000 nodes can be defined in a local nam- ing database. A migration tool is available to move Phase IV and/or LNO databases to the new Large Local File format and/or DECdns for- mat. DNS/bind DECnet can now retrieve TCP/IP naming and addressing information from the DNS/bind name service. DECdns DECnet/OSI for OpenVMS provides a global naming service with the Dig- ital Distributed Naming Service (DECdns). The full DECdns service provides a consistent, network-wide set of names for network resources called the namespace. This namespace is main- tained by one or more DECdns server systems. It is recommended that DECdns servers should be installed on at least two systems in every LAN. This should provide an adequate service and redundancy. 10 The DECdns client is included in DECnet/OSI for OpenVMS AXP. The DECdns server is not supported on AXP systems. An OpenVMS VAX or ULTRIX MIPS system is required to support the DECdns server. The features provided by DECdns include: o A network-wide name-to-attribute mapping service which allows se- lected Digital applications to create, read, modify, and delete names in the namespace o A hierarchical structure permitting a large number of names to be stored and distributed across the network o Access control to each name in the namespace o Management and event logging Distributed Time Service DECnet/OSI for OpenVMS provides a network time service with DECdts, the Digital Distributed Time Service. DECdts provides precise, fault- tolerant clock synchronization for systems in a LAN or WAN. Time is provided in coordinated Universal Time (UTC) and may be used across a global network. Several forms of time provider are supported, and a callable interface for applications allows users to add their own time providers. DECdts may be used by distributed applications to de- termine event sequencing, duration, and scheduling. 1.8 DECnet/OSI for OpenVMS Operation DECnet/OSI is implemented under OpenVMS as an Ancillary Control Pro- cess (ACP) and a network device driver with Digital-supplied executive- level components and user-level programs. The normal OpenVMS protection has been incorporated in the operation of DECnet/OSI. For example, incoming connects, including file access and file transfer requests, are protected by the normal OpenVMS Lo- gin and file protection mechanisms. Outgoing connects, including file access and file transfer requests, can include user password infor- mation that is implicitly specified via NCL, or explicitly specified by the user for verification on the remote node. 1.9 DECnet/OSI for OpenVMS Configuration and Performance DECnet/OSI can be configured using either the BASIC or ADVANCED con- figuration options. The BASIC option is the default. It uses exist- ing system defaults and requires minimal information from the system manager. The ADVANCED option should be used where specific customiza- tion is required. As with any network protocol, the performance of a given DECnet/OSI for OpenVMS node is a function not only of the expected network traf- fic and resultant processing, but also of the amount of concurrent pro- cessing specific to that node. Thus, node performance depends on many factors including: 11 o CPU type o Number and type of devices attached to the particular CPU o Number of device interrupts per unit time o Communications line(s) characteristics o Number and size of buffers o Message size and frequency of transmission o Applications in use It is important to note that the rate at which user data can be trans- mitted (throughput) over a communications line can sometimes approach, but will never exceed, the actual line speed. The reason is that the actual throughput is a function of many factors, including the line quality, protocol overhead, topology, and network application(s), as well as the factors cited in this section. The performance of DECnet/OSI is comparable to the performance of DEC- net Phase IV. 1.10 Standards Conformance DECnet/OSI for OpenVMS has been designed and implemented to be con- formant to the following standards: o ISO - 4335 - 7776, 7809 - 8073, 8208, 8327, 8473, 8571, 8650, 8802-2, 8802-3, 8823, 8878, 8881 - 9314, 9542, 9041 - 3309 o EN - 41 204 - 41 205 - 41 206 - 41 207 o CCITT Recommendation X.25 (1978, 1980, or 1984) using the LAPB or LAPBE variants of the X.25 packet level and data link protocols o US GOSIP V2.0 o UK GOSIP V4.0 Since certification and registration of this product must take place after the product is released, contact your local Digital office for the most recent conformance certificates. 12 1.11 Documentation The documentation for DECnet/OSI for OpenVMS is supplied in four parts: o The Core Documentation set shipped with the H-kit o An optional End User Guide (one copy is shipped with the core doc- umentation) o An optional Programming guide describing $IPC, $QIO, OSI Transport, X.25, WANDD and DECdts programming interfaces o An optional X.25 documentation set covering accounting, X.29 and X.25 Mail New features are extensively documented in the Release Notes. The documentation for DECnet/OSI for OpenVMS is shipped on the Open- VMS Layered Product CD-ROM. Hard copy of the documentation is avail- able as a separate order. 2 INSTALLATION DECnet/OSI software is customer installable. Installation services are available for customers who desire installation of the software prod- uct by an experienced Digital Software Specialist. Digital requires that a customer's first use of X.25 include Digital Installation Services. These services provide for installation of the software product by an experienced Digital Software Specialist. Customer Responsibilities Before Digital Services can install the software, the customer must: o Ensure that the system meets the minimum hardware and software re- quirements (as specified in the relevant SPDs); o Prior to installing Digital hardware or software, obtain, install, and demonstrate as operational any modems and other necessary cus- tomer equipment or facilities to which Digital's communications hard- ware or software will connect; o Designate one adjacent node to verify installation/connectivity; o Make available for a reasonable period of time, as mutually agreed upon by Digital and the customer, all hardware communications fa- cilities and terminals that are to be used during installation. Delays caused by any failure to meet these responsibilities will be charged at the then prevailing rate for time and materials. Installation of DECnet/OSI for OpenVMS consists of the following tasks: o Verify all components of DECnet/OSI for OpenVMS have been received. o Verify the necessary versions of the OpenVMS software and documen- tation are available. 13 o Verify the appropriate SYSGEN parameters. Note: Should a software specialist be required to modify the pre- viously installed operating system parameters, a time and materi- als charge will apply. o Create any necessary DECnet/OSI for OpenVMS accounts and directo- ries. o Enable software via License Product Authorization Key (PAK) reg- istration. o Install the DECnet/OSI software on the target system using the POLY- CENTER Software Installation utility (PCSI). o Verify the proper installation of DECnet/OSI for OpenVMS by run- ning a series of tests to show connectivity to a designated node. Connectivity to all other nodes within the network is the responsi- bility of the customer. Digital recommends the use of NCL to help ver- ify connectivity. In some cases the PSDN supplier (or PTT) may impose restrictions, lim- itations, or requirements on the proposed Digital network configura- tion. The customer must ensure they understand and adhere to these con- trols for each and every network. 3 HARDWARE REQUIREMENTS See the OpenVMS AXP Software Product Description (SPD 41.87.xx) for further details on supported hardware configurations. For general device or controller descriptions please refer to the Net- works and Communications Buyer's Guide. Processors Supported for OpenVMS Alpha AXP Systems: Alpha AXP: DEC 2000 Model 300 Alpha AXP Workstation DEC 2000 Model 500 Alpha AXP Workstation Digital 2100 Server Model A500MP Digital 2100 Server Model A600MP DEC 3000 Model 300 Alpha AXP Workstation Family, DEC 3000 Model 400 Alpha AXP Workstation, DEC 3000 Model 400 Alpha AXP Server, DEC 3000 Model 500 Alpha AXP Workstation Family, DEC 3000 Model 500 Alpha AXP Server, DEC 3000 Model 600 Alpha AXP Workstation, DEC 3000 Model 600 Alpha AXP Server, DEC 3000 Model 800 Alpha AXP Workstation, DEC 3000 Model 800 Alpha AXP Server 14 DEC 4000 Model 600 Alpha AXP System Family, DEC 4000 Model 700 Alpha AXP System Family DEC 7000 Model 600 Alpha AXP System Family DEC 10000 Model 600 Alpha AXP System Family Disk Space Requirements (Block Cluster Size = 1) Disk space required for installation: - Base Software: 60502 blocks - With All Optional Software: 90726 blocks These counts refer to the disk space required on the system disk. The sizes are approximate; actual sizes may vary depending on the user's system environment, configuration, and software options. Supported LAN Adapters ___________________________________________________________________ Table_1:_LAN_Adapters______________________________________________ Adapter___Definition_______________________________________________ DEFZA, A high-performance network adapter that connects TUR- DEFTA BOchannel systems to ANSI FDDI LANs (DMA receive only). DEMFA A high-performance network adapter that connects XMI systems to ANSI FDDI LANs. DEMNA A high-performance network adapter that connects XMI systems to both the Ethernet and IEEE 802.3 LANs. PMAD A network adapter that connects TURBOchannel systems to __________both_the_Ethernet_and_IEEE_802.3_LANs.___________________ 4 SOFTWARE REQUIREMENTS o OpenVMS Operating System V6.1 OpenVMS Tailoring: For V6.x systems the following OpenVMS classes are required for full functionality of this layered product: o OpenVMS Required Saveset o Network Support o Programming Support For more information, refer to the OpenVMS Alpha AXP Operating Sys- tem Software Product Description (SPD 41.87.xx) OpenVMS classes and tailoring are discussed in the OpenVMS AXP Installation manual. 15 5 OPTIONAL SOFTWARE TCP/IP A separate TCP/IP protocol stack is required to use the DECnet over IP features in DECnet/OSI V6.1. The following TCP/IP products have been tested with DECnet/OSI V6.1. o DEC TCP/IP Services for OpenVMS V3.2 DEC TCP/IP Client Software License: QL-0M2A*-** DEC TCP/IP Services Software License: QL-0LXA*-** DEC TCP/IP Client Upgrade License: QL-0PHA*-** SPD: 46.46.xx o Process Software TCPware o TGVs Multinet o The Wollongong Group's PATHWAYS X.25 Optional License: The DECnet/OSI for OpenVMS AXP license grants the right to use the X.25 software for CONS over LLC2 or CLNS over DEC-HDLC. All other X.25 soft- ware functions over LAPB and LLC2 require the X.25 V1.0 for OpenVMS AXP license. The X.25 V1.0 for OpenVMS AXP License is also required to enable the X.25 utilities, such as X.25 Mail and SET HOST/X.25, as well as the X.25 Application Programming Interfaces (APIs). Software License: QL-0THA*-AA Media and Documentation: Included in DECnet/OSI for OpenVMS AXP me- dia and documentation kits (see SPD number 47.37.xx) OSI Application Developer's Toolkit: Software License: QL-3J8A*-AA 6 GROWTH CONSIDERATIONS The minimum hardware/software requirements for any future version of this product may be different from the requirements for the current version. 7 DISTRIBUTION MEDIA This product is available as part of the OpenVMS Consolidated Soft- ware Distribution on CD-ROM. The software documentation for this prod- uct is also available as part of the OpenVMS Online Documentation Li- brary on CD-ROM. 16 8 ORDERING INFORMATION Software Li- QL-MTFA*-AA (End System) censes: QL-MTGA*-AA (Extended Function) Software Media: QA-03XAA-H8 Software Documen- QA-MTFAA-GZ tation: Consolidated QT-03XAA-*8 Distribution Services: * Denotes variant fields. For additional information on available li- censes, services, and media refer to the appropriate price book. 9 SOFTWARE LICENSING The DECnet/OSI licenses gives users the right to use the software on a single CPU and includes the delivery of a License Product Authoriza- tion Key (PAK) to enable the DECnet/OSI for OpenVMS software. To use this software product on additional CPUs, users must purchase a Single-Use License Option for each CPU. The End System license grants the right to use all the DECnet/OSI fea- tures with the exception of the Cluster Alias, and the OSI Applica- tions Gateways. An Extended Function license grants the right to use the DECnet/OSI End System features, the OSI Application Gateways, and the Cluster Alias. An Extended Function license is required on at least one node in ev- ery cluster configuration to enable the use of the cluster alias. This software is furnished only under a license. For more information about Digital's licensing terms and policies, contact your local Dig- ital office. License Management Facility Support This product supports the OpenVMS AXP License Management Facility. License units for this product are allocated on a CPU basis. For more information on the License Management Facility, refer to the OpenVMS AXP Operating System Software Product Description (SPD 41.87.xx) or the License Management Facility manual of the OpenVMS AXP operat- ing system documentation set. For more information about Digital's licensing terms and policies, con- tact your local Digital office. 17 10 SOFTWARE PRODUCT SERVICES Prerequisite Support For the use of X.25 with PSDNs, the customer and Digital must jointly prepare a Network Profile and Customer Support Plan covering all the intended network nodes, their usage of SVCs, PVCs, and other network facilities, and their support. Without this Network Profile and Cus- tomer Support Plan, Digital cannot support the network connections. A variety of service options are available from Digital. For more in- formation, contact your local Digital office. 11 SOFTWARE WARRANTY Warranty for this software is provided by Digital with the purchase of a license for the product as defined in the Software Warranty Ad- dendum of this SPD. [R] TCPware is a registered trademark of Process Software Corpora- tion [R] Multinet is a registered trademark of TGV, Inc. [R] PATHWAYS is a registered trademark of The Wollongong Group [R] IBM is a registered trademark of International Business Ma- chines, Inc. [R] MS-DOS is a registered trademark of Microsoft Corporation. [TM]The DIGITAL Logo, Alpha AXP, AXP, DDCMP, DECnet, DECnet-DOS, DECnet-VAX, DECNIS, DEC WANrouter, Digital, DNA, LAT, MicroVAX, OpenVMS, Q-bus, ULTRIX, UNIBUS, VAX, VAX MACRO, VAXBI, VAXft, VMScluster, VAXserver, VAXstation, and XMI are trademarks of Digital Equipment Corporation. ©1994 Digital Equipment Corporation. All rights reserved. 18 12 Appendix A: File Transfer, Access and Management (FTAM) FTAM software provides communications for performing file operations between open systems. These operations are: o Copying files between local and remote systems. o Appending, deleting, or renaming files on open systems. o Displaying information about files on open systems. An open system is a computer system that implements the standards for each of the seven layers of the Open Systems Interconnection (OSI) Ref- erence Model for communications as defined by the International Or- ganization for Standardization. An FTAM system is any open system con- taining an FTAM implementation that conforms to the FTAM standard and includes the implementations of the necessary underlying OSI services. FTAM implements several standards that define the following components of these layers of the OSI Basic Reference Model: the File Transfer, Access and Management (FTAM) service element and the Association Con- trol Service Element (ACSE) of the Application layer, the Presenta- tion layer, and the Session layer. Supported Standards FTAM conforms to the following OSI standards: o ISO 8571 - File Transfer, Access and Management service and pro- tocol o ISO 8650 - ACSE protocol o ISO 8823 - Presentation protocol o ISO 8327 - Session protocol The following table provides a comparison of the supported implemen- tation profiles for different standards bodies and their relationship to each other. ___________________________________________________________________ International Standardized Profiles (ISP) ISO_10607_______NIST_______CEN/CENELEC_and_EWOS____________________ Part 1: Spec- - - ification of ACSE, Pre- sentation and Session proto- cols for use by FTAM 19 International______________________________________________________ Standardized Profiles (ISP) ISO_10607_______NIST_______CEN/CENELEC_and_EWOS____________________ Part 2: Def- - - inition of document types, con- straint sets, and syntaxes Part 3: AFT11 T1 - A/111 - - Simple Simple iENV 41 204 File Trans- File fer Service Transfer (Unstructured) Part 4: AFT12 T2 - Po- A/112 - (DISP) - Po- sitional ENV 41 206 sitional File File Transfer Ser- Transfer vice (Flat)[1] Part 5: AFT3 M1 - A/13 - (DISP) - File Manage- ENV 41 205 Management ment Service ___________________________________________________________________ [1]AFT12_is_not_supported_by_DECnet/OSI____________________________ DISP indicates a draft ISP. FTAM Component Software The component software includes the user facilities (initiators), re- sponders, management tools, and problem determination tools. FTAM User Facilities The FTAM user facilities are accessed by OpenVMS Operating System com- mands. These commands are APPEND, COPY, DIRECTORY, RENAME, and DELETE. They operate on files stored on any FTAM system whose implementations are compatible with FTAM. These commands cannot be used for manipu- lating files on your local system. Support for Any File Naming Convention A file designation is system-specific information that identifies a file to its storage system. FTAM software lets users specify files us- ing the naming conventions of the systems where the files reside. FTAM supports the OpenVMS Operating System RMS format for file specifica- tions and a comparable style of file-specification format that accom- modates non-RMS file designations. 20 Support for Several File Types FTAM software can access and transfer files containing both binary and ASCII data. FTAM-1, FTAM-2, FTAM-3, and NBS-9 document types are sup- ported. FTAM-1 files are unstructured text files, FTAM-2 files are sequential text files, and FTAM-3 files are unstructured binary files. The FTAM- 1, FTAM-2, and FTAM-3 document types support the following parameters. ___________________________________________________________________ String Document Signifi- Universal Type____cance______Class______Maximum_String_Length________________ FTAM-1 not sig- IA5String Presence and absence of parameter nificant GeneralString fixed VisibleStriPresence of parameter GraphicString variable VisibleStriPresence and absence of parameter GraphicString FTAM-2 not sig- VisibleStriPresence or absence of parameter nificant GraphicString FTAM-3 not sig- Presence or absence of parameter nificant ________fixed_________________Presence_of_parameter________________ NBS-9 files are NBS file directories. Flexible and Transparent Access for Local Files FTAM software treats local files the same way that the OpenVMS Oper- ating System file system treats them. File Transfers The FTAM COPY command transfers files between compatible FTAM systems without modifying the source file. The facility can transfer files in either direction between the local system and a remote FTAM system. The COPY command can also transfer files between two remote FTAM sys- tems for a local FTAM user. This command also allows you to append one or more files to a single output file within or between FTAM systems. FTAM-FTP Gateway The FTAM-FTP Gateway lets you perform file operations between OSI and Internet Systems. Remote users of the gateway do not have to estab- lish accounts on the gateway system to use its capabilities. 21 File Deletion The FTAM DELETE command can delete one or more files on any combina- tion of FTAM systems provided that the user has delete access to those files on the specific FTAM system. Renaming Requests The FTAM RENAME command allows you to rename files. The command works on files stored on remote FTAM systems (remote files). The command en- ables you to change the pathname or file name of an existing file. For remote files, you must specify whatever type of information the re- mote FTAM system requires for specifying files. Directory Requests The FTAM DIRECTORY command displays the complete set of FTAM file at- tributes. Specific options allow users to vary the display of attributes that are meaningful in an OpenVMS Operating System environment: for example, date/time of last modification of file name. FTAM File Error Recovery FTAM provides File Error Recovery functionality both in the COPY ini- tiator command and in the FTAM responder. File Error Recovery is pro- vided for Class 1, Class 2, and Class 3 type errors as detailed in ISO 8571-4. Class 1 File Error Recovery provides only the restart functionality, while Classes 2 and 3 File Error Recovery provide both the Restart and Recovery functionality as follows: o If an internal error is detected in the data transfer regime, Class 1 recovery restarts the data transfer regime by retransmitting the file data beginning at the negotiated checkpoint within the data transfer regime; o Class 2 error recovery provides for the re-establishment of the se- lect and open regimes, and also allows for the retransmission of file data beginning at a negotiated checkpoint within the data trans- fer regime; o Class 3 error recovery provides full recovery by re-establishing a lost FTAM association and its select and open regimes. Class 3 recovery will then restart the data transfer regime by retransmit- ting the file data beginning at the negotiated checkpoint within the data transfer regime. All restart and recovery operations and procedures are completely trans- parent to the user. Management and Problem Determination Tools FTAM software supplies a number of management tools, including an in- stallation verification procedure (IVP), a tracing utility, event log- ging, and informational and error messages. 22 FTAM Installation Verification Procedure (IVP) The FTAM IVP sets up outbound and inbound application associations. A connection is made to your local system (as a loopback test). The FTAM IVP checks that your installation is able to set up and release presentation and session connections. It tests the FTAM software by starting a responder and reading the attributes of a file with the DI- RECTORY command. FTAM Tracing Utility The FTAM tracing utility (ositrace) is a tool for identifying prob- lems in protocol exchanges between your local system and any remote FTAM system. The tracing utility captures protocol exchanges and tran- scribes them into easily read text. ositrace data is written to SYS$OUTPUT. The FTAM tracing utility monitors data exchanges for individual as- sociations. The tracing utility can trace data originating from the following components: FTAM (DATA, PROTOCOL, and STRUCTURING), ACSE, Presentation, and Session. OSI Address Lookup using X.500 The FTAM software is capable of retrieving network addresses from the X.500 directory. This functionality may be used in conjunction with or instead of retrieving addresses from a local repository. FTAM Event Logging For event logging, the FTAM responder writes records to OSIF$RESPONDER.LOG. Requirements for Compatibility with FTAM FTAM lets an open system perform a specific set of file transfer, ac- cess and management activities with any open system having a compat- ible FTAM implementation. The Protocol Implementation Conformance Statement (PICS) provides more information about Digital's FTAM implementation. 13 Appendix B: Virtual Terminal DECnet/OSI Virtual Terminal is Digital Equipment Corporation's imple- mentation of the ISO Virtual Terminal Basic Class standard, which is comprised of the service definition (ISO 9040) and the protocol (ISO 9041). The DECnet/OSI Virtual Terminal software adheres to these stan- dards, thereby providing interactive access between DECnet/OSI sys- tems and other multivendor terminal systems and host systems that also adhere to the ISO Virtual Terminal Basic Class standard. Virtual Terminal is implemented as an Application Service Element (ASE) of the OSI Application layer. DECnet/OSI Virtual Terminal can run over Transport Layer Classes 0, 2 or 4 over CONS, and TP4 over CLNS. DECnet/OSI Virtual Terminal can also run over TCP/IP networks using RFC1006. 23 Virtual Terminal provides Terminal/Initiator (for a local user) and Host/Responder (for the remote user) capabilities. Terminal/Responder and Host/Initiator are not supported. Supported Standards Virtual Terminal conforms to the following OSI standards: o ISO 9041 - Virtual Terminal Protocol - Basic Class o ISO 8650 - ACSE protocol o ISO 8823 - Presentation protocol o ISO 8327 - Session protocol Virtual Terminal Features Virtual Terminal supports the following features: o Class of Service o Basic class (character cell terminals) o Mode of Operation o Asynchronous Mode (A-Mode) o Profile Support o Default A-mode (as per ISO 9040) o A-mode Generalized Telnet (adheres to OIW Stable Agreements) o A-mode Transparent (adheres to OIW Stable Agreements) o A-mode Telnet 1988 (adheres to OIW Stable Agreements) o Functional Units o destructiveBreak o structuredCOs o urgentData o Supported Gateways o Bi-Directional VT/Telnet o Bidirectional VT/LAT o On-Line Help OSI Address Lookup using X.500 The Virtual Terminal software is capable of retrieving network addresses from the X.500 directory. This functionality may be used in conjunc- tion with or instead of retrieving addresses from a local repository. Command Mode Command Mode allows the user to execute commands that can modify the characteristics of the Virtual Terminal association with the remote application. 24 Trace Utility The Virtual Terminal tracing utility (ositrace) is a tool for iden- tifying problems in protocol exchanges between your local system and any remote system. The utility captures protocol exchanges and tran- scribes them into easily read text. The tracing utility monitors data exchanges for individual associa- tions. The utility can trace data originating from the VT, ACSE, Pre- sentation, and Session components. 25