Digital 's VT implemen tation provides both initiator and responder capabil ities. In addition to describ ing the features of the implementation, this section compares the VT protocol with other network ter minal protocols.
Initiator and Responder The VT implementation for both the U LTRIX and the OpenVMS systems pro vides the capability to act as either an initiator (a terminal implementation) or a responder (a host implementation). The initiator is responsible for establishing an association with the responder based on information provided by the user, such as
1 1 4
the desired profile. The responder is responsible for accepting the peer association request and for creat ing an interactive context for the remote peer user. On the OpenVMS system, the VT protocol initia tor is invoked by the DCL command SET HOST/VTP; on the ULTRJX system, the VT protocol in itiator is invoked using the ologi.n command.
Implementation Features The VT implementa tion uses the OSAK interface out! ined ea rlier in the paper. The goals of the VT implementation were to provide a highly portable, very efficient, and easily extensible code.
To achieve the goal of portabil i ty, the implemen tation was divided into two major components: interface to the OS! environment and the non-OSI interfaces (e.g. , to terminals). The OS! component is completely portable to mu ltiple platforms. The non-OSJ component is platform specific and must be rewritten for each unique platform. The inter face between these components consists of six basic fu nctions, which must be supported on all platforms.
• Attach/detach-to attach and detach the non OSI environment
• Open/c lose-to open or close a specific connec tion into the non-OSI environment
• Read/write-to read or write data between the OS! and the non-OSI environments
Because each function is simple and clearly defined, the amount of platform-specific code required for implementation is minimal . For exam ple, t he read function on the U LTRJX implementa tion is only 10 lines of code. The implementation is therefore highly extensible to different platforms. Performance of the VT protocol implementation is enhanced by using preal located buffer pools. This approach to buffer management el iminates the overhead of dynamically allocating buffers.
Our VT protocol implementation not only implements the ISO VT protocol but a lso provides a gateway to and from other terminal protocol envi ronments. We provide gateways to TELNET and to the Local Area Transport (LAT) on both the OpenVMS and the ULTRIX versions. Jn addition, we have a VT;com mand terminal (VT/CTERJ\1) gateway on the ULTRIX version.
Comparison of the VT Protocol with Other Network Terminal Protocols Most comparisons with network terminal protocols deal with echo
An implementation of the OSi Upper Layers and Applications
response time, that is, how long it takes for a char acter to echo to a display after being typed a t the keyboard. YT, like TELNET and CTERJVI, can operate in two different echo modes: remote, where the echo is achieved by means of the remote host; and loca l , where the echo is accompl ished through the local host. A number of factors contribute to response time in a remote echo situation. including protocol overhead and l ine speed. TELNET has little protocol overhead; in fact, for most situations, transferring normal data requires no additional overhead. VT protocol overhead is approximately 30 to 1 for a typical A-mode profi le, that is, 30 octets
are required to carry 1 octet of user data. VT over head may seem excessive when compared with TELNET. However, the VT protocol provides many additional capabilities that TELNET does not, such as the abi l ity to accurately model different terminal environments. Additional ly, the 30 octets of over head does not increase significantly when larger amounts of user data are transferred .
The largest gains for the VT are in the area of S-mode profiles. S-mode profiles enable most char acter echoing to be done locally By using an appro priate S-mode profile, the VT implementation can provide sophisticated local terminal operations. Thus, it is possible to edit an entire screen of text ancl then to transmit it a l l at once to the remote host. The ability to process large amounts of termi nal input as batch jobs has many advantages, includ ing reduced network bandwidth requirements, reduced CPU requirements of the remote host (since the remote host is no longer involved in char acter echo), and i ncreased user satisfaction (since users experience no network delays for character echo).
Summary
Goals common to the OSAK, FTAM, ami YT protocol projects included good performance and portabil ity of implementation. Perform ance is especially important for OSAK, because it supports all other OS[ applications. Maxim izing the use of common
code and reducing system dependencies in the three projects significantly reduced the engineer ing effort to port an implemen tation from one p lat form to another. This savings in human resources is necessary, given the growing set of hardware and operating platforms supported by Digital. Equally important is the integration of OS! applications with
their non-OSI cou nterparts, for example, the ocp and ologin functions and the protocol gateways.
Digital Techuicttljournal Vol. 5 No. J Winter 1993
Ack
nowledgments
The authors wou ld l ike to thank their colleagues for reviewing previous drafts of this paper. In particu lar, we wou ld like to thank Chris Gunner and Nick Emery, who were instrumenta l in revising the OSAK API, and the OSAK team, who converted the
advanced development code into the product.
References
1 . ]. Harper, "Overview of Digital's Open Net working," Digital Technical jo urnal, vol. 5, no. 1 ( Winter 1993, this issue): 12-20.
2. L. Yet to et a l . , "The DECnet/051 for OpenVMS Version 5.5 Implementation," Digital Technical jou rnal, vol . 5, no. 1 ( Winter 1993, this issue):
21- 33.
3. P Lawrence and C. Makemson, "Guide to ISO
Virtual Terminal Standards," Information Tech nology Standards Unit (UK), Department of
Trade and Industry (March 1988).
Genera/ References
lnfonnation Processing Systems, Open Systerns Interconnection, Part 1: Basic Reference Model
(International Organization fo r Standardization, reference no. ISO 7498-1 , 1984).
Information Technology, Open Systems Intercon nection: Connection Oriented Session Service Definition (International Organization for Stan dardization, reference no. ISO 8326, 1987).
Information Technology, Open .�ystems intercon nection: Connection Oriented Session Protocol Definition ( International Organization for Stan dardization, reference no. 150 8327, 1987).
Information Processing -�)'Stems, Open .�ystems Interconnection, File Transje1; Access, and Man agement: Part 1, General Introduction; Part 2, Virtual File Store; Part
3,
File Service Definition; Part 4, File Protocol .'ijJecification; and Part 5, Protocol Implementation Conformance State ment Proforma ( International Organization for Standardization, reference no. ISO 8571, 1988).information Processing Systems, Open Systems Interconnection: Seruice Definition for the Associ ation Control Service Elem ent (International Organization for Standardization, reference no. ISO 8649, 1988).
DEC net Open Networking
information Processing Systerns, Open Systems Interconnection: Protocol Specification for the Association Control Service Element (Interna
tional Organization for Standardization, reference no. ISO 8650, 1988)
Information Processing Systems, Open 5j,stems Interconnection: Connection Oriented Presenta tion Service Definition (International Organization for Standardization, reference no. ISO 8822, 1988).
Information Processing Systems, Open 5)stems Interconnection: Connection Oriented Presenta tion Protocol Specification (International Organi zation for Standardization, reference no. ISO 8823, 1988)
Information Processing Systems, Open Systems Interconnection: Spenfication of Abstract Syntax Notation One
(ASN. l)
(International Organization for Standardization, reference no. ISO 8824, 1987).1 I 6
Information Processing Systems, Open Systems Interconnection: Specification of Basic .Encoding Rules fo r Abstract Syntax Notation One
(ASN. l)
( International Organization for Standardization, reference no. ISO 8825, 1987).
Information Technology, Open .s:vstems Intercon nection: Virtual Terminal Basic Class Service
(International Organization for Standardization , reference no. ISO 9040, 1990).
Information Technology, Open 5)stems Intercon nection: Virtual Terminal Basic Class Protocol
(International Organization for Standardization, reference no. ISO 9041, 1990)
Information Processing Systems, Open Systems Interconnection: Application Lc�yer Structure
(International Organization for Standardization, reference no. ISO 9545, 1989).
Network Management
Mark W. Sylor Francis Dolan David G. Shurtleff
DECnet/051 Phase V incorporates a new network management architecture based on Digital's Ente1prise Manage1nent Architecture (El11A). The ElltlA entity model was developed to manage all entities in a consistent manner, structuring any manage able component regardless of its internal comple.:'(ity. The DNA CMIP management protocol was developed in conjunction with the model to express the basic concepts in the entity model. Phase V network management is extensible; the Phase V management architecture transparently assimilates new deuices and technolo gies. Phase V was designed to be em open architecture. Management ofDECnet/051 Phase V components is effective in a multi vendor network.
Network management has been an in tegral part of DECnet since 1976 when Phase I I was cleveloped . 1 Even at that early stage of the DECnet architecture, an effective management capabil ity was recognized as an essential part of an organized approach to networking. Now in DECnet Phase V, the DECnet network ma nagement architecture has undergone a major revision based on Digital's Enterprise Management Archi tecture (EMA). This paper gives an overview of some of the key features and func tions of EMA and of DECnet Phase V network man agement. See the "Overview of D igital's Open Networking" paper in this issue for an overview of the guiding principles, background, and architec ture of DECnet Phase V2
Our initial work on Phase V indicated that changes were needed i n the network management