(Phase III) AA-AV51A-TK

(1)

Introduction to DECnet (Phase III)

AA-AV51A-TK

May 1982

This document is an overview of the concepts and capabilities of DECnet networks. It defines DECnet terms and describes the network functions that DECnet implementations can perform.

Readers are expected to be familiar with DIGITAL operating systems.

This document has been reprinted directly from the manual Introduction to DECnet, Order No. AA-J055C-TK. Only the title page, reader's comment form and mailer have changed.

This revised document supersedes the Introduction to DECnet (Order No. AA-J055B-TK).

Software and manuals should be ordered by title and order number. In the United States, send orders to the nearest distribution center. Outside the United States, orders should be directed to the nearest DIGITAL Field Sales Office or representative.

Northeast/Mid-Atlantic Region Central Region Western Region

(2)

First Printing, May 1982

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document.

The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such license.

No responsibility is assumed for the use or reliability of software on equipment that is not supplied by DIGITAL or its affiliated companies.

The following are trademarks of Digital Equipment Corporation:

~DmDDmDTM

DEC DECmate DECsystem-10 DECSYSTEM-20 DECUS

DECwriter DIBOL

MASSBUS PDP P/OS Professional Rainbow RSTS RSX

UNIBUS VAX VMS VT

Work Processor

The postage-prepaid READER'S COMMENTS form on the last page of this document requests the user's critical evaluation to assist us in preparing future documentation.

(3)

·

^o-~

6-10 6-10 6--10

(5)

6.7 Accessing Remote Files from a Terminal 6.7.1 Access Control . . . . 6.7.2 File Protection . . . . 6.7.3 Remote File Specifications . . . 6.7.4 Remote Command File Submission

6.7.5 NFT and V AXNMS Command Examples . Chapter 7 DECnet Terminal Facilities

7.1 The TLK Utility . . . . 7.1.1 One-line Mode and Dialog Mode 7.1.2 The TLK Split Screen Option.

7.1.3 TLK Command Files. . . . 7.1.4 The PHONE Command . . . 7.2 The VMSMAIL Utility (DECnet-VAX only) 7.3 Network Command Terminal Facilities . . .

7.3.1 7.3.2

Setting Up a Command Terminal Session Issuing Commands to the Remote Node Chapter 8 Network System Management

8.1 8.2

8.3 8.4

8.5

8.6

Network Management Utilities. . Planning for Node Generation . . 8.2.1 Configuration Data Bases.

8.2.2 Network Generation Planning Aid.

Generating Network Software . . . .

Defining Configuration and Other Static Parameters.

8.4.1 Node Addresses and Names.

8.4.2 Node Verification Passwords . . . . 8.4.3 Network Object Parameters. . . . 8.4.4 Transport Parameters (Phase III nodes only) . 8.4.5 Line Identification . . . . 8.4.6 Circuit Parameters . . . . 8.4.7 Multipoint Line and Circuit Parameters.

8.4.8 Transmission Mode.

Operating a Node . . . . 8.5.1 Controlling the State of a Node 8.5.2 Controlling Physical Links Monitoring Node Activity . . . . Chapter 9 Down-line Loading and Up-line Dumping

9.1 Down-line Loading Definitions . . . . 9.2 Down-line Loading Data Base Parameters.

9.3 Performing a Down-line Load . . . . 9.3.1 The LOAD Command . . . . 9.3.2 Target-initiated Down-line Loads 9 .4 Up-line Dum ping . . . .

9.5 Down-line Loading and Checkpointing RSX-11S Tasks

6-12 6-13 6-15 6-15 6-16 6-17

. 7-1 .7-2 . 7-2 .7-3 .7-3 .7-5 .7-6 .7-8 .7-9

.8-2 .8-2 .8-3 .8-4 .8-4 .8-5 .8-5 .8-5 .8-6 .8-7 .8-7 .8-7 .8-8 8-10 8-10 8-11 8-11 8-12

.9-1 .9-2 .9-2 .9-3 .9-3 .9-4 .9-4

(6)

Chapter 10 Loopback Testing

10.1 Hardware Loopback Devices 10.2 Node Level Loopback Tests

10.2.1 Node Level Loopback Commands 10.2.2 Using Commands t.o Initiate Tests.

10.2.3 Using Programs to Initiate Tests.

10.3 Line/Circuit Level Loopback Tests . . . . 10.3.1 Line/Circuit Level Loopback Commands.

10.3.2 Examples of Line/Circuit Level Tests Appendix A DECnet Documentation

Index

Figures

vi

1-1 A DECnet Network . . . . 1-2 DECnet Implementations: Interfaces between Operating

Systems and the Network . . . . 2-1 The DIGITAL Network Architecture . . . . 2-2 Vertical Interaction of DECnet Software Modules . . . 2-3 Protocol Communication between Equivalent Modules.

2-4 Enveloping User Data in Protocol. . . . 2-5 Data Flow from Node 1 to Node 3 in a Three-node Network 2-6 Network Management: Relation to DNA

3-1 Phase II Point-to-Point Routing.

3-2 Phase III Full Routing . . . . 3-3 Phase II DECnet Configurations . 3-4 Phase III DECnet Configurations .

3-5 A Mixed Configuration: A Phase III Network Adjacent to a Phase II Star-shaped Network . . . . 3-6 Routing Terms . . . . 3-7 Components of a Public Packet Switching Network 3-8 DLM Relaying DECnet Data to PSI Software.

3-9 A DECnet Packet Nested in X.25 Protocol , , , . 3-10 Routing DECnet Data via a PPSN . . . . 3-11 RSX DECnet/PSI Nodes within a Phase III Network 4-1 Logical Link Connecting Programs BOB and CAROL 4-2 NSP Modules and Logical Links . . . . 4-3 Interrelationship of Link Identifiers and Addresses.

4-4 Programs Supporting Multiple Logical Links 5-1 Addressing Network Objects

5-2 Transmitting Normal Data.

6-1 Remote File Access . . . . 7-1 The TLK Utility . . . .

7-2 DEC net-lAS TLK Split Screen Option 7 -3 Remote Terminal Processing . . . .

10-2 10-;1 10-3 10-4 10-4 10-4 10-4 10-6

· 1-1

· 1-2

· 2-2 .2-4 .2-5 .2-7

· 2-8 .2-9 .3-2 .3-3

· 3-3 .3-4 .3-6 .3-7 3-10 3-13 3-13 3-14 3-15 .4-1 .4-2 .4-4 .4-5 .5-5 .5-8 .6-2 .7-2

· 7-4 .7-7

(7)

8-1 A Multipoint Line. .8-8

8-2 Multipoint Circuits 8-10

9-1 A Down-line Load Initiated by a Command Node. .9-2 9-2 A Down-line Load Initiated by a Target Node. .9-3

11"\ 1

Hardware Loopback Devices 10-3

J.V-J.

10-2 Command-initiated Loopback Tests. 10-5

10-3 Program-initiated Loopback Tests 10-7

10-4 Line/Circuit Level Loopback Tests 10-8

Tables

2-1 DN A Protocols. .2-4

5-1 Languages Supporting Task-to-Task Communication . 5-1 5-2 Task-to-Task Calls for DECnet-RT, RSX DECnet, and

DECnet-IAS .5-9

5-3 DECnetJE Task-to-Task Calls 5-10

5-4 DECnetJE Concise COBOL Interface Calls 5-11

5-5 DECnet-VAX Transparent Task-to-Task System Service

Calls 5-12

5-6 DECnet-VAX Nontransparent Task-to-Task System Service

Calls 5-13

5-7 MACRO-20 Task-to-Task Calls. 5-14

6-1 DIGITAL File and Record Management Systems .6-4 6-2 DECnet Remote File and Record Access Capabilities .6-5 6-3 Local Operating System File Specifications . .6-7 6-4 DECnet-RT Remote File Access Macro Calls. .6-9 6-5 Higher Level Language Remote File Access Calls

(DECnet-RT, DECnet-IAS, and RSX DECnet) . 6-10

6-6 VAX-II RMS File Access Calls. 6-11

6-7 Remote File Operations from a Terminal 6-14

6-8 Specifying Access Control Information 6-15

8-1 DECnet Systems and Network Management Utilities .8-3

8-2 Configuration Data Base Terms. .8-4

(8)

(9)

Preface

This edition of the Introduction to DECnet has been revised to reflect new versions of the following products:

RSX DECnet and DECnet-VAX

The Purposes of the Introduction to DEenet

Introduction to DECnet is an overview of the concepts and capabilities of DECnet networks. A DECnet network consists of two or more DIGITAL computer systems that have been linked together via communication lines.

Within such a network, each system runs DECnet software, which, jointly with the networking hardware, enables communication with the other systems in the network.

Although all implementations of DECnet embody the same network concepts, all do not support the same set of network functions. The specific capabilities of a DECnet network depend on the types of systems participating and on the network's application. The objectives of this Introduction are:

• To describe the major network concepts behind all implementations of DECnet

• To define the specific network functions that DECnet provides

• To identify the DECnet implementations that support each function The DECnet implementations discussed in this Introduction are:

• RSX DECnet (DECnet-llM, DECnet-llM-PLUS, DECnet-llS)

• DECnet-IAS

• DECnet-VAX

• DECnet-RT

• DECnet/E

• TOPS 20 DECnet-20

(10)

Chapter 1 What Is DECnet?

DECnet is a family of software products that enables two or more DIGITAL computer systems to form a network. Such a network can link computers that run the same operating system; more significantly, however, computers that run different operating systems can be linked via DECnet, as Figure 1-1 illustrates. The network shown consists of six systems or nodes, each of which runs a different DIGITAL operating system.

DECnet/E

and DECnet-RT

in Paris

DECnet-VAX in Amsterdam

DECnet-IAS

Figure 1-1: A DECnet Network

The DECnet implementation at each node acts as an interface between the node's operating system and the network (see Figure 1-2). On one hand, each implementation formats system-specific data and procedures according to common DECnet rules. All data traveling through a DECnet network has been formated in this way. Conversely, each recognizes the DECnet formats and converts them into formats recognizable to its own operating system.

1-1

(11)

Each implementation formats system-specific data and procedures according to common DECnet rules. Conversely, each implementation recognizes these DECnet formats and converts them into formats recognizable to its own operating system.

Figure 1-2: OECnet Implementations: Interfaces between Operating Systems and the Network

The ability to link different kinds of DIGITAL systems gives a great deal of flexibility to DECnet networks. A general characteristic of distributed processing is that 80% of computer resources are used to process local applications; work related directly to networking functions consumes only 20%.

Therefore, every system within a network must be the right system for local requirements, or else considerable computer resources will be wasted.

DIGITAL offers a variety of operating systems designed for different types of applications and computers. Because DIGITAL also offers implementations of DECnet to extend most of these systems, users can match operating systems to local applications and then tie the various systems together with DECnet.

(12)

1.1 DEenet Functions

DECnet offers a wide range of networking functions. Some, like task-to-task communication, are provided throughout DECnet, while others can be supplied only by a subset of DECnet implementations. For example, loading a system image down-line to a satellite node is a function supported by RSX, lAS, VAX, and TOPS-20 DECnets, but not by DECnet/E or DECnet-RT.

The following list identifies DECnet's major functions, which are discussed at greater length in the chapter or section as indicated. From these discussions, the reader will learn which implementations support the functions and what kind of facilities DECnet provides to perform them.

• Task-to-Task Communication (Chapter 5)

DECnet enables two programs to exchange data over a logical link set up between them. The two programs can reside in the same or in different nodes.

• Remote File Access (Chapter 6)

DECnet provides both terminal and program access to files that reside on remote nodes. Remote file access facilities allow users to perform the following operations:

Transfer files between two nodes

Manipulate files residing at a remote node, for example, open, delete, or append data to remote files

Submit files containing operating system commands to a remote node in order to gain access to that node's resources

• Terminal-to-Terminal Communication (Section 7.1)

A DECnet utility allows a terminal user to send messages to other terminals in the network.

• Remote Terminal Facilities (Section 7.2)

DECnet allows a local terminal to be connected logically to a remote node, which then executes the commands typed at that terminal.

• Network Management Facilities (Chapter 8)

DECnet provides facilities used by system managers to generate, define, monitor, and control network nodes.

• Down-line Loading (Chapter 9)

An RSX-llS node, which has no disk storage of its own, can be loaded from an adjacent RSX, lAS, VAX, or TOPS-20 node. RSX DECnet, DECnet-V AX, DECnet-lAS, and DECnet-20 nodes also support up-line dumping; that is, if the RSX-llS system crashes, it automatically sends a system-image dump up-line to the adjacent node.

• Loopback Testing (Chapter 10)

DECnet supplies tests that system managers can run to exercise various network capabilities and to isolate network problems.

What is DECnet? 1-3

(13)

When configuring a DECnet network, a system designer or manager takes into account the functions supported by each implementation. The range of functions that can be performed between any two network nodes is limited to the functions that they share. The network as a whole, however, is not limited to the functions common to all. The interaction between any two nodes is not determined by the capabilities of the other nodes in the network.

1.2 Using DEenet

DECnet provides user interfaces that are similar to those provided by DIG-

ITAL~s operating systems. To program task-to-task communication or remote file access, programmers use calls formated according to the operating system in which the program will run. Likewise, terminal users invoke DECnet utilities in a Inanner consistent with local operating system conventions. There- fore, using DECnet is similar to using purely local system functions. Never- theless, network activity does entail varying degrees of complexity, depending on the type of work being performed and on the types of nodes within the network. For example, virtually all network functions involve cooperation between two programs. If both programs are user-written, as in task-to-task communication, a programmer must ensure not only that both programs run properly in their respective nodes, but also that the communication between them proceeds as intended.

Furthermore, although DECnet enables communication between nonhomo- geneous systems, users performing such communication have to be aware of system differences. For example, DIGITAL operating systems support different file systems, a fact that has an effect on remote file access operations.

Throughout the Introduction, discussions highlight circumstances in which users must take differing system characteristics into account.

(14)

x

The Readers of the Introduction

The Introduction is intended for readers who want to learn about the concepts and capabilities of DECnet systems. It assumes that the reader is familiar with DIGITAL operating systems but not with DECnet concepts or terms.

Typical readers will include the personnel at the site of a newly installed DECnet system, who can read this manual to learn about the kind of work DECnet enables them to perform. Another group of readers will include system managers and designers who are thinking about using DECnet to expand their existing DIGITAL computer systems. And, finally, the Introduc- tion is also intended for system managers and designers who do not yet use DIGITAL systems but who are considering the implementation of a computer network. This manual will inform them about the network capabilities that nRrnpt. nroviilPQ

--~---~ r-~·----~·

The Structure of the Introduction

The Introduction contains ten chapters, which can be divided into three parts:

• The first part, Chapters 1 to 4, introduces the concepts and the general uses for DECnet.

• The second part, Chapters 5 to 7, defines specific network functions and explains the mechanisms that programmers and terminal users can employ to implement those functions.

• The third part, Chapters 8 to 10, introduces DECnet functions relating to the management of the systems (called nodes) that make up a DECnet network.

Associated Documents

This Introduction discusses many topics that are explained in greater detail in other manuals. Appendix A lists, by implementation, all the DECnet manuals and their order numbers.

(15)

Chapter 2 The DIGITAL Network Architecture

The DIGITAL Network Architecture (DNA) is the model for all DECnet implementations and the standard that allows different DIGITAL operating systems to participate in the same network. This chapter highlights features of DNA to illustrate some basic concepts of DECnet. DNA consists of layers, each of which defines a distinct set of network functions and the rules for performing them. Accordingly, each DECnet implementation consists of software modules that perform these layered network functions as DNA dictates.

The DNA model also allows for implementation of the Comite' Consultatif International T~h~graphique et TelE~phonique (CCITI) recommendation X.25. This recommendation defines a standard interface from a computer or a terminal to a public packet switching network (PPSN). DNA also defines a software interface, called Data Link Mapping (DLM), that creates a bridge between DECnet and X.25 implementations residing in the same node. DLM enables a DECnet node that includes an X.25 implementation to communicate through a PPSN to another DECnet node. (RSX DECnet includes a DLM interface to RSX-11 PSI [Packetnet System Interface], DIGITAL's implementation of the X.25 recommendation for RSX-11 systems.) Section 3.4 discusses PPSN s and the DLM interface.

2.1 The DNA Layers

Figure 2-1 illustrates the DNA functional layers. The following definitions summarize the purpose of each layer. For detailed information about DNA, see the DIGITAL Network Architecture General Description and other manuals that are listed in Appendix A.

(16)

Each layer defines a distinct set of functions as well as rules for implementing those functions.

Layers oriented to user functions

USER LAYER

---

NETWORK MANAGEMENT LAYER

---

NETWORK APPLICATION LAYER

---

^...

^- ^{- ---} ^-- ^{-- - -} ^- ----"'"

Layers oriented SESSION CONTROL LAYER to network functions - - - -

NETWORK SERVICES LAYER

---

TRANSPORT LAYER

~--..,---

Layers oriented to communication functions

DATA LINK LAYER

1 - - - - - - - - - -

PHYSICAL LINK LAYER

~--- COMMUNICATIONS FACILITIES

Figure 2-1: The DIGITAL Network Architecture

Definitions of DNA Layers

• User Layer. The User layer encompasses user-written programs and services that access the network. It is the highest layer in the architecture.

• Network Management Layer. The Network Management layer defines the functions used by operators and programs to plan, control, and maintain the operation of DECnet networks.

• Network Application Layer. The Network Application layer defines network functions used by the two higher layers. The most important DECnet functions currently operating within this layer are remote file access, file transfer, and the remote terminal capability.

• Session Control Layer and Network Services Layer. Together these layers define a mechanism that allows a program in one node to communicate with a program in another node regardless of either program's location within the network. Modules in the User layer, Network Management layer, and Network Application layer can all use the mechanism provided by the Session Control and Network Services layers. This mechanism, called the logical link, is discussed in Chapter 4.

• Transport Layer. The Transport layer defines a mechanism for tran- sporting a unit of data from one node to a specific node elsewhere in the network.

2-2 Introduction to DECnet

(17)

• Data Link Layer. The Data Link layer defines a mechanism for error-free communication between adjacent nodes. This layer is independent of communication device characteristics.

• Physical Link Layer. The Physical Link layer encompasses the software device driver for each communications device plus the communications hardware itself. The hardware includes interface devices, modems, and the communication lines.

2.2 DECnet Module Interfaces

DNA defines the interfaces between DECnet software modules operating within the same node. Reflecting the structure of DNA, each module can communicate with modules in a higher or a lower layer, but not with another module in the same layer. Using these vertical interfaces, each module uses the services provided by a module in a lower layer (see Figure 2-2). (DNA does not allow a module to use any services provided by a higher level module.) In building-block fashion, the modules in each layer support higher level modules by providing them with required network services.

Figure 2-2 illustrates a collection of modules residing in a typical DECnet node. The arrows represent the interfaces between modules. The arrows point down because each module uses the services provided by a module in a lower layer; a module cannot use services provided by a higher level module.

2.3 DNA Protocols

So far, DNA has been viewed in the context of an individual node. However, in addition to defining vertical interfaces, DNA also defines the relationship between modules in separate nodes: A module in one node communicates only with an equivalent module in another node, where equivalent means resident in the same layer and serving the same network function.

Communication between equivalent modules is governed by a set of rules called a protocol. Each protocol defines the form and content of messages to be exchanged by modules residing in the same layer, but in separate nodes.

Equivalent modules use the same protocol.

Protocols for modules in the higher layers are more complex than protocols for lower layers. For example, a Physical Link layer protocol is defined in terms of electrical signals; whereas a protocol for modules residing in the Network Application layer defines message formats and rules for exchanging messages.

Figure 2-3 illustrates protocol communication between equivalent modules in separate nodes. Table 2-1 lists and briefly describes the function of each DNA protocol.

(18)

The Network Control Program, which allows manager/operator to

monitor/control network activity

CD

A user program communicating with a

remote program

@ A user program accessing remote files

"- User

Layer

Network Management Layer

Network Appl ication Layer

Session Controll Network Services Layer

Transport Layer

Data Link Layer

Physical Link Layer

Communications Facilities

f', I

NCP Utility

\

Network

,

\

,

\

,

Management Routines

\

User Program

CD

I

\

I

/

) I

i User Program

(i)

/

,.

Remote File Access Routines

/

~

./

Session Control!

/"

/ '

Line A's Controller

1

/

LmeA (e.g., a telephone line)

NSP Module

I

j Transport

Module

t

DDCMP Module

'-...

~

Line 8's Controller

'\

\

_{Line 8}

(e.g., a cable)

,.. ,-

Figure 2-2: Vertical Interaction of DEenet Software Modules

2-4 Introduction to DECnet

(19)

I I

NODE 1 MODULES

User Program

Network Management Module

Network File Access Routines (NFARs)

NSP Module

Transport Module

DDCMP Module

Device Controller

I i

<I

PROTOCOLS

---

User Layer USER-DEFINED PROTOCOL

~--Network Management Layer

- - ---

NETWORK INFORMATION AND CONTROL EXCHANGE

PROTOCOL (NICE)

---

Network Application Layer

DATA ACCESS PROTOCOL (DAP)

---

Session Control/Network Services Layers SESSION CONTROL AND NETWORK SERVICES (NSP)

PROTOCOLS

---

Transport Layer TRANSPORT PROTOCOL

- ^- ---

Data Link Layer DIGITAL DATA

COMMUNICATIONS MESSAGE PROTOCOL (DDCMP)

---~-Physical Link Layer

ELECTRICAL SIGNALS

---

J

Comm. lines that form

I

physical connection between Node 1 and

I

^{Node 2}

I

~!

I

..

NODE 2 MODULES

User Program

Network Management Module

File Access Listener (FAL)

NSP Module

Transport Module

DDCMP Module

Device Controller

I

Figure 2-3: Protocol Communication between Equivalent Modules

(20)

DNA does not define protocols for all functional layers. For example, the User layer programs communicate over the network according to rules defined by the programmer. Furthermore, more than one protocol can be defined for the same layer because some layers support more than one function. For example, the Network Application layer can include modules that use the Data Access Protocol (DAP) as well as modules that use a protocol defined by users for a specific network application (transaction processing, for example). The protocols that DNA does define are also not exclusive; users can substitute their own protocols as long as they are implemented consistently by equivalent modules throughout the network.

Table 2-1: DNA Protocols

Protocol

NICE

DAP

NSP

Routing

MOP

DDCMP

Layer

Network Management

Network Application

Network Services

Transport

Data Link

Description

The Network Information and Control Exchange protocol defines mechanisms for exchanging network, node, and configuration data, and for servicing requests from modules residing in the Network Management layer.

The Data Access Protocol defines mechanisms for performing remote file access and remote file transfer on be- half of software modules residing in the Network Manage- ment layer (Phase III only) and the User layer. See Chapter 6.

The Network Services Protocol defines a mechanism for creating and maintaining logical links between higher level modules residing in the same node or in different nodes.

The routing protocol defines a mechanism for dispatching data to any node in the network by the best possible route. This protocol is implemented in Phase III products only. See Section 2.5 and Chapter 3.

The Maintenance Operation Protocol defines mechanisms for transmitting data over a communications channel to achieve specific functions: down-line loading of a remote node; up-line dumping from a remote node; testing a node and network connections; and starting up an unattended remote node.

The Digital Data Communications Message Protocol defines a mechanism for ensuring the integrity and sequenti- ality of data transmitted over a communications channel.

This manual refers only to DNA-defined protocols because they are standard for all DEQnet implementations. Some protocols are discussed in relation to the functions they serve. The Data Access Protocol, for example, is discussed in relation to remote file access. Further information about individual DNA protocols can be found in other DIGITAL publications. See Appendix A.

(21)

2.4 Relaying User Data through the Network

DNA LAYERS

User Layer

Before leaving its source node, user data travels down through the layers defined by DNA. A module in each layer adds control information to the unit of data it receives from above. This control information is dictated by the module's protocol. Ultimately, the user data reaches the Physical Link layer and is transmitted in a multisegmented envelope of protocol. Figure 2-4 illustrates how each module adds its protocol to the unit of data it receives from above.

- - - -

Network Application Layer

Network Services Layer

Transport Layer

Data Link Layer

,...-... ----<-..,.

\~---~,,~---~)

Complete Envelope Transmitted from One Node to an Adjacent Node

Figure 2-4: Enveloping User Data in Protocol

(22)

N I

Q)

-

o

m o ::s

CD

-

NODEl NODE 2 NODE 3

r "'" \ r ~ \ r - ~ ,

- - - - - - - - 1 - - - - - - - - - - - - - - - - - - - - - . - - - -

User Layer

Network Application Layer

r----.l:..-~..., Data from user is

DATA

enveloped in Packet Header information as it passes through' layers to the Transport Layer.

See Figure 2-4.

f - - - -

~,

[

DATA

---

DATA

---

~~

Header information removed as data pa,sses through layers to the User Layer.

DATA

.4~

- - - ---- -- - - - - -_. - - - - - -- - -- --- - - -- - - - - - - -- - - -- -- - - - - - - - ----- - - - -- ---

Network Services

Layer

Transport Layer

~,

Transport Layer receives packet

from Data Link Layer and sends

I

^DATA

it to Node 3. ii

IT _---

^DATA

-

--(-'-

^- ^- ^- ^-

-- ---

-

-- -~~---

---

~,

Transport Packet Header

DATA

- - - - - - - - - - - 1 - - - - - - - - - - - - - - - - - - - - - - - . - - - - - - - - - - - - - - - - - - -

Data Link

Data Link Layer ':::ontrol

DATA

Data Link Control

-- --- ~.: ^{;;.;; L:'} ~o-;;',: ^:d-::d: ~ ^{- - - --}

Data Link Layer. /Vode 1.

Headers and data sent from Node 1 to Node 2.

Headers and data sent from Node 2 to Node 3.

~

Data

...

^Link

I ....

Control

Transport Data

Packet DATA Link

Header Control

;;":L:' ~o-;;,:, ;:mo,: - -;.;; un,-;':,:, :;:;:i~ --- ~~ ~,~ ^:n; -;,;::;,:-,:,~,: Y --

in Data Link Layer. Node 2. Data Link Layer. Node 2. in Data Link Layer. Node 3.

Figure 2-5: Data Flow from Node 1 to Node 3 in a Three-Nodle Network

(23)

Each segment of protocol represents one module talking to an equivalent module elsewhere in the network. When the data envelope arrives at its destination node, each module reads and strips off the appropriate protocol segment and then hands the remaining data up to the next module. Figure 2-5 illustrates the process of adding and subtracting protocol as the user data travels from its source to its destination.

Note the action taken by the Transport module when the data needs to be forwarded or routed to another node. The routing mechanism is described in Chapter 3.

Physical Link Modules

User Layer

Network Management Layer

Network Application Layer

Session Control Layer

Network Services Layer

Transport Layer

Data Link Layer

Physical Link Layer

Black arrows show direct access for control and examination of parameters, counters, etc. Red arrows show interfaces between layers for normal user operations such as file access, down-line load, up-line dump, end-to-end looping and logical link usage.

Figure 2-6: Network Management: Relation to DNA

2.5 Differences between Phase II and Phase III DNA

DECnet products and the architecture on which they are based have been evolving since 1973. The basic layered structure of DNA has not changed, but new layers and protocols have been added and existing ones refined. The evolution of the architecture has coincided with the development and release of new DECnet products that incorporate up-to-date networking techniques and concepts.

(24)

The first version of DNA and the first releases of DECnet products were known as DECnet Phase I. Subsequent revisions of DNA and new releases of DECnet products are categorized as DECnet Phase II and III. Phase I products cannot participate in the same network with Phase II and Phase III products. However, with the exception of DECnet-RT. products implementing both Phase II and Phase III architecture are compatible within the same network.

The DECnet implementations described in this manual are either Phase II or Phase III products. The differences between these two product categories reflect the following changes to DNA:

• The Addition of the Network Management Layer. This layer lies between the User layer and the Network Application layer. Unlike most other layers, it has interfaces defined not only for adjacent layers but also for every other layer in the architecture, as Figure 2-6 illustrates. The multiple interfaces meet the special requirements of network system management. The functions defined by this layer allow system managers to oversee, control, maintain, and test all major facets of a network node. Phase II products also supported such functions, but in a system-dependent manner rather than in a manner dictated by DNA. See Chapter 8 for a detailed discussion of network management.

• The Revision of the Transport Layer to incorporate a routing mecha- nism more sophisticated than point-to-point. Although Transport was defined as a separate layer in Phase II DNA, the point-to-point routing mechanism it defined was sufficiently simple to be implemented by the Network Services module. Chapter 3 describes Phase II and Phase III routing mechanisms in greater detail.

• The Addition of the Session Control Layer. The Session Control layer defines local-node aspects of logical link management, whereas the Network Services layer handles the actual creation and management of logical links, which are discussed at length in Chapter 4. However, Phase III implementations include the Session Control functions within the same modules that perform the Network Service functions. In consequence, the management of logical links by Phase II and Phase III implementations is essentially the same.

(25)

Chapter 3 DECnet Routing

Routing is the function that determines the physical path or route along which data travels to its destination. In the context of routing, the unit of data to be transported is called a packet. Routing methods vary depending on the DECnet implementations operating within the network.

• Phase II implementations support point-to-point routing, which allows a node to send packets to physically adjacent nodes only (see Figure 3-1).

Adjacent nodes are linked directly by a physical line.

• Phase III implementations support full routing, which allows one node to send packets to any other node in the same network. The source and destination nodes do not need to be adjacent because each packet is routed through any nodes that fall in between them (see Figure 3-2).

• A Phase III RSX DECnet node that also includes the RSX-11 PSI (Pack- etnet System Interface) product can route packets via a public packet switching network (PPSN) to remote DECnet nodes.

Sections 3.1 through 3.3 discuss point-to-point and full routing. Section 3.4 discusses the RSX DECnet/PSI interface to a PPSN.

3.1 Phase II and Phase III Configurations

Routing capabilities affect the configuration of DECnet networks. Point-to- point routing means that the most useful Phase II DECnet configurations are hierarchical or star-shaped; examples of such configurations are shown in Figure 3-3. In contrast, Phase ill configurations do not have to be so formally structured since nonadjacent Phase ill nodes can communicate directly with one another.

(26)

Node B can exchange data with Nodes A and C, but Nodes A and C cannot exchange data with each other.

Legend:

o

⁼^node

= physical line

= logical communication path

Figure 3-1: Phase II Point-to-Point Routing

A Phase III network can include three types of nodes, which support different degrees of routing function. A node's type determines its position within a Phase III configuration.

• Routing nodes. A routing node can forward packets to other nodes in the network and can be adjacent to all other types of nodes.

• Nonrouting nodes. A nonrouting node can send packets to other nodes in the network but packets cannot be forwarded or routed through it. It can be adjacent to one other node only; therefore it is always an end node in a Phase III configuration. For example, a DECnet-RT node is always a nonrouting end node because it has only one physical link to the network.

• Phase II nodes. A Phase II node is a node that runs a Phase II implementa- tion of DECnet and therefore does not support full routing. It can send packets to adjacent nodes only and it cannot forward packets it receives onto other nodes in the network. It can be adjacent to one or more full routing nodes and/or to other Phase II nodes. Logically, it is an end node within a Phase III configuration.

Figure 3-4 illustrates configurations of nodes that support Phase III full routing. Figure 3-5 illustrates a Phase III configuration adjacent to a subnet- work of Phase II nodes.

(27)

Legend:

o

⁼^node

= physical line

= logical communication path

Figure 3-2: Phase III Full Routing

Hierarchical Star

Linked Stars

Figure 3-3: Phase II DECnet Configurations

(28)

Legend:

o

⁼Routing node

o

⁼Nonrouting node

6

⁼Phase II node

Figure 3-4: Phase III OECnet Configurations

3-4 Introduction to DECnet

(29)

Legend:

o ⁼

Routing node 0

=

Nonrouting node

6=

Phase II node

Figure 3-5: A Mixed Configuration: a Phase III Network Adjacent to a Phase II Star-shaped Network

3.2 Basic Concepts of Full Routing

This section introduces some of the concepts that underlie DECnet's implementation of full routing. The Transport layer of Phase III DNA defines both the full-routing functions and the methods to be used to implement those functions. In this discussion, the term transport module refers to the DECnet software that implements the Transport layer model.

(30)

3.2.1 Node Addresses and Node Names

Within a Phase III network, every node has a unique numeric address. A packet to be routed contains a destination node address in its header, which has been added by a Transport module (see Figures 2-4 and 2-5). The packet may arrive from the NSP module in the same node or from the Transport module in an adjacent node. As one would expect, the destination address determines where the Transport module sends the packet. Other factors, which are explained below, determine the path the packet travels to its destination.

In Phase II networks, nodes are addressed by unique alphanumeric names rather than by numbers. Because a Phase II node can send packets to adjacent nodes only~ names are practical forms of addresses - the number of adjacent nodes is limited and a data base of unique names is easily maintained. Full routing, however, greatly increases the number of reachable nodes. As a result, routing modules can handle unique numeric addresses more efficiently than node names.

On the other hand, node names are an easier form of address for network users to deal with, where users are programmers, operators, system managers, etc.

"Node DENVER" is easier to remember than "Node 27," for instance. To accommodate both the users and the transport modules, Phase III implementations of DECnet require the use of node names at the user level. These names, however, are valid only within the context of the local node; they are eventually translated into their corresponding numeric addresses, which are the only identifiers that uniquely describe all the nodes in the network.

3.2.2 Routing Terms

A path is the route a packet travels from its source to its destination. Path length and path cost, defined below, are important factors in the execution, of full routing.

• Path length. Path length is the distance from the source node to the desti- nation node, measured in hops. A hop is equal to a circuit between two nodes; (Circuits* are logical point-to-point communication paths; see Sec- tion 8.4.6.)

A path never exceeds a maximum number of hops, which is a value set by a system manager or determined by the DECnet implementation.

• Path cost. Path cost is the sum of positive integer values assigned to the circuits that compose the path: Each value is called a circuit cost.

When generating a network data base, a system manager or operator assigns a cost to each circuit defined for that node. When the node is up and running, an operator can dynamically change individual costs to higher or lower values. Altering circuit costs can change packet-routing paths.

* DECnet-IAS and DECnet-RT implementations do not support the concept of circuits. In their cases, a hop equals the physical line between two adjacent nodes.

3-6 Introduction to DEenet

(31)

Maximum path lengths and assigning costs to circuits are discussed in Sec- tion 3.3.

Figure 3-6 is an annotated diagram of a Phase III network consisting of routing and nonrouting nodes. The annotations explain the meaning of the terms path, path length, hop, path cost, and circuit cost.

Legend:

o

⁼^node

_ _ _ _ = circuit

G

⁼ci rcu it cost

0---0

⁼^hop

Node A wants to send a packet to Node D. There are three possible paths.

PATH PATH COST PATH LENGTH

@to@,@to@.@to@ (]]+(]]+rn = 7* ^{3 hops}

@to@,@to@ (]]+[1]=9 ^{2 hops}

@to@,@to®,®to@,@to@ ~+rn+[!]+~ = 11 ^{4 hops}

*7 is the lowest path cost; Node A therefore routes the packet to Node D via this path.

Figure 3-6: Routing Terms

3.2.3 Routing Algorithms and Data Bases

The Transport module in each routing node implements routing algorithms and other functions defined by the Transport layer. These algorithms determine where the Transport module sends or forwards (routes through) a packet.

One routing algorithm calculates the path length and path cost to every possible destination via every circuit defined for the node. Another algorithm then determines which circuit represents the least costly path to each destination in the network. The algorithms operate on locally available values as well as on values supplied by all adjacent nodes.

(32)

The results of these algorithms are saved in routing data bases maintained by each node. Upon receipt of a packet to be routed, the Transport module first consults the data bases to find the least costly path to the packet's destination and then sends the packet via the appropriate circuit. A packet is discarded or returned to its sender if its destination is not accessible via any circuit known to the Transport 111odule. (The sender in this context is the local NSP module.)

When a packet arrives at the next adjacent node on the path, the Transport module there also chooses the least costly path for the packet, according to the local node's routing data bases. The Transport module performs the same services for packets being routed through the local node as for packets that are starting out on their journey.

When a packet finally reaches its destination, the Transport module for that node recognizes that the destination address matches the address of the local node. The packet is then delivered to the module that implements the next higher architectural layer (the NSP module in most cases).

Each routing node executes the algorithms over and over again in response to events of different kinds within the network. For example, if a physical line somewhere in the network goes down, the routing algorithms recalculate the path length and cost to destinations affected by the line failure. An operator can also cause the algorithms to recalculate by changing the cost assigned to a circuit.

Whenever the algorithms reexecute, each node reveals the contents of its data bases to all adjacent nodes, which use that information to update their own routing data bases. In this way, changes affecting path lengths and costs ripple back and forth through the network, so that all data bases are updated to reflect the current state of the network. The rippling action stops when all the routing nodes' data bases are consistent.

3.2.4 Congestion Control

Each Transport module executes congestion control algorithms to limit the number of packets queuing up for transmission on individual circuits. One algorithm regulates the ratio of input packets to route-through packets. Input packets are those that originate from the local node. They are rejected in preference for route-through packets when a circuit's output queue starts to fill up. Another algorithm limits the maximum length of a circuit's output queue so that a single circuit cannot monopolize the available buffers.

3.2.5 Packet Lifetime Control

A packet lifetime algorithm tracks the number of nodes a route-through packet has visited and discards packets that have exceeded a predefined limit. This control ensures that packets can never loop endlessly through the network.

3-8 introduction to DECnet

(33)

3.3 Affecting Routing Operation

Although Phase III routing has been designed to operate without need of direct user intervention, system managers and operators can exercise some indirect control over routing performance. This interface to the Transport module is provided by a network management module. Such indirect control involves manipulation of maximum path lengths and circuit costs. When building a DECnet system for a particular node, a system manager can define initial values for these parameters. The values are determined after careful consideration of their effects on the loc.al node and on the network as a whole.

Subsequently, the values can be modified to improve performance or to reflect changes in the network configuration.

3.3.1 Maximum Path Length

The maximum path length parameter is used to ascertain whether or not a destination is reachable. This parameter is always set to a value equal to or greater than the longest possible path within the network. For example, if a network consists of four nodes in a ring configuration, the longest possible path within that network comprises three hops. Therefore, a destination is unreachable if it cannot be reached in three hops. Among other reasons, a node might be unreachable because it has failed or been removed from the network or because the only physical line connecting it to the network has failed.

3.3.2 Circuit Costs

Circuit cost is a representation of the real or arbitrarily imposed characteristics of a circuit. By assigning a higher or lower cost (positive integer value), a system manager may influence how much the circuit will be used - higher cost tends to cause lower traffic volume. As Section 3.2.3 explains, path cost is the sum of the individual circuit costs incurred by using the path. Because a major function of routing is to send packets by the least costly paths, individual circuit costs are important factors in routing performance.

Section 8.4.4 lists these and other routing parameters that can be defined.

3.4 OeCnet to OeCnet Routing via a Packet Switching Network

An RSX DECnet node that includes RSX-11 PSI (an RSX DECnet/PSI node) can route packets to remote DECnet nodes via a Public Packet Switching Network (PPSN). The Data Link Mapping (DLM) interface provides this routing capability. Section 3.4.1 briefly defines PPSNs. Sections 3.4.2 and 3.4.3 explain the role of DLM and how access to a PPSN can expand the topology of a DECnet network.

(34)

Legend:

-

A LEASED CI RCUIT OR DIAL-UP LINE

PUBLIC PACKET SWITCHING NETWORK (PPSN)

DCE = Data Circuit-terminating Equipment, a PPSN switching node.

DTE Data Terminal Equipment, a user computer or terminal using the PPSN.

Figure 3-7: Components of a Public Packet Switching Network

3.4.1 Public Packet Switching Networks (PPSNs)

A PPSN is a data communications service offered by the Postal Telephone and Telegraph Authorities (PTT) or common carriers of many countries. A PPSN receives packets of data to be transmitted from users of the network.

Each packet includes a header of control and destination information that the PPSN uses to route the packet to its proper destination and to deliver it in its proper sequence. The PPSN shares its transmission lines by interleaving packets from many senders. Neither the packet's sender nor its receiver can directly influence the route a packet takes to its destination.

(35)

Each PPSN consists of a number of geographically separated switching nodes that are connected by high-speed links. A circuit leased from the PTT or common carrier connects a user's computer to one of the PPSN switching nodes, while either a leased circuit or a dial-up line provides the connection for a terminal. The PPSN switching nodes are called network interfaces or Data Circuit-terminating Equipment (DCE). User computers or terminals connected to DCEs are called Data Terminal Equipment (DTE). Figure 3-7 illustrates the components of a PPSN.

3.4.1.1 CCITT Recommendations X.25, X.3, X.28, and X.29 - All DTEs use standard interfaces to the PPSN. DTEs that operate in packet mode, which include computers and intelligent terminals, use the CCITT recommendation X.25 interface. Recommendation X.25 defines the interface between the packet-mode DTE and the DCE to which it is connected. How the DCE itself functions within the PPSN is transparent to the DTEs and not relevant to X.25. To use a PPSN, non-packet-mode (character-mode) terminals require special support from the PPSN and the packet mode DTE with which it wants to communicate. CCITT recommendations X.3, X.28, and X.29 define the interfaces and mechanisms that enable such terminals to function as DTEs.

Any type or make of computer or terminal can become a DTE as long as it implements the appropriate CCITT recommendation(s). Transparently to the DTEs, the PPSN handles any differences in buffering and operating speeds of the various DTEs in the network. This transparent PPSN function and the use of the standard interfaces enable one DTE to communicate with any other DTE on the PPSN, regardless of individual type or make.

3.4.1.2 Virtual Circuits - Two DTEs communicate by means of a virtual circuit, which is a logical association set up by the PPSN either permanently or temporarily. Each virtual circuit handles the exchange of data between two specific DTEs. The DTE at each end assigns a logical channel and a corresponding channel number (LCN) to the circuit. When sending data, the DTE includes an LCN to identify the channel and corresponding circuit to which the data belongs.

When a DTE uses more than one virtual circuit at a time, the circuits are multiplexed over the physical link between the DTE and the DCE.

Virtual circuits are either permanent or temporary (switched):

• Permanent Virtual Circuits - A permanent virtual circuit (PVC) is analo- gous to a leased line between a local and a remote DTE. Either DTE can send data over the PVC at any time without issuing calls to set up or break the circuit. When a user subscribes to a PPSN, the administrators of the PPSN allocate the LCN for each PVC to be used.

• Switched Virtual Circuits - A temporary association between two DTEs is called a switched virtual circuit (SVC). A DTE sets up this type of circuit only when it wants to send data. The sending DTE assigns a channel, identifies the target DTE, and then obtains that DTE's agreement to communicate. When the DTEs have finished exchanging data, one or the other initiates a clearing sequence to terminate the SVC.

(Phase III) AA-AV51A-TK

Introduction to DECnet (Phase III)

Contents

·

Preface

Chapter 1

What Is DECnet?

1.1 DEenet Functions

1.2 Using DEenet

Chapter 2

The DIGITAL Network Architecture

2.1 The DNA Layers

---

---

---

- - --- -- -- - - - ----"'"

---

2.2 DECnet Module Interfaces

2.3 DNA Protocols

CD

\

,

,

,

\

CD

/

/

,.

/

/ '

/

t

\

I I

I i

---

- - ---

---

---

---

- - ---

---

J

I

I

I

I

..

I

2.4 Relaying User Data through the Network

-

o

-

---

---

I

IT ---

--(-'-

-- ---

-- -~~---

---

-- --- ~.: ;;.;; L:' ~o-;;',: :d-::d: ~ - - - --

...

;;":L:' ~o-;;,:, ;:mo,: - -;.;; un,-;':,:, :;:;:i~ --- ~~ ~,~ :n; -;,;::;,:-,:,~,: Y --

2.5 Differences between Phase II and Phase III DNA

Chapter 3

DECnet Routing

3.1 Phase II and Phase III Configurations

o

o

o

o

6

o =

=

6=

3.2 Basic Concepts of Full Routing

o

G

^- ^{- ---} ^-- ^{-- - -} ^- ----"'"

- ^- ---

IT _---

-- --- ~.: ^{;;.;; L:'} ~o-;;',: ^:d-::d: ~ ^{- - - --}

;;":L:' ~o-;;,:, ;:mo,: - -;.;; un,-;':,:, :;:;:i~ --- ~~ ~,~ ^:n; -;,;::;,:-,:,~,: Y --

o ⁼