Digital PDFs

AA-X439A-TK

December 1983

160 pages

Original

2.0MB

Document:	DECnet Digital Network Architecture Phase IV NSP Functional Specification
Order Number:	AA-X439A-TK
Revision:	000
Pages:	160
Original Filename:	http://decnet.ipv7.net/docs/dundas/aa-x439a-tk.pdf

OCR Text

DECnet Digital Network Architecture
Phase IV
NSP Functional Specification
Order No. AA-X439A-TK

DECnet Digital Network Architecture
Phase IV
NSP Functional Speclficatlon
Order No. AA-X439A-TK

December 1983
This document describes the NSP architecture, which models that part
of the DECnet software that supports the creation and destruction of
logical links, error control, and flow control. NSP is the protocol of the
End Communications layer. The End Communications layer is part of the
Digital Network Architecture.

SUPERSESSIONIUPDATE INFORMATION: This is a new manual.
VERSION:

4.0.0

To order additional copies of this document, contact your local
Digital Equipment Corporation Sales Office.

digital equipment corporation maynard, massachusetts

First Printing, December 1983

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 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.

The following are trademarks of Digital Equipment Corporation:

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COMTEX
DDT
DECCOMM
ASSIST-11
VAX
DECnet
DATATRIEVE

DECsystem-10
DECtape
DIBOL
EDL-SYSTEM
FLIP CHIP
FOCAL
INDAC
LAB-8
DECSYSTEM-20
RTS-8
VMS
IAS
TRAX

MASSBLS
OMNIBLS
OS/8
PHA
RSTS
RSX
TYPESET-8
TYPESET-11
TMS- 11
ITPS-10
SBI
PDT

Distributed Systems Publications typeset this manual using DIGITAL'S
TMS-11 Text Management System.
I

MGTPEALL

Page 3

Table of Contents
CONTENTS

INTRODUCTION
5
FUNCTIONAL DESCRIPTION
6
Designscope
I
Relation to DIGITAL Network Architecture . . . . . 7
Routing Characteristics
10
BasicNSPConcepts
11
Logical Links And Ports
11
Port And Logical Link States
12
Logical Link Identification
12
DataFlow . . . . . . . . . . . . . . . . . . 12
Messages
15
Major NS? Functions
18
Establishing And Destroying Logical Links .
18
Error Control
20
FlowControl . . . . . . . . . . . . . . . . . 23
Normal Data Flow Control
23
26
Interrupt Data Flow Control
Segmentation And Reassembly Of User Messages . 26
Functional Components . . . . . . . . . . . . . 27
Data Bases And B u f f e r - Pools . . . . . . . . . 23
Modules . . . . . . . . . . . . . . . . . . . d SnJ
NS? INTERFACES . . . . . . . . . . . . . . . . . . 31
SessionControl Interface
32
Network Manaqerr.ent Interface
33
Routing Interface
-:o
NSPSTATES
18
Portstates
43
Logical Link States
53
NSP DATA BASES AHD BUFFER POOLS
57
57
NSP's Internal Data Base
Session Control Port Data Base
53
Reserved ?ort Data Base
63
N o d e D a t a B a s e . . . . . . . . . . . . . . . . . 63
Buffer Pools
0%
DETAILED FUNCTIONAL MODEL
65
Interface Routines
67
ReceiveDispatcherMod'~1e
72
T

. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . ..
. . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . .
IndextoRoutines
. . . . . . . . . . . . . . . 75
Receive Processes . . . . . . . . . . . . . . . 77
Connect/Disconnect Receive Processes . . . . . 77
Data Receive Processes . . . . . . . . . . . . 81
Reserved Receive Processes . . . . . . . . . . 89
1 ^

ReassemblyModule . . . . . . . . . . . . . . . 89
Transmit Processes . . . . . . . . . . . . . . . 91
Connect/Disconnect Transmit Processes . . . . 91
Data Transmit Processes
94
Reserved Transmit Processes . . . . . . . . . 101
Transmit Format Module
102
107
Segmentation Module
Transmit Allocation Module
108
ALGORITHMS . . . . . . . . . . . . . . . . . . . . 109
109
Data Segment Retransmission
Other-Data Handling
109
Retransmission Timer Value Estimation . . . . . 110
Inactjvity Tirninq . . . . . . . . . . . . . . . 112

. . . . . . . . . . .

. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . .

Table of Contents

Page 4

. . . . . . . . . . . . . . . 112
. . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . 113

Confidence Testing
MESSAGEFORMATS
Message Format Notation
General Message Format
Data Messages
Data Segment Message
Interrupt Message
Link Service Message
Acknowledgment Types
Data Acknowledgment Message
Other-Data Acknowledgment Message
Connect Acknowledgment Message
Control Messages
No Operation Message
Connect Initiate And Retransmitted Connect
Initiate Messages
Connect Confirm Message
Disconnect Initiate Message
Disconnect Confirm Message

. . . . . . . . . . . . . 115
. . . . . . . . . . . . . . . . . 116
. . . . . . . . . . . . . 117
. . . . . . . . . . . . . . 119
. . . . . . . . . . . . . 121
. . . . . . . . . . . . . . 124
. . . . . . . . . 124
. . . . . . 126
. . . . . . . . 127
. . . . . . . . . . . . . . . . 128
. . . . . . . . . . . . . 128
. . . . . . . . . . . . . . 129
. . . . . . . . . . . 131
. . . . . . . . . . 133
. . . . . . . . . . 134

APPENDIX A

LOGICAL LINK ADDRESS ASSIGNMENT/DEASSIGNMENT
INTERFACE TO THE ALGORITHM
DATASTRUCTURES
ALGORITHMOPERATION

. . . . . . . . . . . . A-1

. . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . . A-3

APPENDIX B

SEGMENTATION MODULE EXAMPLE

. . . . . . . . . . . . . . . . . B-1
. . . . . . . . . . . . . . . . . . . . B-2

DATASTRUCTURES
OPERATION
APPENDIX C

REASSEMBLY MODULE EXAMPLE

. . . . . . . . . . . . . . . . .

C-1
DATA STRUCTURES
OPERATION . . . . . . . . . . . . . . . . . . . . C-2
APPENDIX D

TRANSMIT ALLOCATION MODULE EXAMPLE

. . . . . . . . . . . . . . . . . D-1
. . . . . . . . . . . . . . . D-1
. . . . . . . . . . . . . . . . . . . . D-1

DATA STRUCTURES
PRIMITIVEFUNCTIONS
OPERATION
APPENDIX E

REVISION HISTORY

APPENDIX F

GLOSSARY

Page 5
1.0

INTRODUCTION

This document describes the structure, functions, interfaces, and
messages of NSP, the protocol of the End Communications Layer. The
End Communications Layer is that part of the DIGITAL
Network
Architecture (DNA) that models the software (or hardware) enabling the
creation and destruction of logical communication links, data flow
control, end-to-end error control, and the segmentation and reassembly
of messages.
DIGITAL Network Architecture is
the
model
on
which
DECnet
implementations are based. A DECnet network is a family of software
modules, data bases, and hardware components used to tie DIGITAL
systems toaether for resource sharing, distributed computation or
remote system communication.
DNA is a layered structure. Modules in each layer perform distinct
functions.
Modules within a single DNA layer (but typically in
different computer systems) communicate using specific protocols.
Modules in different layers (but typically in the same computer
system) interface using subroutine calls or a system-dependent method.
In this document interfaces are des-ribed in terms of calls to
subroutines.
This specification describes Phase IV NS? architecture. In Phase 1 1 ,
an earlier version, Session Control was part of NSP. With Phase 1 1 1
and Phase IV, Session Control has been lcqically separated from NSP,
and the interface between the two layers iefined. The Session Control
Layer is described in a separate functional specification.
The
Routing specification, also a part of tr-.e Phase I 1 NSP specification,
has been greatly expanded in Phase 1 1 1 and Phase IV and is contained
in
a
separate Routing specification.
Appendix E details the
differences between Phase 1 1 1 and Phase 71 NSP.
A glossary at the end of this document defines many NSP terms.
This
document
assumes
that
the
reader is familiar with computer
communications and DECnet. The primary audience consists of those who
implement DECnet systems;
however, file document may be useful to
anyone interested in the details of DECnet structure.
The other
current DNA functional specifications are:
Data Access Protocol (DAP) Functional
DNA 5.6.0, Order No. A A - K ~ T K

Specification, Version

DNA DiqiFal Data
Communications
Message
?I-otocol (DDCMP)
Functional ~ p e c i f i a t i o n ,~ e r s f n n4.1.0, order No. AA-K175A-TK
Data Link Functional Specification, Version
DNA Ethernet --

1.0.0,

Order No. AA-Y298A-TK

DNA Ethernet Node Product Architecture
1.0.0, Order No. AA-X440A-TK

Specification, Version

DNA Maintenance Operations Functional
NO. AA-X436A-TK

Specification,

3.0.0, Order

Version

Page 6

Introduction
DNA Network Management Functional Specification, Version
-

4.0.0,

DNA Routing Layer Functional Specification, Version
-

Order

Order No. AA-X437A-TK

2.0.0,

NO. AA-X435A-TK

DNA Session Control Functional S~ecification,Version 1.0.0, Order
NO. AA-K182A-TK

- A Local Area Network - -Data Link kayer and Physical
The Ethernet a y e
Specifications, Version
Xerox), Order No. AA-K759B-TK

2.0, (Digital,

Intel,

and

The DECnet DIGITAL Network Architecture (Phase Iv) General Description
Order
No.
AA-N149A-TC)
provides an overview of the network
architecture and an introdu~tion to
each
of
the
functional
specifications.

2.0

FUNCTIONAL DESCRIPTION

NSP performs the following functions:
1. Enahles the creation and destr~ction of virtual channels
(logical links) that can be used for sending messages within
a network node and between network nodes.
2. Manaqes the movement
transmit buffers to
mecnanisms.

of interrupt and normal data from
receive buffers, using flow control

3. Breaks up normal data messages into portions (segments) that
can
be transmitted individually, and reassembles these
segments in their correct order after they have
been
transmitted.
4. Guarantees the delivery of data and control messages to a
specified destination by means of an error control mechanism.

Section 2 is an overview of NSP, covering the following topics:
o

Design scope (Section 2.1)

Relation of NSP to the DIGITAL Network
2.2)

Routing characteristics (Section 2 . 3 )

-0

Basic concepts (Section 2 . 4 )

Messages (Section 2.5)

Major functions (Section 2.6)

Architecture

(Section

Page 7

Functional Description
o

2.1

Functional components (Section 2.7)

Design Scope

NSP satisfies these following design requirements:
1.

Compatibility. NSP version 4.0 is compatible with previous
versions of NSP except for those differences described in
Appendix E.

Performance. NSP allows an implementation to perform without
deadlocks while using dynamic buffer pools.

Prom~tness. NSP minimizes the delays incurred in moving data
from one Session Control module to another.

Efficiency. NSP minimizes the communications overhead
examgle, line bandwidth) consumed by the protocol.

(for

Extensibility. NSP accommodates additional functions in
future, leaving earlier functions as a subset.

the

Fairness. I f more than one logical link is established to
the same destination at the same time, NSP assures that each
provides useful communication services'.

Elasticity. NSP allows an implementation to trade memory
resources (both algorithm complexity and buffer pool sizes)
for performance.

The following are not within the scope of Phase IV NSP:

2.2

Maximum throughput. NSP will not
throughput of a logical link.

necessarily

maximize

the

Uniform service. NSP will not guarantee the same average
throughput and average delays over two logical links from a
common source to a common destination.

Relation to DIGITAL Network Architecture

Figure 1 shows the relationship of the End Communications Layer to the
DNA hierarchy.
Each layer in DNA consists of functional modules and
protocols.
Generally, modules use the services of the next lowest layer. In this
document the service relationship is demonstrated in the way the
interfaces are modeled -- as calls to subroutines.
Note, however,
that the Network Management Layer interfaces directly with each of the
lower layers. Also, all the layers above Session Control interface

Functional Description
directly with it.
In fact, the
referred to as the "end user."

Page 8
upper three layers are sometimes
4

Modules of the same type in the same layer communicate with each other
to provide their services. The rules governing this communication and
the messages required constitute the protocol for those modules.
Messages
are typically exchanged between equivalent modules in
different nodes. However, equivalent modules within a single node can
also exchange messages.

Page 9

Functional Description

.------------> ! Data Link Modules
I

..........................

------------ > ! Physical Link Modules

--------------------------T

Figure 1.

.........................

NSP Relation to DNA

A brief description of each layer follows in order from the highest to
the lowest layer:
1.

User Layer. The highest layer, the User Layer supports user
services and programs. Programs such as the Network Control
Program, which interfaces with the Network Management Layer,
and file transfer programs, which interface with the Network
Application Layer, reside in the User Layer.

Page 10

Functional Description
2.

Network Management Layer. The Network Management Layer is
the only one that has direct access to each lower layer for
control purposes. Modules in this layer provide user control
over and access to network parameters and counters. These
modules also perform up-line dumping, down-line loading, and
testinq functions.
Network Application
Layer.
Modules
in
the
Network
Application Layer support network functions, such as remote
file access and file transfer, used by the User and Network
Management Layers.

Session Control Layer.
The Session Control defines the
system-dependent aspects of logical link communication, which
allows messages to be sent from one node to another in a
network.
Session Control functions include name to address
translation, process addressing, and, in some
systems,
process activation and access control.

End Communications Layer.
The
defines
the system-independent

End Communications Layer
aspects of logical link

communication.
6.

Routing Layer. Modules in the Routing Layer route messages,
called packets, between source and destination nodes.

2.3

Data Link Layer. The Data Link Layer defines the protocol
concerning data integrity and physical channel management.
Physical Link Layer. The Physical Link Layer encompasses a
part of the device driver for each communications device plus
the communications hardware itself.
The hardware includes
interface devices, modems, and the communication lines.

Routing Characteristics

NSP interfaces directly with the Routing Layer for its services.
Routing is a datagram delivery service to NSP. A datagram is a block
of data sent intact from one DECnet node to another.
Routing sends
datagrams in packets.
NSP expects Routing to have the following
characteristics:
1.

Routing will accept a datagram at least as large as 230 8-bit
bytes.

There is an extremely low probability that Routing will:

Duplicate a datagram

Deliver a datagram to the wrong destination

Change the data in a datagram

Routing may fail to deliver a datagram.

Functional Description

2.4

Page 11

Routing may fail to deliver datagrams to a given destination
from a qiven source in the order they were transmitted.

Datagrams delivered to a qiven destination from a given
source undergo a variable delay while under the control of
Routing. However, this maximum delay is bounded.
Datagrams
not delivered within the maximum delay will not be delivered.

Basic NSP Concepts
--

This section describes
understanding of NSP.

concepts

that

are

fundamental

Logical links and ports (Section 2.4.1)

Port and logical link states (Section 2.4.2)

Logical link identification (Section 2.4.3)

Data flow (Section 2.4.4)

2.4.1 Logical -Links And Ports - NSP provides a logical link service
to Session Control.
A logical link is a virtual connection between
two Session Control modules, either between two nodes or within one
node. The connection enables controlled communication between network
nodes. A pair of Session Control modules may have more than one
logical link between them.
Each logical link is separate from all
other logical links.
Each logical link must have a port at each end. A port is an area in
memory, generally in a dedicated or shared pool, that contains control
variables for managing logical links.
Table 4 in Section 5.2
Each node on a network
specifies these variables. NSP manages ports.
has a number of available ports. In forming a logical link, one port
is associated with another.
When Session Control requests a logical link or requests that a port
be opened to receive an incominq connect request, NSP allocates a port
if sufficient resources are available. When session Control requests
that a port be closed, NSP deallocates the resources associated with
the port. Deallocation usually occurs after Session Control requests
a logical link disconnection.
NSP also maintains a "confidence" variable in each port that has been
opened.
Session Control has access to this information, which is
useful in detecting network failures.

Functional Description

Page 12

2.4.2 Port And Logical Link States - Each end of a logical link is in
one o f a s e t o f states at any time. In other words, each port has a
state.

The states at one end of the link affect the states at the other end
of the link'. In this document the possible link states at one end of
a link are called the port states. The logical link states are the
combination of possible states at both ends of the logical link.
Every logical link has its own set of logical link states.
Session Control requests and NSP messages determine the particular
states and state transitions of the logical link. NSP manages these
state changes, based on the particular requests and messages it
receives.
Section 5 details all the normal port and logical link
states and state transitions.

2.4.3 Logical Link Identification - In order for two NS? modules to
manage a given logical link, each NSP module must be able to identify
the link.' The logical link identification consists of the port
addresses at each end of the link.

Each NSP module assigns a 16-bit numerical address to its end of a
logical link. The port at one end of the link contains the address of
the port at the other end of the link and vice versa. This is the way
in which the two ports are associated with each other. The complete
identification of the link, identifying both ends of the link, is
therefore a 32-bit number.
To avoid using the same number to identify two different links, an NSP
module refrains from assigning a 16-bit address it used for a previous
b u t now disconnected) link to a new link as long as possible.
The
probability that each of the two NSP modules reassigns its 16-bit
address and that these two addresses are paired a second time during a
connection process is extremely low. Therefore, the probability that
the same 32-bit identification would exist for two different links is
very low.
This ensures that there will be no cross-talk between
links.

Data Flow - After a logical link is established, data may flow
in b o t d i z i o n s (full-duplex) from transmitting Session Control
transmit buffers through the network to receiving Session Control
receive buffers.
The size of the buffers at each end of the link is
implementation-dependent.
However, the data flowing through the
network is always handled the same way. The NSP interface to Session
Control takes Session Control data provided in DATA-XMT calls (Section
3.1).
It then transforms the data to a network form. At the other
e n d o f the link the receiving NSP interface, responding to Session
2.4.4

Functional Description

Page 13

Control DATA-RCV
calls, transforms the data from its network form L C
its receive buffer form. The mechanisms NSP uses to handle da-a 2r-e
transparent to Session Control. From Session Control's vievpoir,z,::.- f-J
data flow is as shown in Figure 2.
This figure shows Session Control data transformed from a t r a n ~ r n i t t i , ~ ~
Session Control to a transmitting NSP and then transformed back frcr 2
receiving NSP to a receiving Session Control. The NSP data does p . 2 ~
actually move t.irough the network as shown.
(The DNA GeRoral
Descri tion shows how Routing packets actually move through tne

,zx&-j-

Functional Description

Page 14

Transmitting Node

................................
I
\
I

TRANSMITTING
SESSION CONTROL

Figure 2.

NSP
1
Interface I

Model of Data Flow as Seen by Session Control.

Functional Description

Page 15

The transmitting NSP appends the end-of-message (EOM) flags (Figure
2 ) , to the data in the network form. The receiving NSP module removes
these flags, places only data in the Session Control receive buffers,
and then informs the receiving Session Control via a flag in a
returned receive buffer whether an EOM was received.
Section 3.1
details this procedure.
Throughout the data flow process, NSP preserves data order.
NSP
places data bytes from a single transmit buffer into the network form
in the same order as they were in the buffers.
NSP also guarantees
Section 3.1 details the data flow
that no data will be lost.
procedure.

2.5

Messages

In order to provide logical link service, flow control and error
control (thereby supporting the Session Control interface), NSP
modules in different nodes must communicate. They do so by sending
and receiving NSP messages.
The NSP protocol consists of these
messages and the rules governing their exchange.
There are three types of NSF messages:
o

Data messaaes

Acknowledgment messages

Control messages

Table 1 summarizes the functions performed by each
Section 8 describes the message formats in detail.

NSP

message.

Functional Description

Page 16

Table 1
NSP Messages

1 Type

1 Message
......................................................................

1 Data
1
I
I
1
I

1 Data Segment
1
I
1
1
I

1 Acknowledgment

1 Description

1 Carries a portion of a Session 1
I Control
message.
(This has 1
I been passed to Session Control I
1 from
higher DNA layers and 1
I Session Control has added its I
I own control information.)
I
+----------------+-----------------+--------------------------------+

1
1
1

I
1
1
I

I
1

Data
1' Acknowledgment
1

I Acknowledges receipt of either
I a Connect Confirm message or
I one
or
more
Data Segment
I messages, and optionally
an
I Other Data message.

1
1
I
I

\-----------------+---------------------------------+

1 Other Data
1 Acknowledges receipt of one or
1 Acknowledgment I more Interrupt, Data Request or
I
1 Interrupt Request messages.
I-----------------+------------------___------------+
1 Connect
I Acknowledges
receipt
of
a
1 Acknowledgment I Connect Initiate message
or
1
I Retransmitted Connect Initiate
I
I message.

+----------------+------------.-----+---------------------------------

t o be continued)

I
i

1
I

I
I
I
+

Functional Description

Page 1 7

Table 1 (Cont.)
NSP Messages

I Control

I
I
I

1 Disconnect
I Initiate

1 Carries a logical link connect I
I rejection or disconnect request I
I
I from a Session Ccntrol module. I
I-----------------+---------------------------------+
1 No Resources
1 Sent when a Car-nect Initiate I
1
1 message
o r
Retransmitted 1
I
I Connect Initiate message) is I
I
I received
and
:here are no I
1
1 resources to establish a new 1
I
1 port (also called Disconnect I
I
I Confirm message).
I

~ + - - - - - - - - - - - _ ~ _ ~ - _ - - ~ - _ ~ - - - - - - - - - - +

1 Disconnect
1 Complete
1

1
1
1
I

Acknowledges the receipt of a 1
Disconnect
Init :ate
message I
(also called Disconnect Confirm I
message).
I

Functional Description
2.6

Page 18

Major NSP Functions

This section summarizes the operation of the major NSP functions which
include:
1.

Establishing and destroying logical links (Section 2.6.1)

Error control (Section 2.6.2)

Flow control (Section 2.6.3)

Segmentation and reassembly of user
2.6.4)

data

messages

(Section

- Destroying Logical Links - A source NSP and a
2.6.1 Establishing And
destination NSP exchanqe messaaes to establish and destroy (in other
words, to connect and disconnect) logical links. Figures 3 through 7
summarize the message exchanges. The calls in capital letters under
Session Control headings are names of interface functions as des'cribed
in Section 3.1. The message exchanges below will take place correctly
in an implementation, if the algorithms in Section 4 are followed.
1
Source
I-------------------------------I Session
I
1 Control
1 NSP
I-------------------------------i
I
1 CONNECT-XMT -->Connect
1
I
Initiate
I
I
I
I
I

I
I
1

1
I
I
1
I
I

1
Destination
I.--------------------------I
1
NSP
I--------------------------I

I
I

1
I

------------- >
<------------

I
I

<------------

1
1
1
1 Data
I
I
1 Acknowledgment --------- >
I
I
I

Figure 3

I
I
Session I
Control !
I
1
I
I

I
Connect
I
I
Acknowledgment !
I
I
I
Connect
I
I
confirm<-------- ACCEPT 1

Connection with Acceptance

Functional Description

Page 19

1 Disconnect

Complete

I
Ã‘--------Ã‘---Ã‘-----

Figure 4

I
Source
I------------------------------I Session
I
1 Control
1 NSP
'

I------------------------------I
I
I CONNECT-XMT -->Connect
I
I

I
I

1
1

<-----------_

I
I

1
I

Acknowledgment I

I
I
Disconnect
I
I
Initiate<------- REJECT 1
1
1

------------ >
I
I
I ...........................
I

Figure 5

I
1

Connection with Rejection

I--------------------------

Destination

I
1

NSP

I
I-------------------------I
I
--------------- >
Initiate
I
I
I
I

----____-----------------rf_-----'

<--------------

No Resources

I
I

Session I
Control 1
I

I
1

I
I

I
I
I
I

'--------------------------'

Connection Attempt with No Resources

Page 20

Functional Description

Figure 6

Connection Attempt with No Communication

I
Source
I------------------------------I Session
I
1 Control
1 NSP
I------------------------------I
I
1 CONNECT-XMT -->Disconnect
I
I
Initiate
I
I
1
1
I
I
I
I
\-------------------------------'

1
I
I
I
I
I

1
Destination
I-------------------------I
1
NSP
I-------------------------I

I
I

--------------- >
<--------------

Figure 7

Disconnect
Complete

I
I

Session I
Control I
I
I
I
1
I
I
I
I
I
I
1
I
I
I
I

..........................

Disconnection

2.6.2
Error Control - r^SP uses a basic acknowledgment mechanism to
ensure that messages are delivered. NSP does this for each of.the
four data messages listed in Table 1, Section 2.5.

On a logical link, the four data messages can be thought of as moving
in two subchannels.
One contains Data Segment messages, the other
contains Interrupt, Data Request, and Interrupt Request messages
collectively known as Other-Data).
Messages id each subchannel 'are numbered sequentially
by
the
transmitting
NSP.
The receiving NSP returns an acknowledgment
quickly. Otherwise, the transmitting NSP retransmits the message. I t

Functional Description

Page 21

is
not
necessary
to
acknowledge
each message individually.
Acknowledgment of a given numbered message implies acknowledgment of
all messages with a lover number (modulo the maximum message number).
Figure 8 depicts the segment acknowledgment operation.
specifies the format of the acknowledgment messages.

Section

Figure 8 Segment Acknowledgment Operation

.1-1. The data-transmitting NSP assigns a transmit number to a message,
-

transmits the message, and starts a timer.

1
1
1 Data-tranmting
1
NSP
I
1
1
I

1 transmit number = n I

Segment Message!-->I
-1 -' -Data
-------------------1
1
I

1
1

,--------------------- I

Data-receiving
NS P

I transmit number = m I
1
"Other Data" Message[-->[
I

-I -

'---------------------f

121 If the timer times out, the message is retransmitted.
-I

.3- . If the timer does not time out, and the flow control mechanism
- allows
another message to be sent, the data-transmitting NSP
assigns the transmit number plus one to the next data message
transmitted in that subchannel.

.- .

is received by
the data-receiving NSP, it returns that number as an acknowledqment number within the first acknowledgment.

4 1 When the message with the first transmit number

i
I
1
I

I
I

Page 22

Functional Description
Â

5 1 I f the next data message transmit number received is equal to the
current acknowledqment number plus one, the data-receiving NSP
accepts the data message, incrementing the acknowledgment number.
It then sends the new receive acknowledgment number back to the
data-transmitting NSP within an acknowledgment message.

1
1
1

I<--.

1
1
1
Datatransmitting!
1
NSP
1

I
1
1

I
1
I<----------1
1

,------------I

.. number
receive ack.
. I receive ack. I 1
= n
. I number = n + 11 I
Data
. - - I Data
1 -- 1
. Acknowledgment .
.-Message*
.
- - - - - - -

1
1
1
I

I ~cknowledgmentl 1
1 Message
1 1 DataI
--------------I receiving I
-----------------1
NSP
1
I receive ack.
I
I
I
I

I number = m
"Other Data"
1 Acknowledgment
1 Message

------------------

.
I

I---------I

1
1
1
1

-----------

I
I

Data Subchannels

* The data-receiving NSP might not send an acknowledgment for each
data message received. The receive acknowledgment number implies
that all previous numbers were received.

.- .

However, if the data-receiving NSP receives a data message trans-6 1 mit
number less than or equal to the current receive acknowledgment number for that subchannel, the data segment is discarded.
The data-receiving NSP sends an acknowledgment back to the datatransmitting NSP. The acknowledgment contains the receive
acknowledgment number.

.- .

7 1 I f the data-receiving NSP receives a data message transmit number
greater than the current receive acknowledgment number plus one
for that subchannel, the data segment may be held until the
preceding segments are received or it may be discarded.

Figure 8
Segment Acknowledgment Operation

Functional Description

Page 23

2.6.3 Flow Control - Flow control is the mechanism that determines
when to send an NSP Data Segment or Interrupt message.
This
mechanism, along with the error control mechanism, coordinates the
flow of data on a logical link from transmit buffers in one node to
receive buffers in another node.
Flow control is performed separately for normal and interrupt data.
Flow control operates symmetrically for data flow in each direction on
a logical link.

Data Flow Control - Flow
2.6.3.1 Normal algorithms for normal data:

control

requires

two

An
implementation-dependent
algorithm
executed
by
a
data-receiving NSP that determines both when to send a
request message and the count value to be put into a request
message.

An algorithm executed by a data-transmitting
determines if a Data Segment message may be sent.

NSP

that

In addition, an "on/offl' control mechanism may be used by
a
data-receiving NSP to indicate to a data-transmitting NSP that Data
Segment messages may or may not be sent.
On/off control. On/off control is independent of the request count
control.
It operates as follows: Each Data Request message contains
a "send/do not send" indicator. When the error control mechanism in a
data-transmitting NSP has received and accepted a Data Request
message, the value of the "send/do not send" indicator is saved in the
data base associated with the logical link. When the value is "do not
When
send," the data-transmitting NSP may not transmit normal data.
the value is "send," the data-transmitting NSP exercises the flow
control mechanisms described next.
Request count flow control. During logical link formation, the NSP at
each e n d of link determines the kind of flow control it expects
when acting as a data receiver. The term "data-receiving NSP" means
an NSP acting as a data receiver. There is a choice of:
o

No flow control

Segment flow control

Session Control message flow control

The choice of flow control is indicated via fields in Connect
Initiate, Retransmitted Connect Initiate and Connect Confirm messages.

Functional Description

Page 24

Each data-transmitting NSP must accept the type of flow control the
data-receiving NSP expects. Note, Message flow control is obsolescent
and will be eliminated at a future time.
data-transmitting NSP maintains a "transmit request count" variable
for normal: data in the data base associated with each logical link.
When the error control mechanism receives and accepts a Data Request
message, flow control adds the count value from the message to the
appropriate transmit request count. The count values contained in the
request messages may be zero, positive, or, in some cases, negative.
This additive scheme works because the
request
messages
are
error-controlled; it would not work otherwise.
A

No flow control.
-

If the data-receiving NSP selected "no flow
control,' the data-trar-smitting NSP may transmit data at any time
(subject to the "on/offW constraint).

.- .

1 1 NSP/Node A send a Connect Initiate message to NSP/Node B:

1 Connect Initiate I---------------

.2-1. NSP/Node B, having received the Connect Initiate message, returns
-

a Connect Confirm message. A field in the message indicates char
NSP/Node B expects segment flow control:
<----------------

I Connect
I Confirm
-

.- .

.. ..
. '
-

I
I

want segment flow control1'---------I

3 1 NSP/Node A's data base has the initial value of 0 for its request

count variable for normal data segment flow control:

.- .

NSP/Node B sends Data Request message containing a flow control
-4 1 value
that indicates the number of Data Segment messages NSP/Node
B can receive. (NSP/Node B executes an implementation-dependent
algorithm to determine this value):

1 Request

.- .

can receive n messages"----------'

.5 1. NSP/Node A sets FLOWrem-dat to n:

Functional Description

Page 25

.- .

161 NSP/Node A executes algorithm to determine if Data Segment

Number 1 can be sent (highest acknowledged Data Segment messace
plus the current request count must be greater than or equal to
the number of the next Data Segement message sent):

*
I
YES

.- .
171

SEND
The answer to the above is YES, so NSP/Node A sends Data Seqmeni
number 1:

. .

181 NSP/Node B acknowledges receipt of first data segment:

'- I

Figure 9 Example of Segment Flow Control for Normal Data on
a Logical Link (shown in one direction only)
Seqment flow control. Figure 9 shows an example of the operation of
segment flow control. Segment flow control operates in the following
manner: I f the data-receiving NSP selected the segment flow control
mechanism when the logical link was formed, the highest numbered Data
Segment message that may be transmitted is the one whose number is
equal to the sum of the highest numbered Data Seqment message that has
been acknowledged (via the error
control
mechanism)
by
the
data-receiving NSP plus the current value of the request count. The
data-transmitting NSP decrements its request count variable by one for
each Data Segment message acknowledged by the data-receiving NSP.
The count values that can be contained in Data Request messages may be

Functional Description

Page 26

negative.
This means that the permission to transmit a particular
Data Segment message (even if it has been previously transmitted) may
be withdrawn by the receiver. This, in turn, causes an interaction
between the flow control and error control mechanisms.
Specifically,
it is not necessary for the error control mechanism to maintain an
active retransmission timer for a Data Segment message that has been
transmitted at least once but for which permission to transmit (in
other words, to retransmit) has been withdrawn.
Session Control message fiow control.
If the data-receiving NSP
selected Session Control message flow control, the data-transmitting
NSP cannot send a segment i f the number of end-of-message segments
between the highest acknowledged seqment and the segment in question
The
(exclusive) is greater than
or
equal
to
the
count.
data-transmitting NSP decrements its request count variable by one for
each Data Segment message that is
an
end-of-message
segment
acknowledged by the data-receiving NSP.
The mechanism for Session Control message flow control does not
interact
closely with the error control mechanism (unlike the
mechanism for seqment flow control). Once a Data Segmeni has been
given permission to be transmitted, the permission will never b e
withdrawn.

2.6.3.2
Interrupt Data Flow Control - All NSPs use interrupt data
flow control for movlng interrupt data. This mechanism is similar in
operation to the Session Control message flow control mechanism.
Interrupt message request counts are carried in Interrupt Request
messages. The counts are additive and may not be negative.
The
interrupt-transmitting NSP can, therefore, maintain an interrupt
transmit request count. When a logical link is established, there is
an
implicit
request of one interrupt message.
The interrupt
transmitting NSP cannot send an Interrupt message if the number of
Interrupt messages between the highest acknowledged Other Data message
and the Interrupt message in question is greater than or equal to the
count.
The interrupt-transmitting NSP decrements its request count
variable by one for each Interrupt messaqe acknowledged by the
interrupt-receiving NSP.

2.6.4 Segmentation And Reassembly Of -User Messages - Because of
network constraints such as available buffer sizes and transmission
error characteristics, user messages in Session Control buffers cannot
always be sent in one piece. A data-transmitting NSP breaks up data
A
contained in a single Session Control buffer into segments.
data-receiving NSP reassembles the segments. The data-transmitting

Functional Description

Page 27

NSP transmits the segments by means of Data Segment messages.
The
data-receiving NSP puts the segments from the Data Segment messages
into the correct sequence. These messages contain user data as veil
as NSP header information. The segment acknowledgment scheme (Figure
8, Section 2 . 6 . 2 ) ensures that all data segments are received.
The
data-transmitting NSP must know the maximum length of a Data Segment.
This length is the lesser of:
1.

The size of a transmit buffer in the source node. This s i z e
cannot be larger than the node's Routing Layer will permit.

The maximum length that the data-receiving NSP can receive.
The SEGSIZE field in the Connect Initiate and Connect Confirm
messages, exchanqed when the logical link was
formed,
contains this information.

The data-receiving NSP orders the data segments using the sequence
number contained in the Data Segment message and end-of-message
information. When Data Segments have been received out of sequer.ce,
they are either discarded or stored temporarily in a cache buffer
Section 2.7.1).
This document does not specify the detailed processes of segmentation
and reassembly.
However, Sections 6 . 5 and 6.8 provide a model for
implementation and Appendixes B and C provide examples.

2.7

Functional Components

In its relation to DNA, NSP can be considered a "black box," -.?hi c?,
interfaces to Session Control and Routing by defined interfaces and
with other NSP modules by the Network Services Protocol.
The
functional components in this section and in Sections 5 and 6 describe
the operation of this "black box" by means of a sample implementation.
Any
other
implementation with equivalent operation is also a
legitimate NSP implementation.
NSP consists of data bases, buffer pools, and modules.
Brief
descriptions of each follow in this section. Section 5 details the
data base and buffer pool specifications.
Section u specifies i n
detail the operation of the NSP modules with a model implementation
written in a high-level, colloquial computer language.
Figure 10
shows the interrelationship of the NSP components.

Functional Description

Page 28

7 . 1 --Data Bases And Buffer Pools - The following is a model
data bases:

the

NSP

internal data base. The NSP internal data base contains NSP's
internal variables and parameters. Variables are values defined by
NSP. Variables change automatically during the operation of NSP.
Parameters are values defined by the Network Management interface.
Parameters can be read and sometimes set by the user. Many parameters
are static in the sense chat they remain set until the user change's
them.

NSP

Session Control port data base. The Session Control port data base
contains the port variables that NSP uses to manage a logical link.
When a logical link is created, NSP allocates a Session Control port
to it. When the link is destroyed, NSP releases the port back to the
port data base as a free port.
2eserved port -data base. The reserved port data base contains the
port variables reserved for NSP's internal use. NSP uses these to
manage the sending of messages that do not map onto the Session
Control port data base.

Page 23

Functional Description

------------

CACHE

I REASSEMBLY [ < - - > [ A N D
1 MODULE

,------------I

I < -----__
>I

----------Ã‘---

Figure 10

PORT 1
DATA I<-------BASES I<-----.

--------*

1 RECEIVE

I POOLS

------

1 TRANSMIT
1 PROCESSES

1 CCMMIT

PROCESSES 1
^-----------~

Interrelationship of NSP Components

Node data base. The node data base contains a collection of node
descriptors.
A node descriptor is required for each rentote node to
which a logical link is established.
A node descriptor contains
variables and counters pertaining to communications with that node
(for example, the estimated round trip communications delay, traffic
usage and error counters).
7 -

Large and small transmit buffer pools. The large and small transmit
buffer pools contain large and small transmit buffers. Large transmit
buffers transmit Connect Initiate (or Retransmitted Connect Initiate)

Functional Description

Page 30

messages or Data Segment messages. Small transmit buffers transmit
all other NSP messages. An implementation may choose to use a single
transmit buffer pool for all NSP messages.
Receive buffer pool. The receive buffer pool contains a collection o f
receive buffers required to receive an NSP message from Routing.

Commit buffer pool. The commit buffer pool is an optional pool whicn
contains commit buffers used for data that the receivina node may
commit to storaqe even in the absence of receive buffers supplied by
Session Control. Such data may be acknowledged to its transmitter.
Cache buffer pool. The cache buffer pool is an optional pool which
contains a collection of cache buffers. Cache buffers hold received
Data Segment messages that cannot be acknowledged either because they
are out of order or because there is no storaqe in either a commit
buffer or a Session Control receive buffer for them.
Event buffer pool. The event buffer pool contains buffers that may be
queued to NSP's event queue for reading by Network Management.

Modules - NSP modules oerform specialized functions.
two kinds of modules:

2.7.2

There are

A process is a module that is independent of other modules,
but uses the services of some other modules. I t is designed
as if it were executing on a processor dedicated to it.

routine is a module that provides functions for one or more
processes, but does not have a context of its own.

In general, processes communicate with routines by means of calls and
with other processes by means of shared variables, usually a port.
The mechanisms that synchronize two processes to prevent common entry
to a critical region are not explicitly defined.
The NSP process and routine modules are described below.
Note that
these are functional descriptions of components. ~mplementationsneed
not be structured exactly as outlined in these descriptions.
Interface routines'. The interface routines handle all Session Control
calls (Section 3.1).

Receive dispatcher routine.
The receive dispatcher manages the
receive buffer pool. I t polls Routing tor received messages, parses
them, maps them onto ports, and returns message contents to the
appropriate NSP process.
Receive processes. These receive and handle NSP messages from the End
Communications Layer at remote nodes and help manage logical link

Functional Description
states.

Page

Each Session Control port has a set of these processes.

Reassembly routine.
The reassembly routine determines the flow
control ~ o l hmaintains che cache and commit buffer pools, and
reassembles received Data Segment messages into Session Control
receive buffers.
Transmit processes. These transmit (and retransmit, if necessary) NSP
messages to End Communications Layers at remote nodes. Each Session
Control port has a set of these processes.
Transmit format routine. The transmit format routine maintains large
and small transmit buffer pools and formats outgoing messages. I t
queues messages to Routing.
I t polls Routing to get "transmit
complete" notifications.
Segmentation routine. This segments data in Session Control transmit
buffers into a form suitable for transmission in Data Segment
messages.
Transmit allocation rcntine. The transmit allocation routine receives
requests for permission to transmit from the transmit processes. I t
allocates permission t i transmit in a way that guarantees that when
more than one logical link is es'tablished to the same destination at
the same time each prcvides useful commi~~ication
services.

3.0

NSP INTERFACES
-

This section describes the three external NSP interfaces:
1.

Session Contra1 interface

Network Manag?ment interface

Routing interface

The interface functions are described as calls to subroutines
following format:

the

FUNCTION (input; output)
Descriptions of input and output then follow unless previously given.
In general, there are two types of subroutines:
those performing a
function that is completed immediately, and those queueing a buffer
for transmitting or receiving data.
For buffer-queueing calls, additional calls are defined to allow
A "buffer"
polling
to obtain "buffer returned" notifications.
argument denotes a system-dependent buffer descriptor that contains
location and length information. A "port idn is a system-dependent
number identifying a port. Although not described in the following

Page 32

NSP Interfaces
functions, an invalid port identifier causes an error.

Note that an implementation is not required to code the interfaces
calls to subroutines. The calls specify functions only.
I t may be useful to refer to the port state descriptions
4.1 when studying the followinq interface functions.

3.1

Section

Session Control Interface

This interface allows NSP to provide Session Control with the logical
link service.
This service allows Session Control to create one or
more logical links to one or more other Session Control modules in the
same network.
In the interface descriptions, the terms "source" and "destination"
distinguish the requester of a function from the receiver of the
request. The source and destination can be within a single Session
Control module or in two separate Session Control modules. Thus, at a
single node, a Session Control module can communicate with itself via
a logical link;
between two nodes, two Session Control modules car.
communicate with each other via a logical link.
The calls, described by function, are as follows:
NSP status)

STATUS ( ;

returns:

NSP is halted.
NSP is running;
minimum
receive
buffer
NSPbuf -- Table 3 , Section 5.1) returned

size

This function reads the status of NSP and obtains a minimum
receive buffer size if NSP is running. This is the one Session
Control interface function that does not involve the use of a
logical link.
OPEN ( source, buffer;

return)

source:

a 16-bit buffer to contain the logical link requester
node address when this node receives a connect
request

returns:

port allocated and port identifier returned

port not allocated -- insufficient resources
port not allocated -- NSP halted

This 'function allocates a port in NSP for receiving a logical
link connect request.
The source variable receives the node
the buffer receives t,he
address of the requesting node;

NSP Interfaces

Page 33

incoming connect data.
When the port stzte indicates an
incoming connect request is received, NSP places the source
node address in the source variable and the incoming data in
the buffer.

CLOSE (port id)
This function deallocates a port. When a port is closed, NSP
immediately returns all cransmit and receive buffers to Session
Control (see DATA-XMT and DATA-RCV calls).
Once a port is
closed, its associated port identifier is undefined. Any
subsequent call issued with such a port identifier results in
an error return.
Session Control may close a port at any time regardless of the
port's state. However, doing so may create ambiguities for the
Session Control module at the other end of the logical link.

CONFIDENCE (port id;
returns:

confidence)

network probably connected
network probably disconnected
port not in RUNNING, CONNECT-CONFIRM,
DISCONNECT-REJECT, or DISCONNECT-INITIATE state

This function obtains NSP's assessment of connectivity.
NSP
periodically tests a logical link once it is formed to
link
is
ascertain if the physical path supporting the
connected. The result of this testing is the probable state of
connectivity. I t is not a guaranteed state.
Session Control may issue this call to determine when
disconnect a link on behalf of a program at the user level.

STATE (port id; state)
returns:

the state of the associated logical link

This function returns the state of a port that is not CLOSED.
Because NSP's operation is not necessarily synchronized with
that of Session Control, it is possible that this call will not
detect every state transition. This is especially the case for
state transitions that occur very quickly. However, this is
not a problem because the intervening undetected states can be
logically deduced.

NSP Interfaces

Page 34

CONNECT-XMT (destination [,circuit [,nexthop]], buffer;
destination:

return)

destination node address

circuit:

an internal NSP mechanism selector used to enable
loop testing.
Circuit is either unspecified (for
normal use) or a system-dependent circuit number
representing the circuit NSP is to use for its
messages establishing this logical link (for Network
Management loop tests',.

nexthop:

a node number (required i f
circuit)

buffer::

contains connect data

returns:

port allocated;

circuit

broadcast

port id returned

port not allocated -- insufficient resources
port not allocated -- NSP halted
This funct ion allocates a port and requests a logical link
After a logical link has been successfully formed,
connection
Session Control can put a load on a particular physical link
for loop test purposes provided that the circuit argument
specified the physical link.
This enables testing of the
physical link and all of the DECnet modules from Session
Control or higher layers by sending and receiving data on the
resulting logical link. For normal use, the circuit argument
is set to "unspecified."

CONNECT-STATUS (port id, buffer;
returns:

return)

connect request accepted by destination - - port
accept data returned in buffer

connect request rejected by destination - - port
REJECTED state; reject data returned in buffer

RUNNING state;

port in neither RUNNING nor REJECTED state
This function obtains accept or reject data returned as a
result of a previous connect request. If the return is one of
the first two, 'TSP returns any available accept or reject data.
Once this is done, an NSP implementation may discard its copy
of the accept or reject data so that a subsequent connect
status function would not return data.
In cases where state transitions occur very rapidly, Session
Control may not be able to perceive some intervening states.
Consequently, this call may not be accepted (see Section 4.1).

NSP Interfaces

Page 35

Accept data will be lost if the rapid state transitions end
with a transition to the DISCONNECT-NOTIFICATION state and this
call was never executed in the RUNNING state. No data is lost
otherwise.

I f the connect request is accepted, up to 16 bytes of accept
data may be returned in the buffer. I f the connect request was
rejected, up to 18 bytes of reject data may be returned in the
buffer (see the ACCEPT and REJECT calls).

ACCEPT (port id, buffer;
returns:

return)

link accepted
port not in CONNECT-RECEIVED state

Thi s function accepts a connect request
Con trol module. The call supplies a bu
by tes of accept data.

REJECT (port id, value, buffer;
returns:

rom a remote Session
er containing up to 16

return)

link rejected
port not in CONNECT-RECEIVED state

This function rejects a connect request from a Session Control
module.
The call supplies a 2-byte value and a buffer
containing up to 16 bytes of reject data.

DISCONNECT-XMT (port id, value, buffer;
returns:

return)

call accepted
call rejected -- port not in RUNNING state

This function requests the disconnection of a logical link that
is in the RUNNING state. The call supplies a 2-byte value and
a buffer containing up to 16 bytes of disconnect data.
The remote Session Control module receives any data transmitted
by the disconnecting Session Control module prior to this call.
Session Control disconnects a link when it has no more data to
send and wants to ensure that the link will be properly
disconnected, not aborted.

NSP Interfaces

Page 36

ABORT-XMT (port id, value, buffer;
returns:

return)

call accepted
call rejected -- port not in RUNNING state

This function requests the immediate disconnection of a logical
link that is in the RUNNING state. The remote Session Control
module may not receive all previously transmitted data before
receiving the abort notification.
The call supplies a 2-byte value and a buffer containing up
16 bytes of abort data.
DISCONNECT-RCV (port id, value, buffer;
returns:

return)

disconnect data available
no disconnect data available
port not in DISCONNECT-NOTIFICATION state

This function receives disconnect data returned to the local
Session Control module as a result of a DISCONNECT-XMT or
ABORT-XMT call from the remote Session Control module. Session
Control detects a logical link disconnection or an abort when a
STATE call returns a DISCONNECT-NOTIFICATION. A 2-byte value
and up to 16 bytes of data may be returned in the buffer.

DATA-XMT (port id, buffer, xmtflag;
xmtflag:

return)

a flag indicating whether the last byte in the buffer
is the last byte of a Session Control message. Its
value is one of:
o

end-of-message

Section 2.4.4 describes data flow.
returns:

buffer queued
buffer not queued -- insufficient resources
port not in RUNNING state

-for
This function queues a transmit buffer to a
port
transmitting normal data on a logical link. NSP refuses to
queue the buffer either if it lacks the resources to do so or
if th'e port is not in the RUNNING state.

Page 37

NSP Interfaces
XMT-POLL (port id;
returns:

return)

no tranmsit complete
transmit complete -- buffer descriptor returned

This function returns a transmit buffer to Session Control.

DATA-RCV (port id, buffer, rcvflaa;
rcvflag:

returns:

return)

a flag indicating whether data truncation is allowed.
It may have either of the following values:
o

no truncation allowed

truncation allowed

buffer queued
buffer not queued -- insufficient resources
buffer not queued -- buffer too
truncation was specified in rcvflag

small

and

port not in RUNNING or DISCONNECT-INITIATE state
This function queues a receive buffer to a port to receive
normal data. A "buffer too small" return indicates the buffer
size is smaller than the minimum receive buffer, NSPbuf (see
STATUS)

Session Control may provide a buffer to a port in the
DISCONNECT-INITIATE state to avoid a Session Control deadlock
in which each end of
the
logical
link
is
in
the
DISCONNECT-INITIATE
state.
However,
this
is
an
implementation-dependent issue.

RCV-POLL (port id;
returns:

return)

no buffer returned (Either no receive buffers are
queued to the port or there is no receivedata
available.)
buffer returned -- no data lost, end-of-message
buffer returned -- data lost, end-of-message
buffer returned -- no data lost, not end-of-message
buffer returned -- data lost, not end-of-message

NSP Interfaces

Page 38
buffer returned empty -- port not in
RUNNING,
DISCONNECT-COMPLETE,
or
DISCONNECT-INITIATE,
DISCONNECT-NOTIFICATION states.

This function obtains a "receive complete" notification for a
receive buffer previously queued via a DATA-RCV call. NSP
returns receive buffers along with buffer descriptors to
Session Control in the order in which data was placed in them.
A data-transmitting NSP segments data given to it by the
DATA-XMT call and sends each segment separately through the
network. A segment containing data given to NSP with an
'end-of-message1' flag is so marked.
A data-receiving NSP
receives these segments and places the data in Session Control
receive buffers given to NSP by the DATA-RCV function. The
sequence of packets flowing from a data-transmitting NSP to a
data-receiving NSP constitutes the network form described in
Section 2.4.4.
I f a data-receiving Session Control module gives NSP each
receive buffer with the rcvflag set to "no truncation allowed"
on the DATA-RCV call, then NSP attempts to place the data, in
order, from one or more segments of a single Session Control
message into each receive buffer. A receive buffer is always
returned with a "no data lost" indication and is returned with
an "end-of-message" indication i f and only if the last segment
of data placed in it was marked as an "end-of-message" segment.
Note that two DATA-XMT calls by the data-transmitting Session
Control
module,
one
with
data
that
is
not marked
"end-of-message" and the second with no data but marked
llend-of-messagel" may result in data and status being qiven to
the data-receiving Session Control either in two buffers, as
qiven to NSP by the data-transmitting Session Control module,
or in a single buffer containing the data and marked as
'end-of-message "

If a data-receiving Session Control module gives NSP each
receive buffer with the rcvflag set to "truncation allowed,"
then NSP either fills the receive buffer or puts data into it
up
to
and including the data in a segment marked as
"end-of-message" whichever comes first. If a receive buffer is
filled first, then NSP continues to receive and discard data
segments up to and including the first one
marked
as
'end-of-message1' In either case, the receive buffer is
returned as an "end-of-message" on the RCV-POLL call.
In the
case where data was discarded, the receive buffer is returned
with a "data lost" indication. The only time a buffer given
with
a
"truncation
allowed"
rcvflag
is
returned as
"not-end-of-message" is when the logical link is disconnected
by
the
data-transmitting Session. Control module with a
partially transmitted message.
data-receiving Session control module may mix calls with the
"truncation allowed" rcvflag with calls with the "no truncation
allowed" rcvflag..

NSP Interfaces

Page 39

If Session Control closes a port that has receive
queued via the DATA-RCV call, NSP returns these
immediately.

INTERRUPT-XMT (port id, buffer;
returns:

buffers
buffers

return!

data accepted
data not accepted
port not in RUNNING state

This function sends up to 16 bytes of high priority data to the
destination Session Control module. The data has no sequential
relationship to normal data transferred on a logical link. N S ?
may refuse a requ'est to send interrupt data if it is unable to
queue the data internally. The buffer may be up to 16 bytes
long.

INTERRUPT-RCV p o r t id, buffer;
returns:

return)

data returned

no data returned
port not in RUNNING state
This function obtains available interrupt data. Interrupt data
is delivered in the order transmitted by the INTERRUPT-XMT
function. Interrupt data has no sequential relationship to
normal data transferred on a logical link.

Network Management Interface
Network Management can perform the
Network Management interface:

following

functions

using

NSP's

~nitializeor halt NSP.

Read and set some of NSP's local parameters and variables.

Read NSP's remote node variables and counters.
remote node counters.

Read (one event at a time) and clear NSP's event queue.

Clear

NSP'S

The interface is modeled as a collection of functions provided by
subroutines.
Each call represents a specific function. In each

NSP Interfaces

Page 40

return, the variable in parentheses is its name appearing in the
base descriptions in Tables 3 and 4. Section 5.

data

Many of the calls pertain to either local or remote NSPs.
Actually,
the "remote" NSP is the local NSP if the logical link is made within a
single node.:
Al.1 the variables read, set, or cleared by the following Network
Management functions are locally kept variables. Thus, a set of NSP
variables for each remote node to which there is an active logical
link is kept at the local node. NSP does not guarantee that any
information will be available when there are no logical links to the
specified remote node.
Implementations of Network Management are not required to return every
parameter, variable, or counter listed here.
The Network Management interface functions are as follows:

INITIALIZE
This function initializes the local NSP.

HALT
This function halts NSP.

The call has the following effects:

NSP closes all ports.

NSP will refuse to open a new port.

NSP returns all Session
Control.

NSP freezes its counters and event queue.

LOCAL-READ-ADDRESS
return:

(;

Control

buffers

Session

address)

NSP's node address (NSPself)

This function reads NSP's node address.

LOCAL-READ-INACTIVITY ( ;
retuh:

inactivity)

NSP's inactivity timer ( ~ S ~ i n a-ctim)
t

This function returns the interval after which, if there is

Page 41

NSP Interfaces

data going in either direction on a link, NSP checks the link.
NSP checks the link by sendina a Data Request message (Table 1)
to the remote NSP. This message does not change flow control
parameters, but does require an acknowledgment.

LOCAL-READ-DELAY ( ;
return:

delay)

NSP's delay factor vNSPdelay1

This function returns the number by which to multiply one
sixteenth of the estimated round trip delay to a node to set
the retransmission timer to that node. The round trip delay is
used in an NSP algorithm that determines when to retransmit a
message (Section 7.3).

LOCAL-READ-WEIGHT ( ;
return:

weight)

N S P 1 s delay weight

weight)

This function returns the weight NSP applies to the current
round trip delay estimate to a remote node when updating the
estimated round trip delay to a node ( Section 7.3).

LOCAL-READ-RETRANSMIT ( ;
return:

retransmit)

N S P 1 s retransmit threshold (NS~retrans)

This function returns the maximum number of times the source
NSP
will restart an expired retransmission timer before
deciding that the remote node is probably unreachable (see
CONFIDENCE in Section 3.1). When this number is exceeded, NSP
gives a "probable disconnection" return to a Session Control
CONFIDENCE call. Session Control may then disconnect the link
on behalf of the end user. The retransmit threshold is called
the NODE RETRANSMIT FACTOR in the DNA Network Management
Functional Specification.

LOCAL-READ-MAXIMUM-ACTIVE ( ;
return:

maximum ports)

N S P 1 s maximum ports number (NSPmax)

This function returns the ma-ximum number of ports NSP has
concurrently had assigned to a logical link (in other words,
This is
concurrently in a state other than OPEN or CLOSED).
called NODE MAXIMUM LOGICAL LINKS ACTIVE in the DNA Network
Management Functional Specification.

Page 42

NSP Interfaces
LOCAL-READ-TOTAL ( ;
return:

total ports)

NSP's total ports number (NSPtotal)

This function returns the maximum active logical link count for
the node. This is the total number of ports that NSP can have
in use concurrently. This is called NODE MAXIMUM LINKS in the
DNA Network Management Functional Specification.

LOCAL-READ-VERSION ( ;
return:

version number*

NSP's version number (NSPversion)

This function returns the local NSP's version number.
version, the value returned is 4.0.

For this

LOCAL-SET (qualifier, value)
qualifier:

one of the following, defined above:
LOCAL-SET-ADDRESS
LOCAL-SET-DELAY
LOCAL-SET-INACTIVITY
LOCAL-SET-MAXIMUM
LOCAL-SET-RETRANSMIT
LOCAL-SET-WEIGHT

value:

the new numerical value for the selected parameter or
variable.

This function sets NSP local parameters.

REMOTE-READ-DELAY (node; delay)
node :

a node address

return:

the estimated round trip delay
(~ODEdelay)

This function returns the estimated round
remote node.

the

trip

remote

delay

node
the

Page 43

NSP Interfaces
REMOTE-READ-ACTIVE (node; active)
return:

the number of active logical links to the remote
~ODEactive)

NSP

This function returns the number of ports in a state other than
OPEN that NSP has associated with logical links to the remote
node. This variable is called NODE ACTIVE LINKS in the DNA
Network Management Functional Soecification.

REMOTE-READ-BYTES RECEIVED (node; bytes received)
return:

the number of user data bytes received ( ~ 0 D ~ b-yrev)
t

This function returns the total number of user data bytes
received from the remote node, including normal-, interrupt,
connect, accept, reject and disconnect data.

REMOTE-READ-BYTES SENT (node; bytes sent)
return:

the number of user data bytes sent (NODEbyt-xmt)

This function returns the toial number of user data bytes
to the remote node.

sent

REMOTE-READ-MESSAGES RECEIVED (node; messages received)
return:

the total number of messages received from the remote
node (NODEmsg-rev)

This function returns the tola1 number of all types of NSP
messages received from the remote node regardless of their
disposition. This includes detected duplicates.

REMOTE-READ-MESSAGES SENT (node; messages sent)
return:

the total number of NSP messages sent to
node (NODEmsg-xmt)

the

remote

This function returns the total number of NSP messages sent
the remote node. This includes retransmissions.

Page 44

NSP Interfaces
REMOTE-READ-CONNECTS RECEIVED (node; connects received)
return:

the total number of SSP Connect 1nitiat.e messages
received from the remote node (NODEcon-rev)

Th'is;function returns the total number of NSP Connect Initiate
messages the local node has received from the remote node
regardless of their disposition.

REMOTE-READ-CONNECTS SENT (node; connects sent)
return:

the number of NSP Connect Initiate messages
the remote node (NODEcon-xmt)

This function returns the number
messages sent to the remote node.

NSP

Connect

sent

Initiate

REMOTE-READ-CONNECTS REJECTED (node; connects rejected)
return:

the number of received NSP Connect Initiate messages
for which there was no open port (NODEcon-rej)

This function returns the number of NSP Connect ~nitiate
messages rejected by ihe local NSP. This variable is called
"received connect resource errors" in
the
DNA
Network
Management Specification.

REMOTE-READ-TIMEOUTS (node; timeouts)
return:

the number of timeouts that have occurred in waiting
for acknowledgments (of any kind) from the remote
node (NODEtimeout)

This function returns tihe number of response timeouts
from the destination NSP.

REMOTE-READ-AND-CLEAR
-- (node, value;

qualifier)

value:

the
numerical
qualifier.

qualifier:

one of the following, defined above:
0
0

0
0

received

value

for

che

REMOTE-READ-BYTES RECEIVED
REMOTE-READ-BYTES SENT
REMOTE-READ-MESSAGES RECEIVED
REMOTE-READ-MESSAGES SENT

corresponding

Page 45

NSP Interfaces
0
0

o
o
returns:

the selected information

This function
counter.

READ-QUEUE ( ;
returns:

REMOTE-READ-CONNECTS RECEIVED
REMOTE-READ-CONNECTS SENT
REMOTE-READ-CONNECTS REJECTED
REMOTE-READ-TIMEOUTS

reads

and

then

clears

node-dependent

NSP

return)
event queue empty
the first entry on
following events:
invalid message

the

event

queue.

One

the

A
received
message
was
discarded
because
reserved
bits or values in the message
were used.
The beginning of
the message, is the event data.

invalid flow control A
received
Link
Service
message was discarded because
it contained a request count
that, when used to compute an
accumulated
request
count,
would produce a result out of
limits.
The
message
and
current request counts are the
event data.
data base reused

A node descriptor
(Section
5.4)
was
reused
for
a
different remote node.
The
contents of the data base are
the event data.

events lost

The queue was full when NSP
attempted to place an entry in
it. One or more events were
lost.

This function reads the first entry on an event queue.
NSr
maintains an internal event queue. The length of the queue is
implementation-dependent. but is always at least one.
When
events (described above in the returns) occur, NSP places
entries in the queue. If the queue is full when NSP attempts
to place an entry in it, the last entry in the queue changes to
"events lost.
'I

The DNA Network Management Functional

Specification

describes

Page 46

NSP Interfaces
return formats.

CLEAR-QUEUE
This function clears NSP's internal event queue.

3.3

Routing Interface

NSP requires a Routing service for its o~eration. A Routing service
provides NSP with the ability to send datagrams (containing NS?
messages) to, and receive datagrams from. any other NSP module in the
same DECnet network.
The interface described below appears in the form of calls from an NSP
module to a Routing module in the same node.

ROUTING-TRANSMIT
source :

(source,

[ ,circuit[ ,nexthop]I ,

destination,
buffer, tryhard;

returnflaa
return)

a source node address

destination:

a destination node address

returnflag:

a Boolean flag to indicate whether or not the packet
is to be returned by the Routing service i f the
destination node is inaccessible. The flag may have
one of the following values:

circuit:

false -- do not return packet

true -- return packet

an internal NSP mechanism
testing). One of:

selector

(used

for

loop

unspecified

a circuit that is the circuit on which
Routing should direct this datagram.
If
circuit specifies a broadcast circuit, then
nexthop must also be specified.

next hop:

a node number

buffer:

a buffer containing a packet

tryhard:

a Boolean flag to indicate whether or not the packet
is to be sent to the destination node using the

Page 47

NSP Interfaces

Routing Layer's tryhard algorithm. When this flag is
true, NSP is instructing the Routing Layer to make a
maximal effort to deliver the packet.
When false,
NSP is instructing the Routing Layer to deliver the
packet using a less costly and potentially less
reliable mechanism. The normal default is false.
returns:

buffer queued
buffer not queued

This function queues a transmit buffer to Routing.
Routing
rejects this call (in other words, does not queue a packet)
If
only if it has insufficient resources to queue the buffer.
the destination node is currently unreachable, then Routing
accepts the buffer, although i t may return
the
buffer
immediately
(see
ROUTING-CHECK-TRANSMIT-BUFFER
call,
following). The "circuit" argument has the same meaning as
that in the CONNECT-XMT call (Section 3.1).

ROUTING-CHECK-TRANSMIT-BUFFER (buffer, return; )
returns:

all buffers remain queu?d by Routing
buffer returned to NSP

buffer:

a buffer previously
ROUTING-TRANSMIT call

This function checks to see if
buffer can be returned to NSP.

given
a

previously

Routing

via

queued

transmit

ROUTING-SUPPLY-RECEIVE-BUFFER (buffer; return)
returns:

buffer queued for receive by Routing
buffer not queued for receive by Routing

This function queues a receive buffer to Routing.

ROUTING-CHECK-RECEIVE-BUFFER (source, destination,
[,circuit!.,nexthopll, buffer, tryhard;
source:

return)

a source node address

destination:

a destination node address

circuit:

an internal NSP mechanism
testing). One of:

selector

(used

for

loop

Page 48

NSP Interfaces
o

unspecified

a circuit that is the circuit on which
Routing should direct this datagram.
If
circuit specifies a broadcast circuit, then
nexthop must also be specified.

nexthop:

a node number

returns:

all buffers remain queued by Routing
buffer returned with source and destination
addresses -- contains a normal packet
buffer returned -packet

contains

This function c,hecks to see if
buffer can be returned to NSP.

4.0

"return

previously

sender"

queued

receive

NSP STATES
-

This section describes the stsces and state transitions
normal NSP operation.

4.1

node

required

for

Port States

Whenever Session Control allocates a port, NSP associates the port
with a state.
This state is represented by a variable in the port
data base. The CLOSED state really means that the port no longer
exists.
This state is necessary in the architectl-ire because the
remote port may be placed in the CLOSED-NOTIFICATION state.
In some
implementations the CLOSED state may be indicated by the absence of an
entry. A port has only one state at a time. Table 2 summarizes t h e
normal port states.

NSP States

Page 49
Table 2
Port States

1 (CR) CONNECT-RECEIVED
I

I NSP ?as received a
Connect 1
I Initiate message. (The remote 1
port
is
or
was
in
the I
1 CONNECT-INITIATE state.)
I
+----------------------------------+--------------------------------+
1 (DR) DISCONNECT-REJECT
I The local Session Control has 1
1
1 issued a REJECT call while -:he 1
I port
--/as
in
the I
I
1 CONNECT-RECEIVED state.
+----------------------------------+--------__----__--_---_-__--_--_+
1 (DRC) DISCONNECT-REJECT-COMPLETE I NS? has received a Disconnect 1
I
1 Complete message while in the I
1
1 DISCONNECT-REJECT state.
(The 1
I remote port is or has been in I
1 the REJECTED state.
I
I

+-------------------_--------_-_-__+_-_--__-___-_-__-__-____-_-__--_-

+
1 (NR) NO-RESOURCES
I NSP has received a No Resources 1
I
I message
while
in
the I
1
1 CONNECT-INITIATE state.
(The 1
1
I remote NSP did not have an 1
I
I available port in the
OPEN 1
I
I state.)
I
+----------_----_-_----_-_-________+_______________________________-1 (NC) NO-COMMUNICATION
I

1
I
1
1
I

NSP has
received
its
own
Connect
Initiate
message
while in the CONNECT-IMITIATE
state
because
Routing
was
unable to deliver the message.

+
1

I
1
1
I
+-------------Ã‘--------------..----+____-____-.,_--.._____-_________-_
+
1 (CD) CONNECT-DELIVERED
1 NSP has received a
Connect 1
I Acknowledgment message while in I
I
1
1 the
CONNECT-INITIATE
state. 1
I
I (The destination port is or has I
1
1 been in the CONNECT-RECEIVED 1
I
I state.)
I
I
1

Page SO

NSP States
Table 2 (Cont.)
Port States

1 (RJ) REJECTED
1
1
1
1
1

1 NSP has received a Disconnect I
I Initiate message while in the I
1 CONNECT-INITIATE
or I
1 CONNECT-DELIVERED state. (The I
I remote port is or has been in I
I
1 the DISCONNECT-REJECT state.)

+
NSP has either
received
a 1
Connect Confirm message while I
in the
CONNECT-INITIATE
or 1
CONNECT-DELIVERED
state
or 1
received a Data, Data Zequest, 1
Interrupt
Request,
Data 1

+----------------------------------+---------------------------------

1
I
1

1
1
1
1 ~cknowlkdgment 6 r other Data
I Acknowledgment message while in
1 the CONNECT-CONFIRY state. The
I logical link may be used for
I sending and receiving
data.
1 (Either the remote pcrt is or
1 was in
the
CONNECT-CONFIRM
I stat.e or
the
remote port
1 entered the RUNNING state from
1 the CONNECT-DELIVERED state.)

+----------------------------------+---------------------------------+

1 (DI) DISCONNECT-INITIATE
1
1
1

I The local Session Control has 1
I , issued a DISCONNECT-XMT call or I
1 an ABORT-XMT call while in the 1
1 RUNNING state.

1 NSP

+----------------------------------+---------------------------------

has received
either
a 1
1 Disconnect Complete message or 1
1 a Disconnect Initiate messaqe 1
I while
in
the I
1 DISCONNECT-INITIATE
state. 1
I (The remote port is or has been I
I in
either
the I
1
1 DISCONNECT-NOTIFICATION
state 1
1
1 or
the
DISCONNECT-INITIATE I
I
I state.)
I
+----------------------------------+--------------------------------+
I (DN) DISCTNNECT-NOTIFICATION
1 NSP has received a Disc0nnec.t 1
1
I Initiate message while in the !
1
1 RUNNING state.
(The
remote I
1
1 port is or has been in the I
1
1 DISCONNECT-INITIATE state.)
I
+----------------------------------+--------------------------------1
1
1
1
1
1

(DIG) DISCONNECT-COMPLETE

Page 51

NSP States
Table 2 (Cont.)
Port States

1 (Symbol) State
1 Explanation
I
l-------------------------------------------------------------------....................................................................
I
1 (CL) CLOSED
1 The local Session Control has 1
1
1 issued a CLOSE call (normally 1
1
1 while c h e local port was in the I
1
1 DRC, DN, DIC, NC, NR or CI 1
1
1 state). This is not really a 1
1
1 state of the port, but is used I
I
I for descriptive purposes
to I
1
I indicate that the 2ort is not I
I
I there.
I

+----------------------------------+---------------------------------

1 (CN) CLOSED-NOTIFICATION
1

1
1
1
1
1
1
I

NSP has received i No Link i
message
while
in
the I
1
DISCONNECT-INITIATE,
1
1
DISCONNECT-REJECT,
RUN
or 1
1
CONNECT-CONFIRM staye.
(The 1
1
remote NSP closed the remote I
I
port.)
I
+----------------------------------+--------------------------------+

NSP States

Page 52

Figure 11, following, summarizes the normal port state
These transitions correspond with those in Table 2.

transitions.

LEGEND :

.- - .
1

-- 1

contains port state (Table 2 )

++++>

result from an action by NSP

---- > result from a Session Control call
NOTES

state from which an! exit can be made by a + + + + > arrow is
potentially unstable state.
A

A state from which the only exits are ---- > arrows are stable
states.

A state from which an exit can be made only by more than one
++++>
arrow
is
a
state
from
which
the exit is
non-deterministic.

Figure 11
A

Port State Diagram

transition to CLOSE from any state otheq

than

those

connected

NSP States

Page 53

arrows to CL on Figure 11 is equivalent to terminating the logical
link while it was in a useful state. Such a transition would occur,
for example, when a user process terminates abnormally. This is th?
only kind of transition that can occur that is not shown in Figure il.

4.2

Logical Link States

When one Session Control module attempts to form a connection to a
second Session Control module NSP places the requesting port in the
CONNECT-INITIATE (CI) state. NSP then attempts to associate the local
source port with a destination port that is in the OPEN (0) state. I f
the association between the two ports is successful, the combination
of the two port states is the logical link state. The initial logical
link state is represented as CIIO.
A logical link can be in
implementations that follow
transitions correctly.

XS?
only one state at
a
time.
the model in Section 6 will make the

An NSP may fail to associate
following situations:

two

ports.

This

can

happen

the

If the network is disconnected so that the destination system
is not accessible.
In this case, NSP places the requesting
port in the NO-COMMUNICATION state.

I f there are no ports managed by the remote NSP in the GPEN
state.
In this case, NSP places the requesting port in th?
NO-RESOURCES state.

I f the network is not operating properly (e.9.
is badly
congested)
and
succesive retransmissions fail, Sessions
Control can detect this by checking the Confidence variable.

Figure 12 shows the normal logical link state transitions.
The only state transitions that are not illustrated in Figure 12 are
those that represent the transition of one of the ports to the CLOSED
state from a non-terminal state.
Such a transition is generally
succeeded by a transition of the other port to the CLOSED-NOTIFICATION
state. These transitions introduce ambiguity into the diagram of
logical link transitions. Figure 12 shows an example of this kind of
ambiguity in the exits fror. the CLIDI and DIICL states.
Figure 12
does not show this complete set of transitions, because there are too
many to represent coherently in a single diagram.
Moreover, they
obscure the transitions that occur during normal operation of a
logical link.
Note: In certain unlikely cases a port in the open state may match up
with a duplicate request for connection (for example, when the
original connection was rejected). The connect data will appear to be

N
NSP States

Page 54

valid.
If the receiving session control user accepts this false
connection the local port will never enter the RUNNING state.
However, if communication exists with the remote node, the local port
will eventually enter the "CN" state. Because of these cases, a user
program which does not wish to process the data from a duplicate
connect should accept incoming connections and process the connect
data only if the connection enters the RUNNING state.

Page 5 5

NSP S t a t e s

----

i CI i
0

----

* A n e x i t i s made t o t h e CL/CL

s t a t e from
t h i s s t a t e if the port t h a t is s t i l l
open is c l o s e d by S e s s i o n C o n t r o l .

1 RUN
RUN

---I
v

---DI
RUN

----

Figure 1 2

Logical Link State Diagram

Page 56

NSP States
LEGEND :

.- - .
1

1 contains logical link state consisting of the port states

-- ' at both ends of the link (Table 2 ) .

transition caused by NSP

transition caused by a Session Control call

--->

NOTES
state from which an exit can be made by a + + + + + > arrow is a
potentially unstable state.

state from which the
stable states.

only

exits

are

----->

arrows

are

state from -4hich an exit can be made by more than one
+
arrow
is
a
state
from
which the exiz is
non-deterministic.
+

The logical link states presented above
describe
the
disconnection or abortion of the link from the RUN state When
requested by either Session Control module.
This is true
because the Session Control requesting a disconnection could
be either the Session Control that requested the logical link
or the module that accepted the logical link.

I f a logical link enters the DI/RUN or RUN/DI state because
of a disconnect request by one of the Session Control
modules, then an NSP exit from the DI/RUN or RUN/DI states is
possible only if the Session Control module in the RUN state
has provided a sufficient number of receive buffers to
receive all data transmitted by the other Session Control
module. The + + - ' - + + > arrow exit from either of these states
means that S S P guarantees to make exit eventually only if
this constraint has been met. Similarly, an NSP exit from
the DI/DI state is possible only if one of the Session
Control modules sharing the logical link has met this
constraint.
This constraint does not apply when the DI port
state is entered because of an abort request.

Figure 12

Logical Link State Diagram (continued)

NSP Data Bases and Buffer Pools
5.0

NSP DATA BASES AND BUFFER POOLS
----

This section specifies the variables and parameters in the data
and buffer pools described in Section 2.2:

5.1

Page 57

NSP1s internal data base (Section 5 . 1 )

Session Control port data base (Section 5.2)

Reserved port data base (section 5.3)

Node data base (Section 5 . 4 )

Buffer pools (Section 5.5)

bases

NSP1s Internal Data Base

This data base contains
Network Management can
describes the data base.

NSP1s internal variables and parameters.
modify some of these (Section 3.2). Table 3

NSP Data Bases and Buffer Pools

Page 5 8

Table 3
NSP's Internal Data Base
+--Ã‘----Ã‘Ã‘--Ã‘--+----_-Ã‘--_--+-----+---Ã‘--------------------------

1 Initial
Bit 1
Width1 Definition
1 Value
1 Name
.....................................................................
1 NSPstate
I "halted"
I 1 I State: "halted" or "running"

1
I
I
+

[--------------+------------+-----+----------------------------------

I
I 0
I 16 I The node address of this NSP
I----Ã‘--Ã‘Ã‘--Ã‘--+---_-Ã‘__--Ã‘-+-----+---Ã‘Ã‘-Ã‘Ã‘-Ã‘---Ã‘----Ã‘-+
1 * I NSP's inactivity time value (in 1
1 NSPinact-tim I O +
I system-dependent units). 0 means1
1
I
1
I
I "no time value" (Section 7.4).
I
I
I
I-----------_-_+--_---__--_-+-_---+--_---_--------_-_----------------+
I NSPdelay
1 2+
1 8 I NSP's "delay factor" (Sect. 6.6) I
I--------------+--__-----_--+__---+-----__--_---_---_------------_---+
1 NSPweight
1 3+
I 8 I NSP's "round trip delay estima- I
!
I
I tion factor" (Section 6.6).
I
I

I NSPself

I-------_---_--+------------+-_---+------------------_---------------+
I NSPretrans
I 5+
1 8 I NSP's "retransmit threshold"

1
1
I

1
1

for I
I determining confidence in network;
I connectivity for a logical link I
I (Section 7 . 5 ) .
I

[--------------+------------+-----+----------------------------------

1 * I The maximum number of ports thar 1
1
1
. I NSP has had simultaneously in a I
1
1
1 state other th-an OPEN.
I
I--------------+--------_--_+----_+-_---__-----_---__--_--__-----_--1 NSPversion
I 4.0
1 * I N S P 1 s version number.
I
I--------------+------__----+-----+------_-----__------_-----__-_-_--Â¥+
1 NSPtotal
I *
I * I The total number of ports N S ? can1
I
I
1
I handle simultaneously.
!

1 NSPmax
1
1

Â¥+

I--------------+--_-----_---+-----+------_--_-----_-_-_---_-_--__---_+

1 NSPbuf
I
1
1
1
I

1
1
I

I
1

I The minimum Session Control rev. I
1 buffer size and the maximum NS?

I transmit segment size for this
1
I implementation (this value is
1
1
I equal to the maximum Routing
1
1
I Layer block size [returned from
1
1
1
1 Routing Layer Read Blocksize.]
1
1
1
1 minus 1 3 , the maximum NSPheader
1
I
I
I size. See Section 5 . 5 )
I--Ã‘-------Ã‘---+Ã‘--Ã‘-----Ã‘--+----Ã‘+---------_--_-Ã‘Ã‘--Ã‘Ã‘--_1 NSPtryhard
I ceiling
1 8 I NSP's "tryhard threshold" for
1
I determining when the tryhard
I
of
1
1
NSPretrans/2!
1 flag should get set (Sect. 5.2)

.....................................................................

1
I
1
I

* This value is not essential to the model implementation.
-

This is a suggested initial value;
implementations
bound to use this as an initial value.

+---------------------------------------------------_---_-_----___--_

are

not

I
I
I
1
I
I
+
1

I
1
I

I
I

Page 59

NSP Data Bases and Buffer Pools
5.2

Session Control Port Data Base
-

This data base consists of a collection of ports.
NSP allocates a
port on a Session Control OPEN or CONNECT-XMT call. A port contains
the minimal information required to maintain a logical link. Table 4
specifies a Session Control port.
Table 4
Session Control Port

1
1 Name

1 Initial [Bit 1
1 Value
IWidthI Definition

+
1
1

1 STATE

1 0 or CI I

+---------------+---------+-----+------------------------------------

......................................................................

I The state of the port.

+---------------+---------+-----+------------------------------------*

+---------------+---------+-----+------------------------------------+

1 TIMERcon
1

1 0

I Message timer value for Connect
1 and Disconnect messages.

i
I
+---------------+---------+-----+-----------------------------------.+
1 TIMERinact
1 0
1 * I Inactivity timer value (Sect. 7.4) 1

+---------------+---------+-----+----------------------------------.--

1 NUMdat
I

1
I
+

I 12

I Number o f next Data Segment
I message to transmit.

+---------------+---------+-----+------------------------------------

Page 60

NSP Data Bases and Buffer Pools
Table 4 (Cont.)
Session Control Port
+---------------

+---------+_----+----------_-------------------------

1 Initial \Bit 1
IWidthI Definition
1 Value

1 Name

.....................................................................
I NUMoth
1 1
1 12 I Number of next Interrupt or Link
I Service message to transmit (data
1
1
1
I type messages other than Data
1
1
1
I Segment).
I
I
I

1
I

I NUMhigh
I

+---------------+---------+-----+------------------------------------+

1
1

I 12
1
I

I Number of highest numbered Data
I Segment message available from
I Session Control.

I 12
I

I Number of highest numbered Data

I Segment message sent by local NS?.

I 0
1

I 12
1

I Number of last Data Segment message1
I acknowledgment sent by local NSP. :

I 0
1
1

I 12

I
1

I Number of last Interrupt or Link
I Service message acknowledgment

+---------------+---------+-----+------------------------------------

1 ACKrcv -dat
1

1 0
1

I Number of highest Data Segment

I 12
1
1

I
1
1

I 0

I The normal data request count that I

1 0

+---------------+----_----+_----+-------------------------_----------

I NUMsent

I 0

+---------------+--_------+_----+-------------------_----------------*

I ACKxmt -dat

+---------------+---------+-----+-------------------------_----------+

I ACKxmt-0th

1
1

! sent by the local NSP.

I message acknowledgment received
1 from remote NSP.

+---------------+---------+-----+------_-----------------------------

I FLOWloc-dat

1
1

I
I

1
1

1 will be sent in the next Data

I ing interrupt data. This variable I
I takes into account the contents of I

1
I
+---------------+-----.----+-----+-----------------------------------+
1 FLOWloc- int
I "emptyn I 2 I The flow control state for receiv- i

1
1

I
I

1
1
1
1

I
I

1 Request message.

I t h e b u f f e r B U F r c v as w e l l a s

I whether or not a new interrupt reI quest should be sent. One of:
"empty"
I
I
'interrupt"
1
'send request"

i
I

I
I
I

I
+
I FLOWremdat
I 0
I 8 I The cumulative normal data request 1
I
1 count received from the remote NSP.1
1
1
+---------------+---------+-----+-------............................
+
I FLOWrem- int
I 1
I 8 I The cumulative interrupt data
I
1
1
I request count received from the
1
1
1
1
1 remote NSP.
1
I
+---------------+----.-----+-----+-----------------------------------+
+---------------+---------+-----+------------------------------------

NSP Data Bases and Buffer Pools

Table 4 (Cont.)
Session Control Port

Page 61

NSP Data Bases and Buffer Pools

Page 62

Table 4 (Cont.)
Session Control Port

1 DELAYstr-tim
1

1 0

1
1

I Round trip time-of-day value for

1
I start of round trip time estimation1
+---------------+---------+-----+-----------------------------------+
1 DELAYmsg-num I 0
1 12 I The number of the Data Segment
i
1
I message currently being timed for I
I
1
1
I the round trip delay estimation.
I
I
I

+---------------+---------+-----+------------------------------------+

1 OTHERstate
1

I "ready" I
1
1

I
I

I,
I

I
I

I The state of the single "Other
1 Data" message being transmitted,
I if any. One of:
"ready"
I
"sent"
I
" t imeout "

I
1

I
I

+---------------+---------+-----+-----------------------------------_-1.

1 OTHERtyp

I
I

I *

I
I
I

1
I

1 CONFIDENCE
I

1 true

1
1

I SIZES~~

I The type of "Other Data" message
1
I being sent, if any. It has meaning1
1 only when OTHERstate is not
1
I "ready". One of:
I
'interrupt"
I
I
I
'interrupt request" I
"data request''
I
I

+---------------+---------+-----+------------------------------------+

I The Boolean "confidence" variable
I for the port.

+---------------+---------+-----+--------------------------------_---

1 16

I The transmit segment size.

+---------------+---------+-----+-------------------------------------

1 TRYHARD
I

---.Ã£----------Ã‘----Ã‘-Ã‘--------Ã‘---------------------------------

+
I The Boolean "tryhard" variable for I
I the port.
I

.........................................
* This value is not essential to the model implementation.

...........................
1

1 false

NSP Data Bases and Buffer Pools
5.3

Page 63

Reserved --Port Data Base

This data base contains a collection of port variables reserved for
NSPts internal use.
NSP uses them to manage responses to received
messages that do not map onto the Session Control port data base.
Table 5 describes a reserved port.
Table 5
Reserved Port
+---------------+---------+--------+-----_---------------_-----------

1
1 Name

1 Initial I Bit
1 Value
I Width

I NODE

1 0

I Definition

.....................................................................

1 16

1 Remote node address.

+
1
I
I

+
I ADDRtmp
I 0
1 16
I Temporary (local) link address. I
+---------------+---------+--------+--------------------------------+
1 ADDRrem
1 0
1 16
1 Remote link address.
I

+---------------+---------+--------+---------------------------------

+---------------+---------+--------+---------------------------------+

I MSGtype

I
1

'none"
1
I
I
I

I 2
1
I

I 0
1
I

I *
1

1 The message type, i f any that
1 must be sent. One of:
I
'no resources"
1
"no link"
I
' none "

+---------------+-Ã‘---Ã‘--Ã‘+--Ã‘Ã‘----+---.----Ã‘-----Ã‘Ã‘---------

I
I
I

1 The circuit number to use to I
1
1 transmit messages to Routing.
I
I One of:
I
I
I
0 (="unspecifiedw)
I
1
1
1
I
1
a circuit number
1
1
I
+---------------+---------+--------+--------------------------------+
1 NEXTHOP
1 0
1 16
1 Node Number
I
1 CIRCUIT
I

+---------------+---------+--------+-------------------_---------_---

5.4

Node Data Base
---

The node data base contains a collection of node descriptors. A node
descriptor is a collection of node-dependent variables and counters.
These are required in processing logical link connections.
When NSP
receives either an outgoing connect request (from Session Control) or
an incoming connect request (via a Connect Initiate message), NSP
attempts to allocate a node descriptor for the remote node if one does
not exist. Failure of such an attempt has the same consequences as
failure to allocate a port. Table 6 describes a node descriptor.

NSP Data Bases and Buffer Pools

Page 64

Table 6
Node Descriptor

1 NODEmsg-xmt

1 Total NSP messages transmitted.

+---------------+---------+--------+---------------------------------+

1 NODEcon-rev
I

1
I

1 NODEcon-xmt

I
1

1
1
1

1
1

1
I

1
1
1

1 Connect Initiate messages
I received.

+---------------+---------+--------+---------------------------------

1 Connect Initiate messages
I transmitted.

+---------------+---------+--------+---------------------------.-------*

1 NODEcon-rej
I
1

+
!

I
1 Connect Initiate messages
I received for which there was r.o i
1 OPEN port.
1

+---------------+---------+--------+---------------------------------+

1 NODEtimeout

1 Number of timeouts causing NSP
I message retransmission.

......................................................................

I * This value is not essential to the model implementation.
'--------------------------------------------------------------------'

I
I
I

Buffer
There can be up to six buffer pools, as. follows:
Larqe transmit buffer pool. Large transmit buffers are requ-ired to
transmit Connect Initiate or Data Segment messages. The form these
buffers tak'e
is implementation-dependent.
Implementations
that
support buffer chaining may require only enough space in a large
transmit buffer to build a message header. Other implementations may

NSP Data Bases and Buffer Pools

Page 65

use buffers no larger than the size Routing can transmit.
size for the pool is one buffer.

The minimum

Small transmit buffer pool. Small transmit buffers are required to
transmit messages other than Connect Initiate or Data Segment. The
minimum size for this pool is one buffer. An implementation may use a
single transmit buffer pool. In this case, the buffers must all be
' large. "
Receive buffer pool. Receive buffers are required to receive an NSP
message from Routing. Minimum buffer size is 230 bytes. This size is
equal to the contents of NSPbuf (Table 3, Section 5.1) plus 13 (the
maximum length of a Data Segment header).
All NSP messages are
received into buffers of the same size. The minimum size for this
pool is one buffer.
Commit buffer pool. Once data is placed in a commit buffer, the
receiving node is committed to keeping it. Such data is acknowledged
to the transmitter. A commit buffer is the same size as a receive
buffer. This buffer pool is not required for the correct operation of
NSP

Cache buffer pool. Cache buffers hold received Data Segment messages
that cannot be acknowledged either because they were received out of
order o r because there is no permanent storage (such as a commit
buffer or a Session Control buffer) for them. A cache buffer is the
same size as a receive buffer. This buffer pool is not required for
the correct operation of NSP.
Event buffer pool. This contains buffers for NSP's event queue for
reading by Network Management. The minimum size for the pool is one
buffer.

6.0

DETAILED FUNCTIONAL MODEL

Section 6 is essentially a model implementation of NSP that defines
the operation of NSP in terms of a high level language. There is no
requirement that an actual implementation conform to either the
structure or the logical flow of this model. This is a specification
of function only. The following variables are used in the model:
o

TIME. This refers to the value of a local
the time of day.

Fields in a message from Section 8.
These
variables and are given in capital letters.

5. These are given in mixed
Data base variables from Section capital
and
s m a l l l e t t e r s olus STATE. NODE. VERSION.
CONFIDENCE, CIRCUIT and NEXTHOP. -

clock
are

that

keeps

all

other

All NSP segment number arithmetic in this section is performed modulo
4096.
A
segment number n is defined to be greater than a segment

Page 66

Detailed Functional Model
number m if 0 < (n - m) < 2048, modulo 4096.

A timer is modeled as a variable in a port. A timer is in one of
three states: stopped, running, or expired. A timer contains a zero
when it is stopped, a time value (the expiration time) greater than
the time of day when it is running, and a time value less than or
equal to the time of day when it has expired.
This section does not describe:
o

The operation of the Network Management interface,

The maintenance of counters in the node data
variable NSPmax in N S P 1 s internal data base,

The handling of N S P f s event queue, or

The handling of port pools.

base

and

the

It is assumed that the above operations are described sufficiently
the description of the Network Management interface in Section 3.

Finally, this section does not describe the operation of an NS?
implementation that requests no flow control or message flow control.
Nor does it describe the operation that would generate a negative
acknowledgment or exercise "on/offW flow control. The operation of
NSP in transmitting to an NSP implementation that uses these other
forms of flow control and acknowledgment is described in Section
2.6.3.
The colloquial language in the model adheres to the following rules:
is the assignment operator

<--

< > means "not equal to"

<= means "less than or equal to"

>= means

"Loop .Endloop" defines a section of logic that executes
repeatedly.
An "Exitloop" causes an exit to the logic
immediately following the "Endloop."

defines a collection of separate
logic sections, each guarded by a Boolean condition. After
the first section with a "true" Boolean guard is executed, an
exit is made to the logic following the "Endif." The implied
Boolean condition on "Else" is "true." That is, the section
following an "Else" is always executed if a previous section
has not been executed.

Comments are near the code to which they apply, either before
or after.

"greater than or equal to"

"If...Elseif...Else...Endif"

Page 67

Detailed Functional Model
Interface Routines

6.1

This section specifies how NSP handles the Session Control calls
described in Section 3.1. The operation is described by a series of
algorithms with comments. The algorithms assume that at each of the
entry points involving a port identifier passed by Session Control,
NSP does the following:
1.

Checks the port identifier for validity.

Maps the port identifier
descriptor, if possible.

onto

Session

Control

port

The port descriptor variables used herein refer to those in the proper
descriptor.
OPEN:
Logical link address assignment (Appendix A )
If (NSPstate = "halted") then
return "no port allocated - NSP halted"
Elseif (Session Control port is available
and a logical link address is assignable) then
allocate Session Control port
ADDRloc <-- assigned link address
STATE <-- "0"
BUFcon <-- Session Control's buffer descriptor
BUFsrc < - - address of "source" argument
return "port allocated" with port identifier
Else
return "port not allocated - insufficient resources"
Endif
CLOSE :
Logical link address deassiqnment (Appendix A)
deassiqn link address in ADDRloc
release resources
CONFIDENCE:
If (STATE = "RUN" or "CC" or "DR" or "DI") then
return CONFIDENCE
Else
return "port in inv;.L id state"
Endif
STATE :
return STATE

Detailed Functional Model

Page 68

CONNECT-XMT:
Logical link address assignment (Appendix A).
Setting FLAGbuf true
causes the connect/disconnect process for the port to send a Connect
Initiate message. NSP passes the circuit,nexthop value to Routing for
subsequent .-transmissionsfor this port. The circuit,nexthop value is
used for loop-back testing.
I f (NSPstate = "halted") then
return "no port allocated - NSP halted"
Elseif (Session Control port is available
and a node descriptor exists or is available
and a logical link address is assignable) then
allocate Session Control port descriptor
allocate and initialize a node descriptor, if necessary
NODErem <-- destination from call
ADDRloc <-- assigned link address
STATE <-- "CI"
BUFcon <-- Session Control's buffer descriptor
CIRCUIT <-- circuit from call
NEXTHOP <-- nexthop from call
FLAGbuf <-- true
return "port allocated" with port identifier
Else
return "port not allocated - insufficient resources"
Endif
CONNECT-STATUS:
Accept or reject data is only available i f the port is in the "RJ" or
"RUN" states.
The data is in BUFacc i f the oort is in the "RUN"
state; the data is in BUFrcv i f the port is in the "RJ" state.
Furthermore, since BUFrcv receives interrupt data once the logical
link is running, Session Control can obtain accept data only once.
The variable FLOWloc int identifies the contents of the BUFrcv buffer.
Setting this variable to 'empty"
allows NSP to receive interrupt data
- on thelogical link.
If (STATE = "RJ") then
Session Control's buf fen <-- BUFrcv
return "connect request rejected"
Elseif (STATE = "RUN") then
I f (FLOWloc int = "accept") then
< - - BUFacc
~ e s s i o n ~ o n t r o l 'buffer
s
Endi f
return "connect request accepted"
Else
return "port not in RUNNING or REJECTED state"
Endif

Page 69

Detailed Functional Model
ACCEPT :
Setting FLAGbuf true will cause the connect/disconnect
process to send a Connect Confirm message.

transmit

I f (STATE = "CR" then
STATE <-- "CC"
BUFxmt <-- Session Control's data
FLAGbuf <-- true
return "link accepted"
Else
return "port not in CONNECT-RECEIVED state"
Endif

REJECT:
Setting FLAGbuf crue causes the connect/disconnect transmit process to
send a Disconnect Initiate message.
I f (STATE = "CR" then
STATE <-- "DR"
BUFxmt <-- Session Control's data
FLAGbuf < - - true
return "link rejected"
Else
return ''pert not in CONNECT-RECEIVED state"
Endif

DISCONNECT-XMT:
Setting FLAGbuf false and STATE to "DI" causes the connect/disconnect
transmit process to send a Disconnect Initiate message only i f there
are no outstanding, unacknowledged data messages.

I f (STATE = "RUN") then
STATE < - - "DI"
BUFxmt I-- Session Control's data
DELAYstr t i m < - -

FLAGbuf 7-- false
return "call accepted''
Else
return "port not in RUNNING state"
Endif

Detailed Functional Model

Page 70

ABORT-XMT :
This routine acts as routine DISCONNECT-XMT except that i t sets
NUMhigh to ACKrcv dat to stop the transmission of data messages and to
allow the transmission of a Disconnect Initiate message.
If (STATE = "RUN") then
STATE <-- "DI"
BUFxmt <-- session control's data
DELAYstr tim <-- 0
stop timer TIMERdat
stop timer TIMERoth
FLAGbuf <-- false
NUMhigh <-- ACKrcv dat
return "call accepted"
Else
return "port not in RUNNING state"
Endi f
DISCONNECT-RCV:
The connect/disconnect process places any received disconnect data
BUFrcv.
If (STATE = "DN") then
If ( ~ ~ F r cempty)
v
then
return "no disconnect data available"
Else
Session Control's buffer < - - BUFrcv
return "disconnect data available"
Endif
Else
return "port not in DISCONNECT-NOTIFICATION state"
Endif
DATA-XMT :
The segmentation module handles this call almost entirely.
If (STATE = "RUN") then
pass call to segmentation module
pass return to Session Control
Else
return "port not in RUNNING state''
Endif
XMT-POLL:
The segmentation module handles this call entirely.
pass call to segmentation module
pass return to Session Control

~etailedFunctional Model

Page 71

DATA-RCV:
The reassembly module handles this call almost entirely. This call is
accepted in the DI state (Section 4.1) to prevent a Session Control
deadlock.
I f (STATE = "RUN", "DIP' or "DNP') then
pass call to reassembly module
pass return to Session Control
Else
return "port not in RUNNING or DISCONNECT-INITIATE state"
Endif

RCV-POLL :
The reassembly module handles this call entirely.
pass call to reassembly module
pass return to Session Control
INTERRUPT-XMT:
The
BUFxmt is the single buffer holding outgoing interrupt data.
variable FLAGint-avail indicates the state of the buffer. When
FLAGint avail is false, then there is no data in it.
Putting
interrust data in it and setting FLAGint avail to true causes the data
transmit process to send an Interrupt message. .
I f (STATE < > RUN) then
return "port not in RUNNING state"
Elseif (FLAGint avail false) then
BUFxmt <-- ~ e s s i o nControl's data
FLAGint-avail < - - true
return "data accepted"
Else
return "data not accepted - insufficient resources"
Endif

Page 72

Detailed Functional Model
INTERRUPT-RCV:

The data receive process places received interrupt data in BUFrcv i f
FLOWloc int = "empty." The receive data process informs this routine
that interrupt data is available
by
setting
FLOWloc int
to
"interrupt.":This routine informs the data transmit process that i t
should request another interrupt message by setting FLOWloc int to
'send request." This causes the data transmit process t o s e n d an
Interrupt Request message.
If (STATE < > RUN) then
return "port not in RUNNING state"
Elseif (FLOWloc int = "interrupt") then
Session ~ontrol'sbuffer < - - BUFrcv
FLOWloc- int < - - "send request"
return "data returned"
Else
return "no data returned"
Endif

6.2

Receive Dispatcher Module

This module has an imbedded process that gives receive buffers to
Routing, polls to get them back, and then gives them to the receive
processes. Although not explicitly modeled in the receive process
algorithms, these processes return the receive buffers to the receive
dispatcher module after the buffers have been processed.
The receive dispatcher module maps received messages onto ports and
parses messages into field contents. Mapping a received message onto
a particular port is described below.
1.

I f the TYPE or SUBTYPE subfields of the MSGFLG field contain
reserved binary values, or if the MSGFLG field is extended,
then discard the message.

Discard a received No Operation message.

A received Connect Initiate messaqe or Retransmitted Connect
Initiate message with DSTADDR = 0 maps onto any Session
Control port with node = NODE, ADDRrem = SRCADDR and STATE < >
'0" or any Session Control port with STATE = " 0 " i f such a
port .exists and if a node descriptor exists or can be created
for the source node. Otherwise, it maps onto any reserved
Otherwise,
port with MSGtyp = "none", if such a port exist
discard the message.

A returned Connect Initiate message or Retransmitted Connect
Initiate maps onto the Session Control port with STATE = "CI"
and SRCADDR=ADDRloc, if such a port exists.
Otherwise,
distard the message.

Detailed Functional Model

Page 73

Treat a received Disconnect Confirm message as a No Resource
message if the REASON field contains a 1, as a Disconnect
Complete message if the REASON field contains a 42, and as a
No Link message if the REASON field contains a 41.

The following messages map onto a Session Control port in t h e
"CI" state with the source node = NODE and DSTADDR = ADDRloc,
if such a port exists. These messages, with the exception of
the Connect Acknowledgment message, also map onto a port in
any other state with source node = NODE, DSTADDR = ADDRloc,
and SRCADDR = ADDRrem, if such a port exists.
o
o
o
o
o

Connect Acknowledgment
No Resources
Connect Confirm
Disconnect Initiate
Disconnect Confirm with REASON < >

1, 41, or 42

I f a Connect Acknowledgment or No Resources message cannot be
mapped onto a Session Control port, discard it. If a Connect
Confirm or Disconnect Initiate message cannot be mapped onto
a Session Control port, map it onto a reserved port with
MSGtyp = "none," if one exists. Otherwise, discard it.
7.

The following messages map onto a Session Control port with
the source node=NODE, DSTADDR=ADDRloc, and SRCADDR=ADDRrem,
if such a port exists.
Disconnect Complete
No Link
Data Segment
Data Acknowledgment
Interrupt
Data Request
Interrupt Request
Other-Data Acknowledgment
A Data Segment, Interrupt, Data Request, or Interrupt Request
message that cannot map onto a Session Control port is mapped
onto a reserved port with MSGtyp = "none," if one exists;
otherwise, it is discarded. Discard the remaining messages
in the above list if they cannot map onto a Session Control
port.

Note that a Session Control port with STATE = "0," "CI,"
'CD," "NR,'I or "NC" does not have a defined value for
ADDRrem. Therefore, NSP cannot map these messages onto such
a port.

Detailed Functional Model
Parsing messages into field contents
The following are special rules:

Page 74
is

generally

straightforward.

Check the QUAL fields of a received Data Segment, Interrupt,
Link Service, Data Acknowledgment, or Other Acknowledgment
message to determine if the fields are valid.
Ignore a
NUMBER field if the QUAL field has an invalid value.
Mask the SEGNUM field of a received Data Segment, Interrupt,
Link Service, Data Acknowledgment, or Other Acknowledgment
message to the low order 12 bits. Ignore the upper 4 bits
regardless of setting.
Mask the LSFLAGS field of a received Link Service message to
the low order 4 bits. Ignore the upper 4 bits regardless of
setting. Check the reserved values of the FCVAL INT and FC
MOD subfields of the LSFLAGS field, however. I f the reserved
values are used, ignore the entire Link Service message.

Page 75

Detailed Functional Model
6.3

Index
- to Routines

Sections 6.4 through 6.9 contain routines that are used in more than
one subsection.
These routines are only defined once. To aid your
reading of the model, Table 7 is an alphabetic list of all the
routines used in these sections. The table shows both the section in
which the routine is defined and the section(s) that call or otherwise
use the routine.
Table 7
Index to Routines Used in Model

+--------------------------------+-------------------+---------------+

1 ALLOCATE

6.9

1 CHECK-ALLOCATE

6.9

+--------------------------------+-------------------+---------------+

6.6.1, 2, 3

6.6.1, 3

+ - + - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +

1 COMMIT-NUMBER

6.5

I DATA-ACK-SENT

6.6.2

6.4.2

6.6.2

I
+

6.6.2

+--------------------------------+-------------------+---------------

1 DATA-ACK-TO-BE-SENT

6.6.2

+ - - - + - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -

Page 76

Detailed Functional Model
Table 7 (Cont.)
Index to Routines Used in Model
+--------------------------------+----------------_--

+---------------

I Routine

1 Defined In

I Used I n

I PROCESS-OT'HER-DATA-ACK

6.4.2

1 REALLOCATE

6.6.1,

6.6.1

.....................................................................

6.4.2

+
1
I
I

+--------------------------------+-------_-----------+---------------+

6.9

2, 3

+--------------------------------+-------------------+---------------

1 SEND-CONNECT-ACKNOWLEDGMENT

6.7

+
I
+
I

+--------------------------------+-------------------+---------------

1 SEND-CONNECT-CONFIRM

6.7

1 SEND-CONNECT-INITIATE

6.7

6.6.1

+
I

6.7

6.6.2

I
I
+
1

+--------------------------------+-------------------+--------------+-----------Ã‘----------------_---+Ã‘-_---____^--------+----Ã‘-Ã‘-----

SEND-DATA-ACK

+--------------------------------+_---______---------+---------------+

SEND-DATA-REQUEST

6.7

6.6.2

6.7

6.6.2

+--------------------------------+------____---------+---------------

1 SEND-DATA-SEGMENT

+
I
+
1

+--------------------------------+-------------------+---------------

I SEND-NO-RESOURCES

6.7

6.6.3

6.6.2

+--------------------------------+-------------------+---------------

1 SEND-OTHER-DATA-ACK

6.7

+--------------------------------+-------------------+---------------+

1 SEND-SMALL-MESSAGE

6.7

1 SET-SWITCH-AND-FLAG

6.4.2

1 SPECULATE-NUMBER

6.5

6.4.2

1 STORE-SEGMENT

6.4.2

+--------------------------------+-------------------+--------------+--------------------------------+-------------------+--------------+--------------------------------+-------------------+---------------

6.5

+ - + - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -

1 TIMEOUT

6.6.2

6.6.1,

1 ROUTING-TRANSMIT

3.3

6.7

1 UPDATE-DELAY

6..4. 2

6.4.1,

+--------------------------------+-------------------+---------------

+-------------------Ã‘----Ã‘-------+-Ã‘--------Ã‘--------+-Ã‘-----Ã‘--------------------------------+-------------------+---------------'

+
I
+
I
+
I
+
I
+
I
+
1

Page 77

Detailed Functional Model
Receive Processes

6.4

This section contains algorithms for implementing
processes:

the

three

Connect/Disconnect Receive Process (Section 6.4.1)

Data Receive Process (Section 6.4.2)

Reserved Receive Process (section 6.4.3)

receive

6.4.1 Connect/Disconnect Receive Processes - These processes receive
messages from the receive dispatcher module. The message variables
below refer to the information content of message fields as returned
from the receive dispatcher module. There is one connect/disconnect
receive process for each Session Control port.

Loop
This process loops forever.
Oncase (received message type)
When this process receives a message,
statement.

execute

the

appropriate

case

Case (Connect Acknowledgment)

I f this message is received when the link is in the "CI" state, then
observe the round trip delay (Section 7.3). This value is equal to
the current time of day minus the time :he Connect Initiate message
was sent.
This latter time is keot in DELAYstr-tim.
Routine
UPDATE-DELAY makes this calculation and
updates
the
variable
NODEdelay.
I f (STATE = "CI") then
STATE <-- "CD"
Call UPDATE-DELAY
Endi f
Case (Connect Initiate or Retransmitied Connect Initiate)
A Connect Initiate message may contain any value in the
INFO field.
However,
the SERVICES field must contain "none," "segment" or
'message".
Setting FLAGbuf true causes
the
connect/disconnect
transmit process to send a Connect Acknowledgment message.

Detailed Functional Model

Page 78

I f (STATE = "0") then

If (SERVICES = "none," "segment," or "message") then
buffer whose descriptor is in BUFcon <-- DATA-CTL
NODE <-- node from Routing
location whose address is in BUFsrc <-- NODE
ADDRrem < - - SRCADDR
FLOWrem typ <-- SERVICES
VERSION<-- INFO
SIZEseg < - - min of (SEGSIZE, size of a large transmit
buffer minus the maximum NSP header size)
FLAGbuf <-- true
STATE < - - "CR"
I f (NODE = NSPself) then
CIRCUIT <-- CIRCUIT received from Routing
NEXTHOP <-- NEXTHOP received from Routing
Else
CIRCUIT < - - "unspecified"
Endi f
Endi f
Elseif (STATE = "CR", "CC", or "DR") then FLAGbuf < - Elseif (STATE = "RUN", "CD", or "DI") then discard.

true

Message was a duplicate.

Case ("returned to sender" Connect Initiate or Retransmitted
Connect Initiate)
If (STATE = "CI") then STATE < - Else discard

"NC"

Detailed Functional Model

Page 79

Case (Connect Confirm)
The testing of INFO and SERVICES is the same for a Connect Confirm
message as for a Connect Initiate message. Setting the variable
FLOWloc- int to "accept" informs the interface routines that there is
accept data available.
Since the "RUN" state can be ente'red, start
the inactivity timer (Section 7.4). Call UPDATE-DELAY for the same
reasons as when a Connect Acknowledgment message is received.
If (SERVICES = "none," "segment," or "rnessaqe") then
If (STATE = "CI" or "CD") then
ADDRrem < - - SRCADDR
FLOWrem typ < - - SERVICES
VERSION<-- INFO
SIZEseg < - - min of (SEGSIZE, size of a large transmit
buffer -13)
BUFacc <-- DATA-CTL
TIMERinact <-- TIME + NSPinact tim
If (STATE = "CI") then Call UPBATE-DELAY
STATE < - - "RUN"
Endif
If (STATE = "RUN") then
FLAGdat-ack < - - true
Endif
Endif
Case (Disconnect Initiate)
In all cases below, setting FLAGbuf true causes the connect/disconnect
transmit process to send a Disconnect Complete message.

I f (STATE = "CI" or "CD") then
A Disconnect Initiate message received in either of these two states
indicates a rejection of a previously transmitted Connect Initiate
message.
ADDRrem < - - SRCADDR
first two bytes of BUFrcv < - - REASON.
remaining bytes of BUFrcv < - - DATA-CTL
FLAGbuf < - - true
I f (STATE = "CI") then Call UPDATE-DELAY
STATE < - - "RJ"
Elseif (STATE = "RJ") then
A Disconnect Initiate message received in this state is assumed to be
a
duplicite caused by the retransmission of the message that
originally caused the transition to the "RJ" state.
FLAGbuf <-- true
Elseif (STATE = "RUN") then
A Disconnect Initiate message
disconnect of a running link.

received

this

state

indicates

Detailed Functional Model

Page 80

first two bytes of BUFrcv < - - REASON
remaining bytes of BUFrcv < - - DATA-CTL
FLAGbuf <-- true
STATE <-- "DN"
DELAYstr tim < - - i
Stop timer TIMERdat
stop timer TIMERoth
Elseif (STATE = "DIC" or "DI") then
A Disconnect Initiate message received in either of these states is
assumed to be a result of a disconnect collision. In the case of the
'DICn state, this message may have been delayed in Routing until after
the reception of the Disconnect Complete message that caused the
transition to the "DIC" state. In the case of the "DI" state, there
has been a crossing of Disconnect Initiate messages in Routing. In
either case, the response is the same.
FLAGbuf < - - true
STATE < - - "DIC"
DELAYstr tim < - - 0
stop timer TIMERcon
Elseif (STATE = "DN") then
A Disconnect Initiate message received in this state is assumed to be
a
duplicate caused by the retransmission of the message that
originally caused the transition to the "DN" state.
FLAGbuf < - Endif

true

Case (No Resources)
I f (STATE = "CI") then
STATE < - - "NR"
Call UPDATE-DELAY
Endi f
Case (Disconnect Complete)
Stopping timer TIMERcon prevents the retransmission
Initiate message after a timeout.
If (STATE = "DR" or "DI") then
stop timer TIMERcon
stop timer TIMERdat
stop timer TIMERoth
Call UPDATE-DELAY
Endi f
If (STATE = "DRn) then STATE <-If (STATE = "Din) then STATE <--

"DRC"
"DIC"

Case (No Link)
Stopping the timers prevents any retransmissions.

Disconnect

Detailed Functional Model

Page 81

I f (STATE = "CC," "RUN," "DR" or "DI1') then
stop timer TIMERcon
stop timer TIMERdat
stop timer TIMERoth
STATE <-- "CN"
Endif

Case (Disconnect Confirm)
This case is included only for compatibility with version 3.1.
This
case occurs when a 3.1 system sends this message rather than a
Disconnect Initiate message for a Session Control rejection of a
Connect Initiate message.
It also occurs when an NSP version 3.1
system receives a message in error.
If (STATE = "CI") then
first two bytes of BUFrcv < - - REASON
STATE <-- "RJ"
CALL UPDATE-DELAY
Elseif (STATE = "CC" or STATE = "RUN") then
stop timer TIMERcon
stop timer TIMERdat
stop timer TIMERoth
STATE <-- "CN"
Endi f
Endcase
Endloop

6.4.2 Data Receive Processes - These processes receive messages from
the receive dispatcher module. The message variables below refer to
the information content of message fields as returned from the receive
dispatcher module.
There is one Session Control port data receive
process for each Session Control port.
7

Loop
This process loops forever.
I f [(STATE = "CC" or "RUN")
or (STATE = "DIW and NUMhigh < > ACKrcv-dat)] then

This process only runs !.ir ports in the "CC," "RUN," or "DI" states.
It runs for ports in the "CC" state to receive any data type message
as defined by the case statements since the reception of these message
types will cause a transition to the "RUN" state. It runs for ports
in the "RUN" state to receive normal data, interrupts, Link Service
messages, and acknowledgments. It runs for ports in the "DI" state to
receive data while there is outstanding, unacknowledged, transmitted
data. This latter case is true when NUMhiqh < > ACKrcv-dat.

Page 82

Detailed Functional Model
I f (FLOWloc-dat = 0 ) then

FLOWloc dat contains the value, i f any, currently being transmitted or
retransmitted in a Data Request message. I f it is zero, a new Data
Request message can be sent. The routine SPECULATE-NUMBER returns the
value to be sent in the next Data Request message.
Call SPECULATE-NUMBER (low-overhead = "false")
FLOWloc-dat < - - returned value
Endif
The routine COMMIT-NUMBER returns the highest number of a previously
received Data Segment that has been committed to either a commit
buffer or a Session Control receive buffer.
Call COMMIT-NUMBER
I f (returned value < > ACKxmt -dat) then

I f the returned number is different from the last acknowledgment
number sent, then a new acknowledgment must be sent. The variable
ACKxmt -dat contains the data acknowledgment number to be sent in any
Data Segment or Data Acknowledgment message transmitted. Setting
FLAGxmt ack true causes the data transmit process to send a Data
~cknowledgment message i f a Data Segment message does not need to be
transmitted.
FLAGdat ack < - - true
ACKxmt-dat < - - returned value
Endif
Endif
I f (message is received) then
I f (STATE = "CC" and message type = "Data A~knowledgment'~,
"Interrupt", "Data Request", "Interrupt Request"
or "Other-Data-Acknowledgment") then
~

I f this message is taking the port out of the "CC" state, then make an
of t h e round t r i p delay to the r e m o t e NS? ( S e c t i o n 7 . 3 1 .
Since the port just entered the "RUN" state, start the inactivity
timer (Section 7.4).
estimate

STATE <-- "RUN''
FLAGbuf < - - false
Call UPDATE-DELAY
stop timer TIMERcon
CONFIDENCE <-- true
COUNTretrans < - - 0
Endif
Receiving any message restarts the inactivity timer.
TIMERinact <-- TIME + NSPinact tim
Oncase (received message type)When a message is received, execute the appropriate case statement.

Page 83

Detailed Functional Model
Case (Data Segment)
Process the acknowledgment field of a received
independently from the rest of the message.

Data

Segment

messaqe

If (ACKNUM field present) then
Call PROCESS-DATA-ACX
Endi f
If (ACKOTH field present) then
Call PROCESS-OTHER-DATA-ACK
Endi f
If (SEGNUM > ACKxmt dat) then
Call STORE-SEGMENT with DATA, EOM (from MSGFLG), ar,d
SEGNUM
Else
FLAGdat-ack < - - true
Endif
Case (.Interrupt1
Process the acknowledgment field of a received
independently from the rest of the messaqe.

Interrupt

message

I f (ACKNUM field present) then
Call PROCESS-OTHER-DATA-ACK
Endi f
I f (ACKDAT field present) then
Call PROCESS-DATA-ACK
Endif
If (SEGNUM = ACKxmt -0th + 1 and FLOWloc- int = "empty") then
This model of NSP can only buffer one received Interrupt message at a
time (Section 7.2). Its number must be one greater than the number of
the last other-data message
accepted
(contained
in
variable
ACKxmt 0th). When the variable FLOWloc int contains "empty," there is
buffer BUFrcv.
Setting FLAGO:~ ack true causes the data
room
transmit process to acknowledge this ~nterruptmessage.

BUFrcv <-- DATA
FLOWloc int <-- "interrupt"
ACKxmt 0th <-- ACKxmt -0th + 1
F L A G ack
~ ~ <~- - true
Elseif (SEGNUM <= ACXxmt -0th) then
FLAGoth-ack < - - true
Endi f

Page 84

Detailed Functional Model
Case (Data Request)
Process the acknowledgment field of a received
independently from the rest of the message.

Data

Request

message

If ,-(ACKNUMfield present) then
Call PROCESS-OTHER-DATA-ACK
Endi f
If (ACKDAT field present) then
Call PROCESS-DATA-ACK
Endif
If (SEGNUM = ACKxmt -0th + 1) then
This model of NSP processes only one other-data message at a time
I t processes each one to completion. The number of
(Section 7.2).
the one it wants to process next is one greater than the one that i t
has most recently accepted and processed (and whose number is
contained in ACKxmt-0th).
Basically, the algorithm for processing a Data Request message is
check its validity. Discard it i f it is invalid. I f it is valid,
1 )

(2)
(3)
(4)

Store the data "send/do not send" switch in variable FLOWrem
sw.
Increment the acknowledgment number for the
other-data
channel.
Set the flag FLAGoth ack to true to force the data transmit
process to acknowledge the receipt of this message. (Use the
routine SET-SWITCH-AND-FLAG.)
Update the variable FLOWrem dat, i f necessary, by adding the
count from the Data ~ e q u e s t m e s s a g eto it.
I f (FLOWrem typ = "none") then
Call SET=SWITCH-AND-FLAG
Elseif (FLOWrem-typ = "segment") then

The following two statements define the validity check for a received
Data Request message from a remote NSP that receives with "segment1'
flow control.
I f (-128 <= FCVAL < = 127) then
I f (-128 < = FLOWrem-dat + FCVAL < = 127) then
FLOWrem dat < - - FLOWrem dat + FCVAL
Call SET-SWITCH-AND-FLAG
Endif
Endif
Elseif

-typ = "sess,ion-control-message1' ) then

( FLOWrem

The following two statements define the validity check for a received
Data
Request
message
from
a remote NSP that receives with
'lsession-corrtrolmessage" flow control.
If

( 0 < = FCVAL <=

127) then

Detailed Functional Model

Page 85

If ( 0 < FLOWrem dat + FCVAL <= 127) then
FLOWrem dat 7-- FLOWrem dat + FCVAL
Call SET-SWITCH-AND-FLAG
Endif
Endi f
Endif
Elseif (SEGNUM < = ACKxmt 0th) then
FLAG 0th-ack < - - true'
Endif
Case (~nterrupt~ e q u e s t )
Process the acknowledgment field of a received Interrupt
message independently from the rest of the message.

Request

I f (ACKNUM field present) then
Call PROCESS-OTHER-DATA-ACK
Endif
If (ACKDAT field present) then
Call PROCESS-DATA-ACK
Endif
I f (SEGNUM = ACKxmt -0th + 1) then
The message number check for received Interrupt Request messages is
the same as for received Interrupt and Data Request messages. The
following statement defines the validity check for a
received
Interrupt'Request message.
I f (FCVAL >= 0 and 0 < = FLOWrem int + FCVAL < = 127) then
FCVAL
FLOWrem in: < - - FLOWrem int
ACKxmt 5th < - - ACKxmt -0th + 1
F L A G-ack
~ ~ <~- - true
Endif
Elseif (SEGNUM < = ACKxmt 0th) then
FLAG 0th-ack < - - trueEndif
Case (Data Acknowledgment)
Call PROCESS-DATA-ACK
I f (ACKOTH field present) then
CALL PROCESS-OTHER-DATA-ACK
End i f
Case (Non-Data Acknowledgment)
Call PROCESS-OTHER-DATA-ACK
If (ACKDAT field present) then
Call PROCESS-DATA-ACK
Endif
Endcase
Endif
Endloop
The data receive processes call the following routines:

Detailed Functional Model

Page 86

PROCESS-DATA-ACK:
In the following routine, the variables NUMBER and QUAL are the
contents of the fields of the same names from the received data
segment, Data Acknowledgment Message or Data Request Message.

I f (ACKrcv-dat <= NUMBER <= NUMsent) then
If NUMBER is not greater than or equal to ACKrcv dat, then this
acknowledgment has been explicitly or implicitlyprocessed before
(NUMBER is processed when it is equal to ACKrcv dat in case QUAL="nak"
or QUAL="cross sub-channel nak"). I f it is not less than or equal to
NUMhigh, then it is acknowledging a message that was never sent.
In
either case, ignore the acknowledgment.
TRYHARD c - - false
CONFIDENCE < - - true
COUNTretrans < - - 0
The following "If" block updates
the
flow
FLOWrem dat) that allows data transmission.
parallelconstructions here:
(1)
2 )

control
variable
Note that there are

NM(ACKrcv dat + 1, NUMBER) is the number of "endof-messag~"
data
segments
in
the
range
(ACKrcv dat + 1) to NUMBER, and
(NUMBER- ACKrcv dat)
is
the
number of data segments
in the same range.
If (FLOWrem typ = "segment") then
FLOWrem dat < - - FLOWrem dat - (NUMBER - ACKrcv-dat)
Elseif ( ~ ~ 8 ~ typ
r e m= "message")
FLOWrem-dat 7-- FLOWrem-dat - NM(ACKrcv -dat + 1 , NUMBER)
Endif
If ((QUAL = "nak" or QUAL = "cross sub-channel nak") or NUMdat
<= NUMBER) then
NUMdat <-- NUMBER + 1
Endif

I f either this acknowledgment was a negative acknowledgment or the
number of the next Data Segment message that was going to be sent
(contained in NUMdat) is less than or equal to the number just
acknowledged, then set the number of the next Data Segment message to
transmit to the number just acknowledged plus one.
ACKrcv-dat <--

NUMBER

The following code restarts the data retransmission
there is remaining unacknowledged, transmitted data.

timer

only

stop timer TIMERdat
If (ACKrcv dat < NUMsent) then
TIMER^^^ <-- TIME + (NODEdelay * NSPdelay)
Endif
I f (DELAYmsg-num <= ACKrcv -dat and DELAYstr-tim < > 0 ) then

Detailed Functional Model

Page 87

I f DELAYstr-tim is non-zero, then a Data Segment message is being
timed for an update to the round trip delay estimate (see Section
7.3). I f the Data Segment message being timed (whose number is
contained in DELAYmsq num) has just been acknowledged, then calculate
the round trip delay for that message.

Call (.lPDATE-DELAY
Endif
Endi f
PROCESS-OTHER-DATA-ACK:
In the following routine, the variables NUMBER and QUAL are the
contents of the fields of the same name from the received Interrupt,
Data Request, Interrupt Request, Other-Data-Acknowledgment message, or
Data Segment message.
I f (NUMBER=NUMoth-1 and (QUAL="nakl'or QUAL="cross sub-channel
nak") ) then
OTHERstate < - - "timeout"
Endi f
I f (NUMBER = NUMoth and OTHERstate < > "ready") then

NUMoth contains the number of the single, outstanding other-data
message, if any (Section 7.2). OTHERstate is equal to either "sent"
or "timeout" (i.e., not equal to "ready") if there is .such an
outstanding message.
If the message is acknowledged, stop the
retransmission timer for the message.
stop timer TIMERoth
TRYHARD < - - false
CONFIDENCE <-- true
COUNTretrans < - - 0
Handle a negative acknowledgment in the same manner as a timeout.

I f the message was positively acknowledged, then send a new other-data
message.

Setting OTHERstate to "ready" allows the data transmit process to send
another other-data message.
NUMoth contains the number of the next
other-data message that will be transmitted.
OTHERstate <-- "ready"
NUMoth <-- NUMoth + 1
If (OTHERtyp = "interrupt") then
OTHERtyp contains the type of other-data message that was sent and has
just been acknowledged.
I f it was an Interrupt message, then a new
one may be buffered into BUFxmt. Indicate this condition by setting
FLAGint -avail to false. Decrement the remote interrupt request Count.

Page 88

Detailed Functional Model
FLAGint-avail <-- false
FLOWrem int <-.- FLOWrem int - 1
Elseif E OTHER^^^ = "data request") then

If a Data Request message has just been acknowledged, then clear the
count value contained in i t , allowing the data receive process to
obtain a new speculate number that can be sent in the next Data
Request message.
FLOWloc-dat <-Endif
Endi f

The acknowledgment of an Interrupt Request message does not require
any additional explicit handling.
This is because a new Interrupt
Request message cannot be sent until session control has received the
interrupt data whose request was just acknowledged (Section 7.2).
SET-SWITCH-AND-FLAG:
This routine stores the data "send/do not send" value from a received
Data Request message in FLOWrem sw and sets FLAGoth-ack true to
indicate that an other-data acknowledgment is required.
FLOWrem sw < - - FC MOD
ACKxmt 5th <-- ACKxmt -0th + 1
F L A G O-~ack
~ < - - true
Both the data receive processes and the
processes call the following routine:

connect/disconnect

receive

UPDATE-DELAY:
This routine updates the NODEdelay variable in a node descriptor.
Call the routine with a port argument. In this code, "temp" is a
temporary variable.
1 f ( D E L ~ Y s t r tirn < > 0 ) t h e n

~ f ( ~ ~ ~ ~ d= e0)then
l a y
NODEdelay <-- TIME - OELAYstr-tirn
Else
temp < - - TIME - DELAYstr tirn
temp < - - temp - ~ 0 ~ ~ d e l a y
NODEdelay <--. NODEdelay + (temp / (NSPweight + 1))
Endif
DELA'istr-tim <-- 0
Endi f

Detailed Functional Model

Page 89

6.4.3 Reserved ~ e c e i v e Processes - These
processes
received messages that map onto a reserved port.
reserved port process for each reserved port.

handle
all
There is one

Loop
This process loops forever.
I f (a message is received) then
If (the message is a Connect Initiate) then

Setting MSGtyp to "no resources" causes
process to send a No Resources message.

the

reserved

port

transmit

NODE <-- source node address
ADDRrem < - - SRCADDR
MSGtyp < - - "no resources"
CIRCUIT < - - CIRCUIT received from Routing
NEXTHOP < - - NEXTHOP recieved from Routing
Elseif (the message is a Connect Confirm, Disconnect Initiate
Data Segment, Interrupt, Data Reques:, or Interrupt
Request) then
Setting MSTtyp to "no-link" causes the reserved por:
to send a No-Link message.

transmit

process

NODE < - - source node address
ADDRrem <-- SRCADDR
ADDRtmp < - - DSTADDR
MSGtyp < - - "no-link"
CIRCUIT < - - circuit received from Routine
NEXTHOP < - - nexthop received from Routing
Endif
Endi f
Endloop
2

6.5

Reassembly Module

The reassembly module has two functions. ~ i r s t , i:
maps data from
Data Segment messages into Session Control buffers according to the
rules implied by the Session Control interface description.
Because
of this, the DATA-RCV call is passed to this module from the interface
routines. Second, it manages the cache and commit buffer pools. This
function includes flow control policy establishment. That is, this
module is aware of the amount of buffering available via Session
Control receive buffers, cache buffers, and commit buffers. I t usesthis information to produce normal data'request counts to be sent in
Data Request messages. The data transmit processes execute the flow
control mechanism (in other words, the
Data
Request
message
transmission).

Detailed Functional Model

Page 90

The detailed description of the operation of this module is beyond the
scope of this' specification.
However, it must operate with the
following restriction with respect to the management of the cache
buffer pool.
It must not discard the data from a received Data
Segment message for a given Session Control port if there is data from
a higher numbered Data Segment message in the cache for the same port.
Appendix C contains an example of this module.
The data receive processes obtain changes in the number of Data
Segment messages that should be received for a given port by calling
this module. The data receive processes store these values in the
corresponding ports. In the most general case, the reassembly module
may be requesting data for which there is not necessarily any
guaranteed storage.
Therefore, the number of segments that the
reassembly module wants to receive for a port at any given time is
referred to as the "speculate number" for the port.
When the call to "SPECULATE-NUMBER" returns a non-zero value NSP will
transmit a Data-Request messaqe. The decision to send this messace
represents a tradeoff between the benefit of precise control over the
flow of arriving messages and the cost of sending Data-request
messages and their acknowledgments.
The
cost
of
sending
a
Data-Request messaqe depends on whether the Data-Request message can
piggyback a data acknowledgment. In order for the reassembly module
to
make
intelligent policy decisions a parameter is defined,
low-overhead, which is used to inform the reassembly module whether
sending a Data-Request message at this time will be inexpensive. The
data receive processes obtain the speculate number for a port by
issuing the following call:
SPECULATE-NUMBER (port id, low-overhead ;
port id:

a port identifier

low-overhead:
return:

return)

low-overhead flag

the current number of data segments
would like to receive.

that

this

module

The data receive processes periodically obtain the highest segment
number committed to either a commit or session control buffer. This
value is the acknowledgment number to be sent to the remote NSP
The data receive processes obtain this number by issuing the
module.
following call:
COMMIT-NUMBER (port id;
port id:

return)

a port identifier

return:
the highest segment number-committed
The data receive processes attempt to put data from received Data
Segment messages into a cache, commit, or session control receive
buffer by issuing the following call:

Page 91

Detailed Functional Model
STORE-SEGMENT (port id, data, eom, number)
port id:

a port identifier

data:

data from a Data Segment message

eom:

one of:

number:

6.6

data is end-of-message

data is not end-of-message

the segment number of the Data Segment message

Transmit Processes

This section contains algorithms for implementing the following:
o

Connect/disconnect transmit process (Section 6.6.1)

Data transmit processes (Section 6.6.2)

Reserved transmit processes (Section 6.6.3)

6.6.1 Connect/Disconnect
Transmit
Processes - These
processes
transmit Connect Initiate, Connect Acknowledgment, Connect Confirm,
Disconnect Initiate, and Disconnect Complete messages. There is one
session control port connect/disconnect transmit process for each
Session Control port.
Loop
This process loops forever. In general, if FLAGbuf is true a
or disconnect message requires transmission.

connect

I f (STATE = "DI" and FLAGbuf false
and NUMhigh = ACKrcv -dat and TIMERcon not running) then

This test causes this process to attempt to send a
message only if:

2 )

(3)

isc connect ~nitiate

Session Control requested a disconnection (i.e., STATE =
"DI"):
there are no outstanding, unacknowledged
Data
Segment
messages (NUMhigh = ACKrcv dat); and
a previously transmitted ~Tsconnect Initiate message, i f any,
is not being timed out (TIMERcon not running).

Detailed Functional Model

Page 92

FLAGbuf < - - true
DELAYstr-tim <-- TIME
Endif
If (timer TIMERcon expired and STATE = "CI", "CC", ' D I " or "DR")
then
I f the retransmission timer has expired,
NSP
increments
the
retransmission count and attempts to send a connect or disconnect
message.
FLAGbuf < - - true
Call TIMEOUT
Endif
When FLAGbuf is true, a connect or disconnect message requires
transmission.
When FLAGcon-alloc is true, permission to transmit has
been requested from the transmit allocation module.
These two
variables act together to form a state variable with 4 states.
Conditions that require a message to be sent can change dynamically.
This process has to request permission to transmit but has to take
back a request it previously made if it no longer must send a message.
Therefore, interpret these variables as follows:
FLAGbuf true, FLAGcon alloc false: request permission to send.
FLAGbuf true, ~ L ~ ~ c o n a l ltrue:
o c attempt message transmission.
FLAGbuf false, FLAGCO; alloc true: take back permission request.
FLAGbuf false, ~ L ~ ~ c-o n a l lfalse:
oc
do nothing.
I f (FLAGbuf true and FLAGcon-alloc false) then
Call ALLOCATE
FLAGcon alloc < - - true
Elseif ( F L A G ~ Ufalse
~
and FLAGcon-alloc true) then
Call DEALLOCATE
FLAGcon alloc < - - false
Elseif ( F L ~ G ~
true
U ~ and FLAGcon-alloc true) then
If (CHECK-ALLOCATE) then

CHECK-ALLOCATE is a Boolean function in the transmit allocation module
that returns true if and only if permission to transmit has been
granted. The state of the port determines the message to be sent.
If (STATE = "CI") then
DELAYstr tim <-- TIME
Call SEND-CONNECT-INITIATE
with data addressed in BUFcon
Endi f
If (STATE = "DIC," "RJ," or "DN") then
Call SEND-DISCONNECT-COMPLETE
Endi f
If (STATE = "DR" or "DI") then
If (DELAYstr tim = 0 ) then DELAYstr-tim <-- TIME
Call SEND-DISCONNECT-INITIATE
Endif

Detailed Functional Model

Page 93

I f (STATE = "CR") then Call SEND-CONNECT-ACKNOWLEDGMENT
If (STATE = "CC") then
If (DELAYstr tim = 0) then DELAYstr-tim < - - TIME
Call SEND-CONNECT-CONFIRM
Endif

If the transmission was successful, this process must take back its
request for permission to transmit (to allow another process to be
given an equal chance to transmit).
If (success) then
Call DEALLOCATE
FLAGcon alloc < - - false
F L A G ~ U ~ < -false
I f (STATE = "CC," "DI," or "DR") then
If not (STATE = "CC" and VERSION = 3.1) then
If (NODEdelay = 0) then
This means that there is no current round trip delay estimate to the
remote node.
The 5 seconds is a suggested value;
it is not
mandatory.
TIMERcon < - - TIME + 5 seconds
Else
An estimate does exist.
TIMERcon < - - TIME + (NODEdelay * NSPdelay)
Endif
Endif
Endif
I f (STATE = "CC" and VERSION = 3.1 ) then
STATE <-- "RUN"
stop timer TIMERcon
CONFIDENCE <--true
COUNTretrans < - - 0
TIMERinact < - - TIME + NSPinact -tim
Endif
Else
If transmission is unsuccessful, calling REALLOCATE will give other
ports a chance to transmit without removing this port for contention
for Routing resources. This process leaves FLAGbuf true.
his causes
the process to request permission to transmit again.
Call REALLOCATE
Endif
Endif
Endif
Endloop

Detailed Functional Model

Page 94

6.6.2 Data Transmit Processes - These processes send Data Segment,
Interrupt, Data Request, Interrupt Request, Data Acknowledgment, and
Other-Data Acknowledgment messages.
There is one data transmit
process for each Session Control port.

Loop
This process loops forever.
The data receiveprocess for the port puts the highest number of an
acknowledged Data Segment message in ACKrcv dat. This process informs
the segmentation module of this value by calling ACK-SESSION-CONTROL.
It obtains the highest segment number available from the segmentation
routines via function LAST.
Call ACK-SESSION-CONTROL with ACKrcv -dat
If (STATE = "RUN") then NUMhigh <-- LAST
I f [STATE = "RUN" or (STATE = "DI" and NUMhigh
then

ACKrcv -dat)]

With the exception of the processing above, this process does nothing
for a port that is not in either the "RUN" state or in the "DI" state
with outstanding, unacknowledged Data Segment messages (NUMhiqh < >
ACKrcv-dat).
If (timer TIMERdat expired) then
If the data retransmission timer expires, then the number of the next
Data Segment message to transmit is one greater than the highest
segment acknowledged by the remote NSP.
NUMdat <-- ACKrcv -dat + 1
Call TIMEOUT
Endi f
If (timer TIMERoth expired) then

I f the other-data retransmission timer expires, record the expiration
in the state variable OTHERstate. This is possible since there can be
at most one outstanding, unacknowledged other data message in this
model of NSP.
OTHERstate <-Call TIMEOUT
Endif

"timeout"

The tests below are completely analogous to the tests performed in a
connect/disconnect transmit process. The only difference is that the
need to transmit a connect or disconnect message could be determined
by ewamining a single flag (FL~Gbufl. But the need to send a data
type message is determined by a complicated Boolean function of
variables in the port.
The Boolean function MESSAGE-TO-BE-SENT
returns true if a message requires transmi,ssion and is used below in a
manner analogous to FLAGbuf in a connect/disconnect transmit process.
If (MESSAGE-TO-BE-SENT and FLAGdat-alloc false) then
Call ALLOCATE
FLAGdat-alloc <-- true

Detailed Functional Model

Page

Elseif (not MESSAGE-TO-BE-SENT and FLAGdat-alloc true) then
Call DEALLOCATE
FLAGdat alloc <-- false
and FLAGdat -alloc true) then
Elseif (MESSAGE-TO-BE-SENT
I f (CHECK-ALLOCATE) then
-

- -

I f permission to transmit has been granted, then determine the type of
message to transmit by testing a collection of Boolean functions of
variables in the port. The order in which these functions are tested
is important and is part of the specification. That is, if more than
one type of data message may be transmitted, the type that must be
transmitted
first
is
important.
Also,
if
transmission is
unsuccessful, call REALLOCATE for the same reasons as in
the
connect/disconnect transmit processes.

If (INTERRUPT-TO-BE-SENT) then
Call SEND-INTERRUPT
If (success) then
The routine OTHER-DATA-SENT performs processing common
to
the
successful transmission of Interrupt, Data Request, and Interrupt
Request messages.
OTHERtyp < - - "interrupt"
Call OTHER-DATA-SENT
Else
Call REALLOCATE
End i f
Elseif (INT-REQUEST-TO-BE SENT) then
Call SEND-INTERRUPT-REQUEST
I f (success) then
OTHERtyp < - - "interrupt request"
Setting FLOWloc int to "empty" allows data from a received
message to be saved in BUFrcv by the data receive process.

Interrupt

FLOWloc int < - - "empty"
Call OTHER-DATA-SENT
Else
Call REALLOCATE
Endi f
Elseif (DATA-REQUEST-TO-BE-SENT) then
Call SEND-DATA-REQUEST
I f (success) then
OTHERtyp < - - "data request"
One reason that a Data Request message may be sent is that the
inactivity timer has expired (Section 7.4). If this is the case, the
inactivity timer is restarted.

Detailed Functional Model

Page 96

If (TIMERinact expired) then
TIMERinact < - - TIME + NSPinact-tim
Endif
Call OTHER-DATA-SENT
If (VERS.ON = "4.0") then
FLAGdat-ack < - - false
Endi f
Else
Call REALLOCATE
Endif
Elseif (DATA-TO-BE-SENT) then
I f there is no Data Segment currently being timed for an update to the
estimated round trip delay (DEL~ystrtim = O), then save the current
time of day. Also save the number of the Data Segment being timed.
If (DELAYstr tim =0) then
DELAYstr Tim < - - TIME
~ ~ ~ ~ y m- s g -<n- - u mNUMdat
Endif
Call GET-SEGMENT with segment number NUMdat
Call SEND-DATA-SEGMENT with returned values
If (success) then
The routine DATA-ACK-SENT performs processing common to the successful
transmission of Data Segment and Data Acknowledgment messages.
I f the Data Segment just sent had a number one greater than the
highest number acknowledged by the remote NSP, then start the
retransmission timer. The value for this timer is a constant times
the current estimated round trip delay (Section 7.3).

If (NUMdat = ACKrcv dat+l) then
TIMERdat < - - TIME + (NODEdelay * NSPdelay)
Endi f
Increment the number of
(NUMdat)

the

Data

Segment

If (NUMdat > NUMsent) then
NUMsent = NUMdat
Endi f
NUMdat <-- NUMdat + 1
Call DATA-ACK-SENT
If (VERSION = "4.0") then
FLAGoth-ack < - - false
Endif
Else
Call REALLOCATE
Endif
Elseif (OTHER-DATA-ACK-TO-BE-SENT)then
Call SEND-OTHER-DATA-ACK
If (success) then

transmitted

Detailed Functional Model

Page 97

The routine OTHER-ACK-SENT performs processing
common
to
the
successful transmission of Interrupt, Data Request, Interrupt Request,
and Other-Data Acknowledgment messages.
Call OTHER-ACK-SENT
Else
Call REALLOCATE
Endif
Elseif (DATA-ACK-TO-BE-SENT) then
If (VERSION = "4.0") then
Call SPECULATE-NUMBER (low-overhead = "true")
FLOWloc dat <-- returned value
If (DATA-REQUEST-TO-BE-SENT) then
Call SEND-DATA-REQUEST
If (success) then
OTHERtyp <-- "data request"
One reason'that a Data Request message may be sent is that the
inactivity timer has expired (Section 7.4). If this is the case, the
inactivity timer is restarted.

I f (TIMERinact expired) then
TIMERinact < - - TIME + NSPinact tim
Endif
Call OTHER-DATA-SENT
Else
Call REALLOCATE
Endif
Else
Call SEND-DATA-ACX
If (success) then
Call DATA-ACK-SENT
Else
Call REALLOCATE
Endif
Endif
Else
Call SEND-DATA-ACK

If (success) then
Call DATA-ACX-SENT
Else
Call REALLOCATE
Endif
Endi f
Endif
Endif
Endif
Endloop
The following routines are used by these processes.

Detailed Functional Model

Page 98

COUNTretrans <-- COUNTretrans + 1
If (COUNTretrans > NSPretrans) then CONFIDENCE < - - false
If (COUNTretrans > ~ S ~ t r y h a r dthen
)
TRYHARD < - - true
MESSAGE-TO-BE-SENT:
I f (INTERRUPT-TO-BE-SENT) then return true
Elseif (INT-REQUEST-TO-BE-SENT) then return true
Elseif (DATA-REQUEST-TO-BE-SENT) then return true
Elseif (DATA-TO-BE-SENT) then return true
Elseif (OTHER-DATA-ACK-TO-BE-SENT) then return true
Elseif (DATA-ACK-TO-BE-SENT) then return true
Else
return false
Endif
INTERRUPT-TO-BE-SENT:
To send an interrupt message, either:
(1)

Interrupt data must be available in BUFxmt (FLAGint-avail
true),
The remote NSP must have requested the interrupt data
(FLOWrem int > O ) , and
There must be no outstanding, unacknowledged Interrupt, Data
Request, or Interrupt Request message (OTHERstate = "ready").

(2)

(3)

or
(1)
(2)

There must be an outstanding, unacknowledged
Interrupt
message (OTHERtyp = "interrupt"), and
The message must have timed out (OTHERstate = timeo out"^.

I f (FLAGint avail true and FLOWrem int > 0
and 0 T ~ ~ ~ s t a= t"ready")
e
then
return true
Elseif (OTHERstate = "timeout"

and OTHERtyp = "interrupt") then
return true
Else
return false
Endif
INT-REQUEST-TO-BE-SENT:
To send an Interrupt Request message, either:
(1)
(2)

The buffer BUFrcv must be empty and an Interrupt Request
message not previously sent (FLOWloc- int = "send request");
and
There must be no outstanding, unacknowledged Interrupt, Data
Request, or Interrupt Request message (OTHERstate = "ready"),

Detailed Functional Model

Page 100

message to be sent is always one that is unacknowledged since the
variable NUMdat is always greater than ACKrcv dat, although there will
be no data to send if NUMdat = ACKrcv-dat + 1 = NUMhigh + 1.
The remaining tests depend on the type of flow control that
selected by -the remote NSP when the logical link was established.

was

If (FLOwrem-typ = "none") then
return true
The two tests below are analogous. Each is testing to see if the
number of requested elements (segments or Session Control messages) is
greater than or equal to the number of elements in the range from the
highest acknowledged (ACKrcv-dat) to the one whose transmission is
being attempted (NU~dat).
Elseif (FLOWrern typ = "segment"
and ~ f i d a t<= ACKrcv -dat + FLOWrem-dat) then
return true
Elseif (FLOWrem typ = "session-control-message"
and N M ~ A C K ~ -Cdat
V + 1,NUMdat) < = FLOWrem-dat) then
return true
Else
return false
Endif
Else
return false
End i f
DATA-ACK-TO-BE-SENT:
return FLAGdat-ack
OTHER-DATA-SENT:
Call OTHER-ACK-SENT
OTHERstate < - - "sent"
TIMERoth < - - TIME + (NODEdelay * NSPdelay)
OTHER-ACK-SENT:
Call MESSAGE-SENT
FLAGoth-ack <-- false
DATA-ACK-SENT:
Call MESSAGE-SENT
FLAGdat-ack <-- false
MESSAGE-SENT:
This routine ascertains if there is more data to be sent. I f so, it
calls REALLOCATE to remain in contention for transmit resources but to
free those resources for other ports. If not, it calls DEALLOCATE to
free the resources and remove itself from contention. In the latter

Detailed Functional Model

Page 101

case, it sets FLAGdat alloc false so that an ALLOCATE request will
made when there is data to send.

I f (MESSAGE-TO-BE-SENT) then
Call REALLOCATE
Else
Call DEALLOCATE
FLAGdat-alloc < - - false
Endif

6.6.3 Reserved Transmit Processes - The reserved transmit processes
send No Resources and No-Link messages.
There is one reserved
transmit process for each reserved port.

Loop
The processing here is somewhat complicated due to the interaction
with the transmit allocation module and the fact that a transmit
request to Routing may fail. It is not modeled analogously to the
connect/disconnect and data transmit processes because the need to
transmit a given message will not disappear as with the other
processes.
If ( ~ S ~ t y< p> "none") then
Call ALLOCATE
Loop
Call CHECK-ALLOCATE
I f (success) then
I f (MSGtyp = "no resources") then
Call SEND-NO-RESOURCES
Elseif ( ~ S G t y p= "no-link") then
Call SEND-NO-LINK
Endi f
I f (success)

MSGtyp <-- "none"
Call DEALLOCATE
Exit loop
Else
Call REALLOCATE
Endif
Endif
Endloop
Endi f
Endloop

Detailed Functional Model
6.7

Page 102

Transmit Format Module

This module manages the large and small transmit buffer pools, formats
outgoing NSP messages, and sends messages to Routing. In addition,
although it is not explicitly modeled, this module polls Routing to
get back buffers that have been transmitted. When such a buffer is
returned, it is immediately placed back in its pool.
The name of each routine in this module describes its function.
call supplies the appropriate port id.
SEND-CONNECT-INITIATE (port id):
I f (a large transmit buffer is available) then
allocate large transmit buffer
If (COUNTretrans = 0 ) the MSGFLG <-- "connect initiate"
Else
MSGFLG = "retransmit connect initiate"
Endif
SRCADDR <-- ADDR~oc
SERVICES <-- "segment"
INFO <-- "version 4.0''
SEGSIZE <-- NSPbuf
DATA-CTL <-- data addressed by BUFcon
Call ROUTING-TRANSMIT with "return to sender" and circuit =
CIRCUIT,
nexthop = NEXTHOP
If (success) then
return success
Else
release large transmit buffer
return failure
Endif
Else
return failure
Endi f
SEND-CONNECT-ACKNOWLEDGMENT (port id) :
I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "connect acknowledgment"
DSTADDR <-- ADDRrem
Call SEND-SMALL-MESSAGE
Else
return failure
Endif

Each

Detailed Functional Model
SEND-NO-RESOURCES (port id):

I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "disconnect confirm"
DSTADDR <-- ADDRrem
SRCADDR < - - 0
REASON <-- 1
Call SEND-SMALL-MESSAGE
Else
return failure
Endif
SEND-CONNECT-CONFIRM (port id):

I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG < - - "cc'nnect confirm"
DSTADDR < - - ADDRrem
SRCADDR < - - A D D R ~ o c
SERVICES < - - "segment"
INFO <-- "version 4.0"
SEGSIZE < - - NSPbuf
DATA-CTL <-- SUFxmt
Call SEND-SMALL-MESSAGE
Else
return failure
Endif
SEND-DISCONNECT-INITIATE (port id):

I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG < - - "disconnect initiate''
DSTADDR < - - ADDRrem
SRCADDR < - - ADDRloc
REASON <-- first two bytes of BUFxmt
DATA-CTL < - - remaining bytes of BUFxmt
Call SEND-SMALL-MESSAGE
Else
return failure
Endif
SEND-DISCONNECT-COMPLETE (port id):
I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "disconnect confirm"
DSTADDR < - - ADDRrem
SRCADDR <-- ADDRloc
42
REASON < - Call SEND-SMALL-MESSAGE
Else
return failure
End i f

Page 103

Page 104

~etailedFunctional Model
SEND-NO-LINK (port id):
I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "disconnect confirm"
DSTADDR< - - ADDRrem
SRCADDR <-- ADDRtmp
41
REASON <-Call SEND-SMALL-MESSAGE
Else
return failure
Endif

SEND-DATA-ACK (port id):
I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "data acknowledgment"
DSTADDR <-- ADDRrem
SRCADDR < - - A D D R ~ o c
NUMBER <-- ACKxmt-dat
QUAL < - - "ack"
Call SEND-SMALL-MESSAGE
Else
return failure
2ndif
,

SEND-OTHER-DATA-ACK (port id) :

(a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "other data acknowledgment"
DSTADDR < - - ADDRrem
SRCADDR <-- ADDRloc
NUMBER < - - ACKxmt -0th
QUAL <-- "ack"
Call SEND-SMALL-MESSAGE
Else
return failure
Endif

Detailed Functional Model
SEND-DATA-SEGMENT (port id, buffer descriptor, eom, born):
a large transmit buffer is available) then
allocate large transmit buffer
MSGFLG <-- "data," eom, born
DSTADDR <-- ADDRrem
SRCADDR <-- ADDRloc
NUMBER < - - ACKxmt -dat
QUAL <-- "ack"
NUMBER <-- ACKxmt 0th
QUAL <-- "cross sub-channel ack"
SEGNUM < - - NUMdat
DATA <-- data from buffer descriptor
Call ROUTING-TRANSMIT with circuit = CIRCUIT
nexthop = NEXTHOP and tryhard = TRYHARD
If (success) then
return success
Else
release large transmit buffer
return failure
Endif
Else
return failure
End i f
SEND-INTERRUPT (port id):
I f (a small transmit buffer is available) then

allocate small transmit buffer
MSGFLG < - - "interrupt"
DSTADDR < - - ADDRrem
SRCADDR < - - ADDRloc
NUMBER < - - ACKxmt-0th
QUAL <-- "ack"
SEGNUM < - - NUMoth
DATA <-- BUFxmt
Call SEND-SMALL-MESSAGE
Else
return failure
Endif

Page 105

Detailed Functional Model

Page 106

SEND-DATA-REQUEST (port id):
I f (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "data request"
DSTADDR <-- ADDRrem
SRCADDR <-- ADDR~oc
NUMBER <-- ACKxmt-0th
QUAL a-- "ack"
NUMBER <-- ACKxmt dat
QUAL <-- "cross sub-channel ack"
SEGNUM <-- NUMoth
FC MOD <-- "send"
FCVAL INT <-- "data"
FCVAL <-- FLOWloc dat
Call SEND-SMALL-MESSAGE
Else
return failure
End i f

SEND-INTERRUPT-REQUEST (port id) :
If (a small transmit buffer is available) then
allocate small transmit buffer
MSGFLG <-- "interrupt request"
DSTADDR <-- ADDRrem
SRCADDR <-- ADDRloc
NUMBER <-- ACKxmt-0th
QUAL <-- "ack"
SEGNUM <-- NUMoth
FC MOD <-- "send"
FCVAL INT <-- "interrupt"
FCVAL <-- 1
Call SEND-SMALL-MESSAGE
Else
return failure
Endif
The following routine is used by the above routines.
SEND-SMALL-MESSAGE:
Call ROUTING-TRANSMIT with circuit = CIRCUIT, nexthop = NEXTHOP
and tryhard = TRYHARD
If (success) then
return success
Else
release small transmit buffer
return failure
Endif

Page 107

Detailed Functional Model
6.8

Segmentation Module

The segmentation module maps data from Session Control transmiz
buffers into Data Segment messages according to the rules implied by
the Session Control interface specification.
The module makes the
data available to the data transmit processes. Because of this, the
interface routines pass the DATA-XMT and XMT-POLL calls to the module.
The detailed specification of this module is beyond the scope of
specification (Appendix B).

this

A data transmit process obtains a buffer descriptor for a segment of a
session control message from this module by issuing the following
call:
GET-SEGMENT (port id, number;

return)

number:

the number of the desired segment

returns:

a buffer descriptor for the segment, an end-of-message
indication, and a beginning-of-message indication

A data transmit process informs this module that it will no longer
require a segment or sequence of segments by issuing the following
call.
ACK-SESSION-CONTROL (port id, number)
number:

a segment number; no segment with this or a lower
number will be required again by the data tran.sr"iit
process.

A data transmit process obtains the number of Session Control data
segments marked as "end-of-message" in a given range of segment
numbers by executing the following function:
W. (port id, i , j ;
-

return)

a segment number

j :

a segment number

returns:

the returned number of end-of-message segments in the
range of segments from number i to number j, inclusive
i f i<=j
0 in all other cases

A data transmit process obtains information on the amount of transmit
data available from the session control by executing the following
function:

Page 108

Detailed Functional Model
LAST (port id;
return:

6.9

return)
the highest segment number that could be assigned to
data available for transmission from Session Control

Transmit Allocation Module

Each transmit process must call this module to obtain permission to
transmit a message.
This module guarantees the fair use of Routing
resources across all logical Links. The algorithms executed by this
module are system-dependent and are, therefore, beyond the scope of.
this specification (Appendix Dl. The argument "port id" is a port
identifier.
A transmit process requests permission
following call:

transmit

issuing

the

A transmit process checks to see i f it has permission to
executing the following Boolean function:

transmit

The transmit allocation module cannot give permission to
more than one transmit process at a time.

transmit

A transmit process indicates that it no longer needs
issuing the following call:

transmit

ALLOCATE p o r t

CHECK-ALLOCATE (port id!
returns:

true if a message may be sent
false if a message may not be sent

DEALLOCATE (port id)
After obtaining permission to transmit, a transmit process must issue
this call or the next call before permission to transmit can be given
to another transmit process.
A transmit process indicates that it has used its permission to
attempt a transmit, but that it also has more data to send by issuing
the following call:
REALLOCATE (port id)

Page 109

Algorithms
7.0

ALGORITHMS

This section contains an overview of some algorithms collectively
executed by several NSP components. These algorithms are explicitly
defined in Section 6 in the model description.
The explanation in
this section is added as an aid to understanding.

7.1

Data Segment Retransmission

The data retransmission algorithm described in Section 6.6 in several
of the modules operates as follows. There is only one timer for each
port. When a Data Segment is transmitted (or retransmitted), start
the timer if the segment being sent is the "oldest" segment. That is,
the segment number is one greater than
the
highest
segment
acknowledged from the remote receiver. Also, restart the timer upon
receipt of a data acknowledgment that acknowledges data segments that
have not previously been acknowledged but that does not acknowledge
all outstanding data segments.
Stop the timer upon receipt of
acknowledgment of all outstanding segments.
When a data transmit process detects that a timer has expired, that
process sets the number of the next Data Segment that can be
transmitted to one greater than the value of the highest segment that
has
been
acknowledged from the remote receiver.
This causes
retransmission if the flow control variables allow retransmission. It
will .not necessarily cause a retransmission, however, because there
may have been a change to the flow control variables.
An implementation of NSP may elect to provide an algorithm different
from
the
one described above.
An algorithm that times each
outstanding Data Segment separately would provide a higher level of
service (in terms of average delay seen by end users) at a cost of
more data base storage for NSP.

7.2

Other-Data Handling

Handle other-data subchannel transmission as follows.
No more than
one other-data message is outstanding at a time for a given port. The
variable OTHERstate contains the state of the port with respect to an
other-data message. It may have the following states:
State

Meaning

'ready"

No other-data
acknowledged.

Sent"

An other-data message has been sent,
acknowledged, and is being timed.

"t imeout"

An other-data message has been
acknowledged, and has timed out.

message

has

been

sent

but

not

has

not

been

sent, has

not

been

Algorithms

Page 110

When the port is in a state other than "ready," the variable OTHERtyp
contains the other-data message type that has been transmitted, and
the variable NUMoth contains its number.
Other-data subchannel receiving is handled as follows. The receipt of
either a Data Request message or an Interrupt Request message causes
an update of the corresponding request count variable in the port
FLOWrem dat and FLOWrem int, respectively).
The receipt of an
Interrupt message causes the placement of interrupt data in BUFrcv.
Since this implementation model can buffer only one received Interrupt
message at a time, handle flow control for Interrupt data as follows.
There is an interrupt flow control state machine conceptually attached
to BUFrcv.
This machine has three states. The current state of the
machine is contained in variable FLOWloc- int. The states are:
State

Meaning

"empty"

BUFrcv is empty, and an Interrupt Request message has
been sent or the logical link has just entered the RL'N
state (in which there is an implied request for one
Interrupt messa'ged .

interrupt"

BUFrcv contains the data from an Interrupt message, and
session control has not yet issued an INTERRUPT-RCV
call to get the data.

"send request" BUFrcv is empty, and an Interrupt Request message
should be sent to- request an additional Interrupt
message.
Because of this model for interrupt flow control, an Interrupt Request
message cannot be sent for the first time unless FLOWloc- int = "send
request" and OTHERstate = "ready."
An implementation of W may elect to use a different algorithm for
other-data error and flow control from the ones described. An
implementation could time each
outstanding
Other-Data
message
separately. This would provide a higher level of service (in terms of
average delay seen by end users) at a cost of more data base storage
An implementation could buffer more than one Interrupt
for NS?.
messaqe concurrently.
The only restriction in the operation of
interrupt flow control is that, unlike normal data flow control, an
Interrupt Request messaqe cannot be sent unless space is guaranteed
for receipt of the interrupt data requested.

7.3

Retransmission -Timer Value Estimation

must compute the appropriate value for the time within which to
retransmit certain messages. If the value is too great, end users may
detect unusually long delays, since outing may drop packets. 1f the
outing
v a l u e is too small, N S P may make very inefficient use of the
bandwidth.

NSP

Algorithms

Page 111

NSP attempts to maintain an estimate of the current round trip delay
to each remote node with which it is communicating.
Variable
NODEdelay in a node descriptor contains this value. The estimate is
updated each time an observation of round trip delay is made. An
observation can be made whenever NSP receives a message in response to
a previously transmitted message.
Wh<--:-leverNSP sends a Connect
Initiate, Connect Confirm, or Disconnect Initiate message, it saves
the current time of day in variable DELAYstr tim. Whenever NSP
receives a Connect Acknowledgment, Connect
confirm,
Disconnect
Complete message, or any message acknowledging a Connect Confirm, NSP
observes the round trip delay to be the current time minus the value
in DELAYstr-tim.
In addition, sample round trip delays are observed by timing selected,
transmitted Data Segment messages.
To conserve space, use only a
single timer per port. An implementation may choose to operate with
multiple
timers.
Such operation would tend to produce better
estimates at a cost of more data base storage.
Observe the Data Segment timing by starting the timer (provided it is
not already running) when a Data Segment message needs to be
transmitted the first time and by stopping the timer when an (explicit
or implicit) acknowledgment is received for the message. Do not
restart the timer i f the Data Segment is retransmitted, since the
algorithm is attempting to estimate the average delay from first need
to transmit to eventual acknowledgment. Once an observed round trip
sample is taken as described above, average the value with the current
estimate by means of a weighting factor. The formula for this is:
NODEdelay =

NSPweight * NODEdelay + deltaT
NSPweiqht + 1

where: NSPweight
NODEdelay
deltaT

=
=

the weighting factor
the estimated round trip time
the sample round trip time

Mote that i f NSPweight is equal to a power of 2
computation can be performed easily.

minus

then

this

The time that NSP uses to determine when to retransmit a message is a
constant times the estimated round trip delay time. This constant is
the "delay factor" and is contained in variable NSPdelay in Table 3.
The delay factor and the weighting factor are NSP parameters.
NSPweight is an integer in the range 0 to 255, inclusive. NSPdelay is
a value in sixteenths of a unit in the range 0 to 15 and 15/16,
inclusive.

Algorithms
7.4

Page 112

Inactivity Timing

I f two NSPs cannot communicate with each other for a sufficiently long
time (for example, because the network is disconnected), the following
problem results. An end u:er that is either not using a logical link
or is passively waiting to receive would not necessarily know that it
is uselessly consuming resources by maintaining the logical link.
Therefore, NSP contains an algorithm to exercise the logical link when
there is no received traffic (either data or NSP control messages)
from the remote NSP for each logical link.
The inactivity timing algorithm operates as follows.
Start an
inactivity" timer when a logical link enters the RUNNING state.
Restart the timer whenever a message is received for the logical link.
I f the timer expires, NSP attempts to send a Data Request message that
If
does not change the remote N S P t s flow control variables.
communications
are
not possible to the remote NSP, then the
retransmission algorithm causes NS? to periodically retransmit the
Data Request message.
Retransmission can result in a change to the
CONFIDENCE variable as described below.

7.5

Confidence Testing

A given NSP module cannot know whether or not a network path exists
between it a n d a given second NSP module, even if the two modules have
communicated in the past.
Therefore, NSP cannot give a "network
disconnection" signal to Session Control when the physical network
supporting a logical link fails.
To provide some useful information to Session Control, NSP maintains a
counter in variable COUNTretrans in a port. Each time a message
timeout occurs (for a Connect Confirm, Disconnect Initiate, Data
Segment, Link Service, or Interrupt message) NSP increments this
variable and compares it to a
global
"retransmit
threshold"
I f COUNTretrans is greater, then NSP sets variable
NSPretrans).
CONFIDENCE false.
Whenever NSP receives an acknowledgment of a
previously unacknowledged message, NSP sets CONFIDENCE to true and
COUNTretrans to zero. NSP returns the CONFIDENCE variable to Session
Control on a CONFIDENCE call.
When communicating with a Version 3.1 neighbor, an implementation of
this specification may set CONFIDENCE false immediately upon detection
of a failure of the physical link to the neighbor.

Page 113

Message Formats
8.0

MESSAGE FORMATS

This section specifies the formats for NSP messages.

Message Format Notation
The following notation is used
herein:
FIELD (LENGTH) :

describe

the

messages

contained

CODING = description of fi.eld

where:
FIELD

Is the name of the field being described

LENGTH

Is the length of the field as:
1.

A number meaning number of 8-bit bytes (octets)

A number followed by a "B1'meaning number of bits

The letters "EX-n" means extensible field. n is a
number that specifies the maximum length of 8-bit
bytes in the protocol before interpretation, as
described below.
I f no number is specified, the
current maximum length is 1 byte.
Extensible
fields are variable in length consisting of 8-bit
bytes. The high-order bit of each byte indicates
whether the next byte is part of the same field. A
1 means the next byte is part of this field.
A
0
indicates the next byte is the last byte. The
low-order 7-bits of each byte are information bits.
Extensible fields can be binary or bit map. I f
they are binary, then 7-bits from each byte are
concatenated into a single binary field. If they
are bit map, then 7-bits from each byte are used
independently or in groups as information bits.
NOTE

The
bit
definitions
define
information
bits after removing
extension bits and
compressing
bytes.
4.

the
the
the

The letters "I-n" means this is an image field.
n
is a number specifying the maximum length of 8-bit
bytes in the image. A 1-byte count of the length
of the remainder of the field precedes the image.
Image fields are variable in length and may be null
=
0).
All 8-bits of each byte are
(count

Message Formats

Page 114
information bits. The meaning and interpretation
of each image field is defined with that specific
field.

COD I NG

Is the representation type used as follows:
A
B
BM

7-bit ASCII
Binary
Bit map (each bit or group
independent meaning)
C
Constant
null Interpretation data dependent

bits

has

NOTES
1.

If both the length and coding are omitted, the
field represents a generic field with a number of
subfields specified in the description.

Any bit or field specified as
zero unless otherwise noted.

"reserved" must

All numeric values in this
unless otherwise noted.

section

Bits are numbered with bit 0 on
the
right
(low-order, least-significant bit) and bit 7 on the
left (high-order, most-significant
bit).
For
convenience, when the graphic form of a 2-byte
field is given, it will be shown converted to a
16-bit word.
When a subfield of a message field
contains more than one bit, it should be considered
a binary value.

Unless otherwise specified, the numbers that appear
at the top of the message formats represent bit
positions.

Bracketed fields are optional.

are

decimal

Page 115

Message Formats
8.2

General Message Format

In general, NSP messages have the following format:

MSGFLG (EX) : BM

Is a group of fields describing the characteristics of the message. -The MSGFLG format is:

SUBTYPE (3B) : B

I
1
1
I
I
1
1

1
I
1

Is the message subtype - used to
modify TYPE field.

1
1
I
I
1
I
1
I

1 0
1
1
I 2
1 3
1 4
1 5

I
1

1 7

I 6
I

No Operation (included for
compatibility with NSP 3.1)
Connect Initiate
Connect Confirm
Disconnect Initiatl
Disconnect Confirm
reserved (Phase I 1 node
init)
Retransmitted Connect
Initiate
reserved

+------+---------+---------------------------------+

I
I

1
I

1
1
I
1

I
I

Page 116

Message Formats
TYPE ( 2 B ) :

Is the message type (binary!
0
1
2
3

data message
acknowledgment message
control message
reserved

Is the remainder of an

MSGDATA

NSP

3-5).

8.3

Data Messages

There are three types of data messages:
1.

Data Segment messages (Section 8.3.1)

Interrupt messages (Section 8.3.2)

Link Service messages (Section 8.3.3)

message

(Section 8 -

Message Formats
8.3.1
form:

Page 117

Data Segment Message - A Data Segment message has the following

MSGFLG ( E X ) : BM

Represents the message identifier.
this field is:

The format

where:
EOM (1B) : BM

Is the end-of-message indicator
0
1

BOM (1B) : BM

not-end-of-message
end-of-message

Is the beginning-of-message
indicator
0
1

not-beginning-of-message
beginning-of-message

DSTADDR (2) : B

Is the logical link destination address.

SRCADDR (2) : B

Is the logical link source address.

ACKNUM (2) : BM

Is the number of the last NSP Data Segment message
successfully
received
and
a
positive
acknowledgment (ACK) or a negative acknowledgment
(NAK).
This field is optional. Its presence is
indicated by bit 15 being set.
The format for
this field is as follows:

where:
QUAL ( 3 ~ ): B

Is an acknowledgment qualifier.
0
ACK
1
NAK
2-7 reserved

Page 118

Message Formats
NUMBER (12B) : B
ACKOTH (2) : BM

Is the number of the message
being acknowledged.

Is the number of the last NSP Other Data message
successfully
received
and
a
positive
acknowledgment (ACK) or a negative acknowledgment
(NAK).
This field is optional. Its presence is
indicated by bit 15 being set.
The format for
this field is as follows:

where:
QUAL (3B) : B

Is an acknowledgment qualifier.
0,l reserved
2
cross sub-channel ACK
3
cross sub-channel NAK
4-7 reserved

NUMBER (12B) : B

Is the number of the message
being acknowledged.

SEGNUM (2) : BM

Is the number of this Data Segment
format for this field is:

DATA

Is the data to be sent over a logical link.

message.

The

This
field is transparent and may use all 8-bits of
each byte.
The length of the data field is
ascertained from the total length of the Data
Segment message and consists of all bytes in the
message after the SEGNUM field.

Message Formats

Page 119

8.3.2
form:

Interrupt Message - The Interrupt

MSGFLG

(EX)

: BM

message

Is the message identifier.
field is:

has

The

the

following

format

this

DSTADDR ( 2 ) : B

Is the logical link destination address.

SRCADDR (2) : B

Is the logical link source address.

ACKNUM (2) : BM

Is the number of the last NSP Interrupt or Link
Service
message
successfully received and a
positive acknowledgment (ACK) or
a
negative
acknowledgment (NAK).
This field is optional.
Its presence is indicated by bit 15 being set.
The format for this field is as follows:

where:
QUAL ( 3 ~ ): B

Is an acknowledgment qualifier.
0

ACK

1
NAK
2 - 7 reserved

NUMBER (12B) : B
ACKDAT (2) : BM

Is the number of the
being acknowledged.

message

Is the number of the last NSP Data Segment message
successfully
received
and
a
positive
acknowledgment (ACK) or a negative acknowledgment
(NAK).
This field is optional. Its presence is
The format for
indicated by bit 15 being set.
this field is as follows:

Message Formats

Page 120

where:
Is an acknowledgment qualifier.

QUAL ( 3 B ) : B

.
NUMBER ( 1 2 B ) : B

0,l reserved
2
cross sub-channel ACK
3
cross sub-channel NAK
4-7 reserved
Is the number of the
being acknowledged.

message

SEGNUM (2) : BM

Is the number of this Interrupt
format for this field is:

message.

The

DATA

Is the interrupt data. This field is transparent
and may use all 8-bits of each byte. The length
of the data field is ascertained from the total
length of the Interrupt message and consists of
all bytes in the message after the SEGNUM field.
Interrupt data may be no longer than 16 bytes.

Message Formats
8.3.3 Link Service
following form:

Page 121
Messaqe - The

Link

Service

message

has

the

this

MSGFLG (EX) : BM

Is the message identifier.
field is:

DSTADDR ( 2 ) : B

Is the logical link destination address.

SRCADDR ( 2 ) : B

Is the logical Link source address.

ACKNUM ( 2 ) : BM

Is the number of the last NSP Interrupt or Link
Service
message
successfully received and a
positive acknowledgment (ACK) or
a
negative
This field is optional.
acknowledgment (NAK).
Its presence is indicated by bit 15 being set.
The format for this field is as follows:

The

format

where:
QUAL ( 3 B ) : B

Is an acknowledgment qualifier.
0

NUMBER (12B) : B

ACKDAT ( 2 ) : BM

ACK
NAK

2-7

reserved

Is the number of the
being acknowledged.

message

Is the number of the last NSP Data Segment message
successfully
received
and
a
posit ive
acknowledgment ( A C K ) or a negative acknowledgment
(NAK).
This field is optional. Its presence is
The format for
indicated by bit 15 being set.
this field is as follows:

Page 122

Message Formats

where:
QUAL ( 3 B ) : B

Is an acknowledgment qualifier.
0,1 reserved
2
cross sub-channel ACK
3
cross sub-channel NAK
4-7 reserved

NUMBER ( 1 2 ~ ): B

Is the number of this Link Service
format for this field is:

SEGNUM ( 2 ) : BM

LSFLAGS (EQ) :

Is the number of the
being acknowledged.

Is the Link Service flags.
field is as follows:

The

message

message.

format

The

for

this

Is the
interpretation
FCVAL field

where:
FCVAL INT ( 2 B ) : B

data segment or message
request count
1
interrupt request count
2-3 reserved

FC MOD ( 2 ~ ): B

Is
the
flow
control
modification. I f FCVAL INT =
0, then this field has the
following contents.
0
1
2
3

nochange
do not send data

send d a t a
reserved

Page 123

Message Formats

If FCVAL INT = 1, then this
field is 0 on transmit and
ignored on receive.
FCVAL (1) :

Is the number of Session Control messages, Data
Segment messages, or Interrupt messages that the
sender of the message can receive in addition to
those previously requested by a Link Services
message. This number is added to the request
count which is maintained by NSP, to determine how
many Session Control messages,
Data
Segment
messages,
or
Interrupt
messages
will
be
transmitted via a logical link.
NOTES
INT = 0, the message is a Data Request message.

I f FCVAL INT
message.

The transmit request count for segment flow control may be
negative.
(Negative values are presented in 2's complement
form in the FCVAL field.)

If FCVAL is for Session Control message or Interrupt message
flow control, the count must be positive. Us? 0 if there is
to be no change in the count.

the

message

Interrupt

Request

Page 124

Message Formats
8.4

Acknowledgment Types

There are three types of acknowledgment messages:
1.

Data Acknowledgment message (Section 8.4.1)

Other-Data Acknowledgment messages (Section 8.4.2)

Connect Acknowledgment messages (Section 8.4.3)

8.4.1 Data Acknowledgment Message - The Data
has the following form:

~cknowledgment message

MSGFLG (EX) :

Is the message identifier.
field is:

The

format

this

DSTADDR (2) :

Is the logical link destination address.

SRCADDR (2) :

Is the logical link source address.

ACKNUM (2) :

Is the number of the last NSP Data Segment message
successfully
received
and
a
positive
acknowledgment ( A C K ) o r a negative

acknowledgment

This field is required.
this field is as follows:

The format for

(NAK).

where:
QUAL ( 3 B )

Is an acknowledgment qualifier.
ACK
NAK
2-7 reserved

0
1

Message Formats

Page 125
NUMBER ( 1 2 ~ ):

ACKOTH (2) : BM

B Is the

number of the
being acknowledged.

message

Is the number of the last N S P Other Data message
successfully
received
positive
and
a
acknowledgment (ACK) or a negative acknowledgment
NAK).
This field is optional. Its presence is
indicated by bit 15 being set.
The format for
this field is as follows:

where:
QUAL (3B) : B

Is an acknowledgment qualifier.

0,l reserved
2
cross sub-channel ACK
3
cross sub-channel NAK
4-7 reserved
NUMBER (12B) : B

Is the number of the message
being acknowledged.

Message Formats

Page 126

8.4.2 Other-Data
Acknowledgment
Acknowledgment
message
acknowledges
messages. It has the following form:

Message - The
Interrupt and

Other-Data
Link Service

MSGFLG ( E X ) :

Is the message identifier.
field is:

DSTADDR (2) :

Is the logical link destination address.

SRCADDR (2) :

Is the logical link source address.

ACKNUM (2) :

Is the number of the last NSP Interrupt or Link
Service
message
successfully received and a
positive acknowledgment (ACK) or
a
negative
This field is required.
acknowledgment (NAK).
The format for this field is as follows:

The

format

this

where:
QUAL (3B) :

Is an acknowledgment qualifier.
0
ACK
NAK
1
2-7 reserved

NUMBER (12B) :
ACKDAT ( 2 ) : BM

B Is the number of the
being acknowledged.

message

Is the number of the last NSP Data Segment message
successfully
received
and
a
positive
acknowledgment (ACK) or a negative acknowledgment
(NAK).
This field is optional. Its presence is
The format for
indicated by bit 15 being set.
this field is as follows:

Message Formats

Page 127

where:.
QUAL ( 3 ~ ): B

Is an acknowledgment qualifier.

0,l reserved
2
cross sub-channel ACK
3
cross sub-channel NAK
4-7 reserved
NUMBER ( 1 2 B ) : B

Is the number of the
being acknowledged.

8.4.3 Connect Acknowledgment Message - The
message has the following form:

Connect

The

message

Acknowledgment

MSGFLG ( E X ) :

Is the message identifier.
field is:

format

DSTADDR ( 2 ) :

Is the logical link destination address.

this

Page 128

Message Formats
8.5

Control Messages

There are five types of control messages:
1.

No Operation messiges (Section 8.5.1)

Connect Initiate messages (Section 8.5.2)

Connect Confirm message (Section 8.5.3)

Disconnect Initiate messages (Section 8.5.4)

Disconnect Confirm messages (Section 8.5.5)

8.5.1

No Operation Message -

where:
MSGFLG (EX) :

TSTDATA

Is the message identifier.
field is:

Is any data.

The

format

this

Message Formats

Page 129

8.5.2 Connect Initiate And
- Retransmitted Connect Initiate Messages The Connect Initiate and the Retransmitted Connect Initiate messages
have the following form:

where:
MSGFLG (EX) :

Is the Connect Initiate message
format of this field is:

MSGFLG ( E X ) :

Is the Retransmitted Connect Initiate
identifier. The format of this field is:

DSTADDR ( 2 ) :

Is the destination logical link address.
This
address will be 0 to allow the receiving NSP to
assign a number dynamically.

SRCADDR ( 2 ) :

Is the source logical link address.
his number
is assigned by the sending NSP and will be used by
the destination to address all messages for this
logical link. The value 0 is illegal.

SERVICES ( E X ) :

BM The requested services.
is as follows:

where:

identifier.

message

The format for this field

Page 130

Message Formats
FCOPT ( 2 B ) :

Are the flow control options.
0
1
2

3
INFO (EX) :

Is the information.
as follows:

none
segment request count
Session Control message
request count
reserved
The format for this field

where:
VER ( 2 B ) :

Is the NSP version.
0
1

2
3
SEGSIZE ( 2 ) :

DATA-CTL

version3.2
version3.1
version 4.0
reserved

Is the maximum size (in bytes) of the data in a
Data Segment that can be received on this logical
link.
Is the Connect Initiate data field. The length of
this field is ascertained from the total length of
the Connect Initiate message and consists of a:'
bytes in the message after the SEGSIZE field.

Message Formats

Page 131

8.5.3 Connect Confirm Message - The Connect Confirm message
following form:

has

the

this

where:
MSGFLG (EX) :

Is the message identifier.
field is:

DSTADDR (2) :

Is the destination logical link address.
This
will not be 0.
It is the value of the SRCADDR
field from the Connect Initiate message.

SRCADDR (2) :

Is the source logical link address.
This number
is assigned by the sending NSP and will be used to
address all messages for this logical link.
The
value 0 is illegal.

SERVICES (EX) :

BM Are the requested services.
field is as follows:

The

format

The format

for

this

where:
FCOPT (2B) : B

Are the. flow control options.
0
1
2

3
INFO (EX) : BM

Is the information.
as follows:

none
segment request count
Session Control message
request count
reserved
The format for this field

Page 132

Message Formats
where:
VER ( 2 B ) :

Is the SSP version.
0
1
2
3

SEGSIZE ( 2 ) :

version 3.2
version3.1
version4.0
reserved

Is the maximum s i z e ( i n bytes) of the data in a
Data Segment that can be received o n this logical
link.

DATA-CTL (1-16) : B Is user-supplied data.

Message Formats

Page 133

Disconnect Initiate Message - The Disconnect
has the following form:

8.5.4

Initiate

message

format

where:
MSGFLG (EX) :

Is the message identifier.
field is:

The

this

DSTADDR ( 2 ) : B

Is the logical link destination address.

SRCADDR ( 2 ) : B

Is the logical link source address.

REASON ( 2 ) : B

Is the first two
disconnect data.

bytes

Session

Control

DATA-CTL (1-16) : B Is the remaining
disconnect data.

bytes

Session

Control

Message Formats

Page 134

5 . 5 Disconnect Confirm Messaqe - A Disconnect Confirm
the following form:

message

has

where:
MSGFLG (EX) : BM

Is the message identifier.
field is:

The

format

DSTADDR ( 2 ) : B

Is the logical link destination address.

SRCADDR ( 2 ) : B

Is the logical link source address.

REASON ( 2 ) : B

Is the disconnect reason.

this

NOTES
1.

If REASON = 1, the message is a No Resources message.

If REASON = 42, the message is a Disconnect Complete message.

I f REASON = 41, the message is a No Link Terminate message.

APPENDIX A
LOGICAL LINK ADDRESS ASSIGNMENT/DEASSIGNMENT

A logical link address is a 16-bit value. When an NSP module opens a
port, it assigns a logical link address. When an NSP module closes a
port, it deassigns a logical link address. The algorithm that assiq.".~
and deassiqns these addresses is implementation-dependent. There a r e
two requirements for this algorithm:
1.

I t must not assign
concurrently, and

given

16-bit

address

I t must not reassign a given 16-bit address for a long period
following its deassiqnment.

In addition, the algorithm should operate . with a modest
memory,
trading
off the amount of memory for the
reassignment.

two

por:s

amount
period

of
cf

The algorithm described in this appendix is a sample algorithm ^ h a t
meets these requirements. No implementation of NSP is required to '-is3
this algorithm, however.
Any algorithm
that
meets
the
t--3
requirements
stated above is acceptable.
The sample algorithm
restricts the number of outstanding, assigned link addresses.

INTERFACE TO THE ALGORITHM
The sample algorithm is implemented by a module that accepts three
calls:
one to assign a link address, one to deassign a link address,
and one to initialize the module.
The following routine assigns a link address.
GET-ADDRESS
returns:

success - a link address is returned
failure - too many link addresses currently
- assigned

The following routine deassigns a link address.
RELEASE-ADDRESS (address)

Page A - 2

LOGICAL LINK ADDRESS ASSIGMENT/DEASSIGmENT
address:

the link address to be deassigned

returns:

success
failure - Link address was not assigned

The following routine initializes the algorithm module.
INITIALIZE-ADDRESS
NSP calls this routine during NSP initialization. The routine allows
the algorithm module to meet the second rzquirement above even across
NSP initializations.

A.2

DATA STRUCTURES

This algorithm forms link addresses of the following form:
random

part

r bits

index

part

i bits

where:

No two concurrently assigned link
value in the low i bits.

addresses

will

contain

the

same

Furthermore, the algorithm restricts the number of ?ddresses that
be assigned concurrently to open ports to:

can

The data base consists of two vectors and three variables.

These

are

This vector contains 2"i bits. There is one bit for
possible value in the index part of a link address.

each

the following.

Boolean vector INUSE

A bit is set to "true1' if the corresponding index is in use
(i.e., is in the lower i bits of an assigned link address).
The it is set to "false" otherwise.
2.

Vector RANDOM

This vector contains 2"i entries, each r bits wide.
An
element of the vector contains the random part of the last
lirfk address assigned with the index part equal to the index
of this element in the vector.

Page A-3

LOGICAL LINK ADDRESS ASSIGMENT/DEASSIGWENT

Variable NUMBER-ASSIGNED
This variable contains the number of link addresses currently
assigned. I t has a value in the following range:
0 < = NUMBER-ASSIGNED <= zAi-l

When NUMBER-ASSIGNED = 2ni-1, then no more link addresses may
be assigned.

Variable INDEX
This variable contains the index value portion
link address that was assigned.

the

last

Variable TEMP
This variable is used to temporarily hold the index value
portion of a link address that is being deassigned and in
module initialization.

ALGORITHM OPERATION

A.3

This algorithm operation is regresented in the same high-level
language that was used to represent NSP's operation in the body of
this document.
GET-ADDRESS:
(NUMBER-ASSIGNED < ZAi-1) then
NUMBER-ASSIGNZD < - - NUMBER-ASSIGNED + 1
While (INUSE(1NDEX) true) do
INDEX < - - INDEX + 1 (mod 2"i)
Endwhi le
RANDOM(INDEX~ < - - RANDOM (INDEX) + 1 (mod 2"r)
INUSE(1NDEX) < - - true
random part of link address < - - RANDOM(INDEX)
index part of link address < - - INDEX
return success
Zlse
return failure
Endif
If

RELEASE-ADDRESS:
TEMP < - - index part of the link address
I f (INUSE(TEMP1 true
and RANDOM(TEMP1 = random part of link address) then
INUSE(TEMP) <-- false
NUMBER-ASSIGNED <-- NUMBER-ASSIGNED - 1
return success
Else
return failure

LOGICAL LINK ADDRESS ASSIGMENT/DEASSIGWENT
Endi f
INITIALIZE-ADDRESS:
TEMP <-- 0
While (TEMP < Z A i ) do
INuSE(TEMP) < - - false
RANDOM(TEMP) <-- random number (mod 2Ar)
TEMP < - - TEMP + 1
Endwhile
INDEX <-- random number (mod 2 " i )
NUMBER-ASSIGNED <-- 0

Page A - 4

APPENDIX B
SEGMENTATION MODULE EXAMPLE

This appendix models a segmentation module. The model supports
queuing of multiple outstanding transmit requests for each port.

B.1

:he

DATA STRUCTURES

To support this
following items:

model!

each

port

requires

the

aadition

c'ne

from

:he

Port Additions

A request queue head.

The segment number of the last segment
segment queue (initial value = 0)

Boolean flag to indicate if the next segment placed on :he
segment queue will be a beginning-of-message segment (initial
value = true).

segment queue head.
removed

This mode* also requires a pool of queue control blocks to nold
information about queued transmit requests and outstanding segments.
When a transmit request from Session Control is accepted by the
segmentation module! a queue control block is added tc the request
queue for the port. It contains the following information:
Request Queue Control Block
1. Buffer descriptor from the request.
2. Xmtflag from the r-quest.
3. Highest segment number corresponding to the request.
4. Status ("incomplete" or "complete").
When the data from a single transmit request is segmented, each
segment is assigned a queue control block that is added to the segment
queue for the port. Each segment queue control block .contains the
following information:

SEGMENTATION MODULE EXAMPLE

Page B-2

Segment Queue Control Block
1. Buffer descriptor for the seqment.
2. ~nd-of-messag; flag.
3. Beginning-of-message flag.
4. Segment number assigned to the segment.
The queue pointer cells required in these blocks and in the queue head
information in the port are not described but are assumed to allow
'finding the first control block in each queue, the last control
lock
on each queue, and the control block queued after a given control
block.

B.2

OPERATION

DATA-XMT
This routine operates as follows.
1.

There must be enough queue control blocks available f r ~ z z5e
queue control block pool to queue one block to the ?or:'s
request queue and one or more blocks to the ~ o r t ' s seane?:
he total number of blocks required is equal t; the
queue.
length of the transmit buffer divided by SIZEseq (for =he
segment queue) plus one (if there is-a remainder from :he
1f
previous division) plus one (for the request queue).
there aren't enough blocks available from the pool, the
DATA-XMT call is returned as "buffer not queued."

I f the DATA-XMT call is not rejected, add one control block
to the request queue.
Store the buffer descriptor a ~ ~ d
xmtflag values from the call in the block. Set the sratas :o
"incomplete.

Add a control block to the segment queue.
The b ~ f f e r
descriptor for the control block contains the address :ram
the DATA-XMT call and a length equal to the minimum of the
length
from
the
call
and
SIZEseg.
Set
:tie
beginning-of-message
flag
to
true
only
if
the
beginning-of-message flag in the port is true. Set the
segment number to the segment number of the preceding block
on the queue plus one (if there is a preceding block).
Otherwise set the segment number to that contained in the
port descriptor plus one.

Add the remaining control blocks (if any) to the segment
queue.
The buffer descriptor reflects the segmentation of
the transmit buffer into segments.
Each segment except,
perhaps, the last is as long as the previous segment. Assign
each block a segment number equal to that of the preceding
block on the queue plus one. Clear the end-of-message and
beginning-of-message flags of each block, except, perhaps,
the last one. The last block has the end-of-message flag set
only i f the xmtflag value in the DATA-XMT call indicates

SEGMENTATION MODULE EXAMPLE

Page B-3

end-of-message.
5.

Give the request queue control block queued in step 2
segment number of the last block on the segment queue.

the

XMT-POLL

I f the
This routine examines the first block on the request queue.
status is "complete," remove the block from the queue. Return the
block to the pool. Give a "transmit complete" return with the buffer
descriptor from the block. I f the status is not "complete," give a
n o transmit complete" return.
GET-SEGMENT
This routine examines the segment queue to find an entry with a
matching segment number. The buffer descriptor, end-of-message flag,
and beginning-of-message flag are returned.
ACK-SESSION-CCNTROL
This routine c ~ e r a t e sas follows.
Examine the first block on the seqment queue. I f the segment
number from the call is less than the segment number (modulo
4 0 9 6 ) in the block, go t o s t e p 3. Otherwise, go to step 2.
Remove the block from the queue and return the block to the
pool.
Store the segment number from the block in the port.
Go tc step 1.
Examiie the request queue. Mark every entry on the queue
containing a segment number less than (modulo 4 0 9 6 ) or equal
to the segment number from the call "~omplete.'~Make a
return.

This routine identifies the entries on the segment queue from the
entry with a seqment number equal to the first argument in the call up
to the entry equal to the second argument in the call, inclusive.
It
counts the number of these entries that have the end-of-message flag
set and returns this value.
LAST
Return the segment number of the last blc-k on the segment queue, i f
s ~ c h a block exists. Otherwise, return the segment number from the
port.

APPENDIX C
REASSEMBLY MODULE EXAMPLE

This appendix contains a model of a reassembly module.
This model
supports the queuing of multiple outstanding receive requests for each
port. It does not support the use of either cache or commit buffers.

C.1

DATA STRUCTURES

To support this
following items:

model,

each

port

requires

the

addition

the

Port ~ d d i ions
t
o

A request queue head

A variable (~LOWreass)used to contain changes to the
count for the port (initial value = 0 )

A variable (FLOWhigh) to contain the highest segment number
(modulo 4096) stored in a session control receive buffer
(initial value = 0 )

A Boolean variable ( F ~ O ~ d i s c a r d )to indicate i f
segments are to be discarded (initial value = false)

request

received

This model also requires a pool of queue control blocks to hold
information about queued receive requests. When a receive request
from session control is accepted by the reassembly module, a queue
control block is added to the request queue for the port. I t contains
the following information:
Request Queue Control Block
o

Buffer descriptor from the request

Temporary buffer descriptor to handle the
multiple segments into the same receive buffer

Rcvflag from the request

reception

Page C-2

REASSEMBLY MODULE EXAMPLE
o

C.2

Status
("incomplete,"
truncation, "
no
EOM -- truncation").

'EOM -- no
EOM -- no

truncation,
E O M -truncation,"
no

OPERATION

In the following descriptions, the checking for invalid port states is
not described since it is assumed to be clear from the body of the
specification.
DATA-RCV
This routine operates as follows.
If no truncation was specified and the buffer is smaller t h a z
NSPbuf, reject the call.
I f no more queue control blocks
call.

are

available,

reject

the

Otherwise, store the call parameters in a queue control
block.
Set the temporary buffer descriptor equal to the
request buffer descriptor. Add the block to the receive
request queue.
I f rcvflag indicated no truncation, increment FLOWreass by
one. Otherwise, compute the smallest integer greater than or
equal to the length of the receive buffer divided by NSPbuf.
This is how many segments will fit into the buffer. Add the
result to FLOWreass.

RCV-POLL
If
the
state
of
the
port
is
DISCONNECT-NOTIFICATION,
DISCONNECT-COMPLETE, or CLOSE-NOTIFICATION, set the status of all
incomplete" control blocks on the request queue to either "no
EOM -- no truncation" ( i f rcvflag was "no truncation allowed") or "no
EOM -- truncation" (if rcvflag was "truncation allowed").

Examine the first block on the receive queue. I f it has a value other
than "incomplete," remove the block from the queue. Return the block
to the control block pool. Return the request buffer descriptor and
status value to Session Control.
I f the return block has the value "incomplete," givf. a
returned" indication to Session Control.

SPECULATE-NUMBER
Return the contents of FLOWreass and clear FLOWreass.

"no

buffer

REASSEMBLY MODULE EXAMPLE

Page C-3

COMMIT-NUMBER
Return the contents of FLOWhigh.
STORE-SEGMENT
The description of this routine uses a colloquial,
high-level
terms
NUMBER
and
EOM
represent
the
segment
number and
language.
The
end-of-message flags, respectively, passed to this routine by the data
receive process.
I f (NUMBER = FLOWhigh + 1) then
Find the first "incomplete" queued receive request
If (such a request exists) then
FLOWhigh < - - FLOWhigh + 1
If (rcvflag = "no truncation") then
Put received data in front of buffer
Set status using EOM
Else
If (FLOWdiscard) then
If (EOM set) then
FLOWdiscard < - - false
Else
FLOWreass < - - FLOWreass + 1
Endif
Else
Put data (that will fit) in buffer (NOTE 1)
Adjust temporary buffer descriptor' to reflect storage
I f (data fit in buffer) then
If (EOM set) then
Calculate space loss (NOTE 2 )
FLOW reass < - - FLOWreass -- space loss
Set status to "EOM -- no truncation"
Endif
Else
Set status to "EOM -- truncation"
If (EOM not set) then
F'LOWreass < - - FLOWreass + 1
FLOWdiscard < - - true
Endif
Endif
Endi f
Endif
Endif
Endif

NOTES
1.

Use the temporary buffer descriptor.

The space loss is equal to the number of segments that were
requested to fill the buffer, but for which there will be no
receive space due to the impending return of the buffer
partially filled.

APPENDIX D
TRANSMIT ALLOCATION MODULE EXAMPLE

This appendix contains a model of a transmit allocation module.

D.1

DATA STRUCTURES

This model requires a list structure.
Each element in the list
contains a port identifier. This list must be large enough to hold
one element for each port that NSP can handle.

PRIMITIVE FUNCTIONS
This model assumes that the functions described below are available.
List Manipulation Functions
1.

An element can be added to a list.

An element, selected by either index or entry
be removed from the List.

The contents of the first list entry can be read.

contents,

can

Random Number Generation
A random number in a selected range can be obtained.

D.3

OPERATION

The following description of the transmit allocation module
uses a high-level, colloquial language.
ALLOCATE (port id)
Add an element with port id to the list.

operation

TRANSMIT ALLOCATION MODULE EXAMPLE
CHECK-ALLOCATE (port id)
If (port id = contents of first list entry) then
return success
Else
return failure
Endif
DEALLOCATE (port id)
Remove the list entry containing port id
Call REALLOCATE
REALLOCATE (port id)
I f (list not empty) then
Get random index (NOTE)
Swap first and indexed entries
Endif

NOTE
This function obtains a random number in
the range (1, length of list).

Page D-2

APPENDIX E
REVISION HISTORY

This appendix describes the differences from NSP 3.2.1 to NSP 4.0.
1.

Phase I 1 1 and Phase IV NSP do net send NAKs

Several fixes to Section 6 . 4 . 2

The variable "NUMsent" was added to the Session Control Port
to indicate the number of the highest numbered Data Segment
message sent by local NS?.
Changes were made to the
"PROCESS-DATA-ACK" routine and the Data Transmit Process to
accomodate the new variable.

Change the names of the Network Services Layer and Transport
Layer to the End Communications Layer and Routing Layer,
respectively.

Addition of the "tryhard" parameter to the Routing Layer
interface and a procedure for setting the TRYHARD variable in
the Session Control Port data base. This is a local change
only and does not affect the NSP protocol.

and 6 . 8 .

6. Replace the "channel" parameter with "circuit" and
parmaters as required by Routing version 2.0.

"nexthop"

Changes to the connect procedure
to
allow
for
the
retransmission of Connect Initiate messages, with new message
types for retransmitted Connect
Initiate
message,
so
retransmitted
'connects"
will
be
ignored
by
old
implementations. This is an upward compatible change.

Changes to the flow control procedures and message formats to
permit cross sub-channel piggybacking of acknowledgments.
Cross sub-channel acknowledgments are not sent, except when
4.0, so this is an upward
communicating with an NSP Vs.
compatible change.

APPENDIX F
GLOSSARY

confidence
the
probable
An NSP variable (CONFIDENCE) that indicates
connectedness of the physical network supporting a logical link.
data
flow
-The movement of data from a source Session Control to a
destination Session Control.
NSP transforms data from Session
Control transmit buffers to a network form -before sending i t
across a logical link.
NSP retransforms the data at t-he
destination from its network form to its receive buffer form.
Data flows in both directions (full-duplex) on a logical link.
datagram
A unit o f data, inc
to the Rout ing L
When Rou t ing addS 1
a packet

ing NSP control informa

r for tr ansmission to a
route header informatio

n , that i passed
sti nation system.
the unit becomes

Data Link
-The DNA layer below the Routing Layer. The modules in the Data
Link Layer manage physical channels and maintain data integrity.
delay factor
An NSP parameter (NSPdelay) that is multiplied by the estimated
round trip delay time to determine the appropriate value for the
time to retransmit certain NSP messages.
delay weight
An NSP 'parameter weight) that is used to calculate a new
value of the estimated round trip delay. The old round trip
delay is weighted by a function of this statistical factor to

Page F-2

GLOSSARY

calculate the new round trip delay. If the delay weight is set
high, the retransmit time changes slowly. I f the weight is set
low, the observed round trip time can change quickly i f the
observed round trip delays have a wide variance, and thus the
retransmit time can change more rapidly. The default value for
delay weight is 3.
Disconnect Confirm
The NSP No Resources, Disconnect Complete, and No Link messages.
The REASON field in the Disconnect Confirm message (Section 8 )
indicates which message applies.
error control
The NSP function that insures the delivery of NSP data
It consists of an acknowledgment mechanism.

messages.

flow control
The NSP function that coordinates the flow of data on a
link in both directions, from transmit buffers to
buffers, in order to minimize conununications overhead.

logical
receive

inactivity timer
A timer that, upon'expiration, causes NSP to attempt to send a
Data Request message. NSP starts this timer when a logical link
enters the RUN/RUN state. Whenever NSP receives a Data Request
message for that logical link, NSP restarts this timer. The
purpose of the timer is to provide activity for the logical link
so that NSP can determine the probable connectedness of the
physical network supporting the link. The value for the timer is
an NSP parameter (TIMERinact).
Link Service
These
The NSP messages that carry flow control information.
messages are the Data Request and the Interrupt Request messages.

logical link
A virtual channel between two Session Control implementations or
between two components of one Session Control implementation.
NSP's major function is the creation and destruction of logical
links.
logical link identification
unique 32-bit number describing a logical
link.
This
identification consists of the two 16-bit addresses of the ports
at each end of the link.

GLOSSARY

Page F-3

Network Management
The DNA layer directly above the Session Control Layer that
enables
operator
control over and observation of network
parameters and variables.
Network Management also provides
down-line loading. up-line dumping. and testing functions.
node descriptor
A collection
of
variables
and
counters
pertaining
to
communications with a particular node. Some of the variables and
counters are the estimated round trip delay, traffic usage
counters, and error counters.
Other-Data
The NSP Data Request, Interrupt Request, and Interrupt messages.
These are all the NSP data messages other than Data Seqment.
Because all Other-Data messages move in the same data subchannel,
it is sometimes useful to group them together.
port
collection of control variables and parameters for managing
logical links.
Each logical link has a port at each end. Each
NSP at each node has a numer of available ports.
When Session
Control requests a logical link or requests a port be opened to
receive an incoming connect request, NSP allocates a port i f
sufficient resources are available.'

reassembly
The ordering of received data segments by NSP into numbered
sequence for placement into Session Control receive buffers.
request count
This term has two different definitions in the document.
1)
Variables
(FLOWrem.dat
and FLOWrem.int) that NSP uses to
determine when to send data. 2 ) Values sent in Link Service
messages.
The flow control mechanism adds the request counts
received in Data Request and Interrupt Request (Link Service)
messages (definition 2. above) to the request counts it maintains
(definition 1. above) to determine when to send data.
retransmission
The resending of NSP data messages that
have
not
been
acknowledged within a certain period of time. This is part of
NSP's error control mechanism.
retransmission counter
An NSP variable ( C O ~ ~ T r e t r a n sthat
)
contains a count of message
timeouts for Connect Confirm, Disconnect Initiate, Data Seqment,

GLOSSARY
Link Service, and Interrupt messages.
with
the retransmit threshold to
variable.
retransmit threshold

Page F-4
NSP compares this variable
calculate the confidence

An NSP variable (NSPretrans) equal to the maximum number of
successive times a retransmission occurs with no intervening,
received acknowledgment before NSP decides that the physical
network supporting a logical link has failed. NSP compares the
retransmit threshold with the retransmission counter to determine
the value.of the confidence variable.
round trip delay
An NSP parameter (NODEdelay) that represents
the
current
estimated time for an acknowledgment to be received for an NSP
message. This parameter is calculated by a formula described in
Section 4.7.6.
segment
The data carried in a Data Segment message. NSP divides the data
from Session Control transmit buffers into numbered segments for
transmission by Routing.
segmentation
The division of normal data from Session Control transmit buffers
into numbered segments for transmission over logical links.
Session Control
The DNA layer directly above NSP. Session Control defines the
system-dependent aspects of logical link communication. Session
Control provides functions such as name to address translation,
process addressing, and in some systems, access control.
subchannel
A logical communications path within a logical link that handles
a defined category of NSP data messaqes. Because Data Segment
messages are handled differently from Other-Data messaqes, the
two types of messages can be thought of as traveling in two
different subchannels.
Routing
The DNA layer directly below NSP that provides NSP with routing,
congestion control, and packet lifetime control services.

DECnet Digital Network Architecture Phase i v
NSP Functional Specification
AA-X439A-TK

READER'S COMMENTS
NOTE: This form is for document comments only. DIGITAL will use comments submitted on this t l i r m 2 : i: :
company's discretion. If you require a written reply and are eligible to receive one under Sut-LJ..
Performance Report (SPR) service, submit your comments on an SPR form.

Did you find this manual understandable, usable, and well-organized? Please make suggestions for improvemen:

Did you fmd errors in this manual? If so. specify the error and the page number.

Please indicate the type of userlreader that you most nearly represent.

0
0

0
0
0

Name

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify)

Date

Organization
Street
City

State

Zip Code
or

Country

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO 33 MAYNARD MASS.

POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE DOCUMENTATION
1925 ANDOVER STREET TW/E07
TEWKSBURY, MASSACHUSETTS 01 876

- - - - Do Not Tear - Fold Here and Tape - - - - - - - - - - - - - - - - - -7I