DECnet DIGITAL Network Architecture NSP Functional Specification Phase IV Version 4.0.1 July, 1984 .-------. `=======' .------. .---. .-------. | | .-------. `======' `===' `=======' | | `=======' \\ ..| |\ \\ \ | | / / \...| .-----. .-------------. ......| | \ \ \ .-------. .-------. o\.--------------. o `--/ /--' `---|\--' o `-----\\ \-----' o / / | \ o \\ \ o / / | \ O \\ \ O ------------. .----------------. .-----------------. /| | \ \ \ / | \ \ \ \ /.-----| \------.\ \ / `-----| \-----' \ \ --------. / .---------------------. \ .----------------------. / | | | \| \ \ | / /----' `---------------------' `--------\ \ \-------' / / \ \ \ / / \ \ \ / .------------------------ / |\ \ \ \ \ \ \ \ \ \ \ \ \ .---------------- \ | \ \| \ \ `---------\ \ Page 2 ABSTRACT 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. DIGITAL EQUIPMENT CORPORATION MAYNARD, MASSACHUSETTS 01754 Copyright (C) 1980, 1982 Digital Equipment Corporation This material may be copied, in whole or in part, provided that the above copyright notice is included in each copy along with an acknowledgment that the copy describes protocols, algorithms, and structures developed by Digital Equipment Corporation. This material may be changed without notice by Digital Equipment Corporation, and Digital Equipment Corporation is not responsible for any errors which may appear herein. Page 3 CONTENTS 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 6 2 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 7 2.1 Design Scope . . . . . . . . . . . . . . . . . . . 8 2.2 Relation to DIGITAL Network Architecture . . . . . 8 2.3 Routing Characteristics . . . . . . . . . . . . 11 2.4 Basic NSP Concepts . . . . . . . . . . . . . . . 12 2.4.1 Logical Links And Ports . . . . . . . . . . . 12 2.4.2 Port And Logical Link States . . . . . . . . . 13 2.4.3 Logical Link Identification . . . . . . . . . 13 2.4.4 Data Flow . . . . . . . . . . . . . . . . . . 14 2.5 Messages . . . . . . . . . . . . . . . . . . . . 16 2.6 Major NSP Functions . . . . . . . . . . . . . . 19 2.6.1 Establishing And Destroying Logical Links . . 19 2.6.2 Error Control . . . . . . . . . . . . . . . . 21 2.6.3 Flow Control . . . . . . . . . . . . . . . . . 24 2.6.3.1 Normal Data Flow Control . . . . . . . . . . 24 2.6.3.2 Interrupt Data Flow Control . . . . . . . . 27 2.6.4 Segmentation And Reassembly Of User Messages . 28 2.7 Functional Components . . . . . . . . . . . . . 28 2.7.1 Data Bases And Buffer Pools . . . . . . . . . 29 2.7.2 Modules . . . . . . . . . . . . . . . . . . . 31 3 NSP INTERFACES . . . . . . . . . . . . . . . . . . 32 3.1 Session Control Interface . . . . . . . . . . . 33 3.2 Network Management Interface . . . . . . . . . . 40 3.3 Routing Interface . . . . . . . . . . . . . . . 47 4 NSP STATES . . . . . . . . . . . . . . . . . . . . 49 4.1 Port States . . . . . . . . . . . . . . . . . . 49 4.2 Logical Link States . . . . . . . . . . . . . . 54 5 NSP DATA BASES AND BUFFER POOLS . . . . . . . . . 58 5.1 NSP's Internal Data Base . . . . . . . . . . . . 58 5.2 Session Control Port Data Base . . . . . . . . . 60 5.3 Reserved Port Data Base . . . . . . . . . . . . 64 5.4 Node Data Base . . . . . . . . . . . . . . . . . 64 5.5 Buffer Pools . . . . . . . . . . . . . . . . . . 65 6 DETAILED FUNCTIONAL MODEL . . . . . . . . . . . . 66 6.1 Interface Routines . . . . . . . . . . . . . . . 68 6.2 Receive Dispatcher Module . . . . . . . . . . . 73 6.3 Index to Routines . . . . . . . . . . . . . . . 76 6.4 Receive Processes . . . . . . . . . . . . . . . 78 6.4.1 Connect/Disconnect Receive Processes . . . . . 78 6.4.2 Data Receive Processes . . . . . . . . . . . . 82 6.4.3 Reserved Receive Processes . . . . . . . . . . 90 6.5 Reassembly Module . . . . . . . . . . . . . . . 91 6.6 Transmit Processes . . . . . . . . . . . . . . . 92 6.6.1 Connect/Disconnect Transmit Processes . . . . 92 6.6.2 Data Transmit Processes . . . . . . . . . . . 95 6.6.3 Reserved Transmit Processes . . . . . . . . . 103 6.7 Transmit Format Module . . . . . . . . . . . . . 104 6.8 Segmentation Module . . . . . . . . . . . . . . 109 6.9 Transmit Allocation Module . . . . . . . . . . . 110 7 ALGORITHMS . . . . . . . . . . . . . . . . . . . . 110 7.1 Data Segment Retransmission . . . . . . . . . . 111 7.2 Other-Data Handling . . . . . . . . . . . . . . 111 Page 4 7.3 Retransmission Timer Value Estimation . . . . . 112 7.4 Inactivity Timing . . . . . . . . . . . . . . . 113 7.5 Confidence Testing . . . . . . . . . . . . . . . 114 8 MESSAGE FORMATS . . . . . . . . . . . . . . . . . 114 8.1 Message Format Notation . . . . . . . . . . . . 115 8.2 General Message Format . . . . . . . . . . . . . 117 8.3 Data Messages . . . . . . . . . . . . . . . . . 118 8.3.1 Data Segment Message . . . . . . . . . . . . . 119 8.3.2 Interrupt Message . . . . . . . . . . . . . . 121 8.3.3 Link Service Message . . . . . . . . . . . . . 123 8.4 Acknowledgment Types . . . . . . . . . . . . . . 126 8.4.1 Data Acknowledgment Message . . . . . . . . . 126 8.4.2 Other-Data Acknowledgment Message . . . . . . 128 8.4.3 Connect Acknowledgment Message . . . . . . . . 129 8.5 Control Messages . . . . . . . . . . . . . . . . 130 8.5.1 No Operation Message . . . . . . . . . . . . . 130 8.5.2 Connect Initiate And Retransmitted Connect Initiate Messages . . . . . . . . . . . . . . 131 8.5.3 Connect Confirm Message . . . . . . . . . . . 133 8.5.4 Disconnect Initiate Message . . . . . . . . . 135 8.5.5 Disconnect Confirm Message . . . . . . . . . . 136 APPENDIX A LOGICAL LINK ADDRESS ASSIGNMENT/DEASSIGNMENT A.1 INTERFACE TO THE ALGORITHM . . . . . . . . . . . . A-1 A.2 DATA STRUCTURES . . . . . . . . . . . . . . . . . A-2 A.3 ALGORITHM OPERATION . . . . . . . . . . . . . . . A-3 APPENDIX B SEGMENTATION MODULE EXAMPLE B.1 DATA STRUCTURES . . . . . . . . . . . . . . . . . B-1 B.2 OPERATION . . . . . . . . . . . . . . . . . . . . B-2 APPENDIX C REASSEMBLY MODULE EXAMPLE C.1 DATA STRUCTURES . . . . . . . . . . . . . . . . . C-1 C.2 OPERATION . . . . . . . . . . . . . . . . . . . . C-2 APPENDIX D TRANSMIT ALLOCATION MODULE EXAMPLE D.1 DATA STRUCTURES . . . . . . . . . . . . . . . . . D-1 D.2 PRIMITIVE FUNCTIONS . . . . . . . . . . . . . . . D-1 D.3 OPERATION . . . . . . . . . . . . . . . . . . . . D-1 APPENDIX E REVISION HISTORY Page 5 APPENDIX F GLOSSARY FIGURES 1 NSP Relation to DNA . . . . . . . . . . . . . . . 10 2 Model of Data Flow as Seen by Session Control. . . 15 3 Connection with Acceptance . . . . . . . . . . . . 19 4 Connection with Rejection . . . . . . . . . . . . 20 5 Connection Attempt with No Resources . . . . . . . 20 6 Connection Attempt with No Communication . . . . . 21 7 Disconnection . . . . . . . . . . . . . . . . . . 21 8 Segment Acknowledgment Operation . . . . . . . . . 23 9 Example of Segment Flow Control for Normal Data on a Logical Link (shown in one direction only) . . . 26 10 Interrelationship of NSP Components . . . . . . . 30 11 Port State Diagram . . . . . . . . . . . . . . . . 53 12 Logical Link State Diagram . . . . . . . . . . . . 56 TABLES 1 NSP Messages . . . . . . . . . . . . . . . . . . . 17 2 Port States . . . . . . . . . . . . . . . . . . . 50 3 NSP's Internal Data Base . . . . . . . . . . . . . 59 4 Session Control Port . . . . . . . . . . . . . . 60 5 Reserved Port . . . . . . . . . . . . . . . . . . 64 6 Node Descriptor . . . . . . . . . . . . . . . . . 65 7 Index to Routines Used in Model . . . . . . . . . 76 Introduction Page 6 1 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 together 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 described in terms of calls to subroutines. This specification describes Phase IV NSP architecture. In Phase II, an earlier version, Session Control was part of NSP. With Phase III and Phase IV, Session Control has been logically separated from NSP, and the interface between the two layers defined. The Session Control Layer is described in a separate functional specification. The Routing specification, also a part of the Phase II NSP specification, has been greatly expanded in Phase III and Phase IV and is contained in a separate Routing specification. Appendix E details the differences between Phase III and Phase IV 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, the document may be useful to anyone interested in the details of DECnet structure. The other current DNA functional specifications are: DNA Data Access Protocol (DAP) Functional Specification, Version 5.6.0, Order No. AA-K177A-TK DNA Digital Data Communications Message Protocol (DDCMP) Functional Specification, Version 4.1.0, Order No. AA-K175A-TK DNA Ethernet Data Link Functional Specification, Version 1.0.0, Order No. AA-Y298A-TK DNA Ethernet Node Product Architecture Specification, Version 1.0.0, Order No. AA-X440A-TK DNA Maintenance Operations Functional Specification, Version 3.0.0, Order No. AA-X436A-TK Introduction Page 7 DNA Network Management Functional Specification, Version 4.0.0, Order No. AA-X437A-TK DNA Routing Layer Functional Specification, Version 2.0.0, Order No. AA-X435A-TK DNA Session Control Functional Specification, Version 1.0.0, Order No. AA-K182A-TK The Ethernet - A Local Area Network - Data Link Layer and Physical Layer Specifications, Version 2.0, (Digital, Intel, and Xerox), Order No. AA-K759B-TK The DECnet DIGITAL Network Architecture (Phase IV) General Description (Order No. AA-N149A-TC) provides an overview of the network architecture and an introduction to each of the functional specifications. 2 FUNCTIONAL DESCRIPTION NSP performs the following functions: 1. Enables the creation and destruction of virtual channels (logical links) that can be used for sending messages within a network node and between network nodes. 2. Manages the movement of interrupt and normal data from transmit buffers to receive buffers, using flow control mechanisms. 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) o Relation of NSP to the DIGITAL Network Architecture (Section 2.2) o Routing characteristics (Section 2.3) o Basic concepts (Section 2.4) o Messages (Section 2.5) Functional Description Page 8 o Major functions (Section 2.6) o Functional components (Section 2.7) 2.1 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. 2. Performance. NSP allows an implementation to perform without deadlocks while using dynamic buffer pools. 3. Promptness. NSP minimizes the delays incurred in moving data from one Session Control module to another. 4. Efficiency. NSP minimizes the communications overhead (for example, line bandwidth) consumed by the protocol. 5. Extensibility. NSP accommodates additional functions in the future, leaving earlier functions as a subset. 6. Fairness. If more than one logical link is established to the same destination at the same time, NSP assures that each provides useful communication services. 7. 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: 1. Maximum throughput. NSP will not necessarily maximize the throughput of a logical link. 2. 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. 2.2 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 Functional Description Page 9 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 directly with it. In fact, the upper three layers are sometimes referred to as the "end user." 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. Functional Description Page 10 .----------------------------. | User Modules | `----------------------------' | | | | | V .- | ------- | -----------------------------------. .------| | Network | Management Modules | | `- | ------- | -----------------------------------' | | | | | | | | V V | | | .- | -------------------------------- | ------. | :----> | | Network Application Modules | | | | `- | -------------------------------- | ------' | | | | | | | | V V V | | | .---------------------------------------. | | :----> | Session Control Modules | | | | `---------------------------------------' | | | | | | | V | | | .----------------------------. | | :------------> | End Communications Modules | | | | `----------------------------' | | | | | | | V | | | .--------------------------. | | :------------> | Routing Layer Modules | | | | `--------------------------' | | | | | | | V V V | .-----------------------------------------. :------------> | Data Link Modules | | `-----------------------------------------' | | | V | .--------------------------. `------------> | Physical Link Modules | `--------------------------' | `-------------------------> 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 Functional Description Page 11 Application Layer, reside in the User Layer. 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 testing functions. 3. 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. 4. 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. 5. End Communications Layer. The End Communications Layer defines the system-independent aspects of logical link communication. 6. Routing Layer. Modules in the Routing Layer route messages, called packets, between source and destination nodes. 7. Data Link Layer. The Data Link Layer defines the protocol concerning data integrity and physical channel management. 8. 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. 2.3 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. 2. There is an extremely low probability that Routing will: a. Duplicate a datagram Functional Description Page 12 b. Deliver a datagram to the wrong destination c. Change the data in a datagram 3. Routing may fail to deliver a datagram. 4. Routing may fail to deliver datagrams to a given destination from a given source in the order they were transmitted. 5. Datagrams delivered to a given 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. 2.4 Basic NSP Concepts This section describes concepts that are fundamental to an understanding of NSP. 1. Logical links and ports (Section 2.4.1) 2. Port and logical link states (Section 2.4.2) 3. Logical link identification (Section 2.4.3) 4. 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 specifies these variables. NSP manages ports. Each node on a network 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 incoming 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. Functional Description Page 13 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. 2.4.2 Port And Logical Link States - Each end of a logical link is in one of a set of 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 NSP 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 (but 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. Functional Description Page 14 2.4.4 Data Flow - After a logical link is established, data may flow in both directions (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 end of the link the receiving NSP interface, responding to Session Control DATA-RCV calls, transforms the data from its network form to its receive buffer form. The mechanisms NSP uses to handle data are transparent to Session Control. From Session Control's viewpoint, the data flow is as shown in Figure 2. This figure shows Session Control data transformed from a transmitting Session Control to a transmitting NSP and then transformed back from a receiving NSP to a receiving Session Control. The NSP data does not actually move through the network as shown. (The DNA General Description shows how Routing packets actually move through the network.) Functional Description Page 15 Transmitting Node .--------------------------------. | TRANSMITTING | NSP | | SESSION CONTROL | Interface | | | | | .---. .---. | | | | B | | B | | |=====.. | | U | | U | | | || | | F | | F | | | || | | F | | F | | | || | | E |. . .| E | | | || | | R | | R | | | || | | | | | | | || | | # | | # | | | || | | N | | 1 | | | || | `---' `---' | | || `--------------------------------' || \ / \/ ##################### # # ################ ###### # # NETWORK # # # # ###### .----------------------------------. # # | E | | | E | | ##### # | O | DATA | . . . | O | DATA | # ##### | M | | | M | | # # `----------------------------------' #### # # # # # # ############### ######### #################### || || || Receiving Node || .----------------------------------. || | NSP | RECEIVING | || | Interface | SESSION CONTROL | || | | | || | | .---. .---. | || \ | | | B | | B | | ``=== `| | | U | | U | | LEGEND: / | | | F | | F | | | | | F | | F | | EOM end-of-message flag | | | E |. . .| E | | DATA a collection | | | R | | R | | of 8-bit bytes | | | | | | | | | | # | | # | | | | | N | | 1 | | | | `---' `---' | `----------------------------------' Figure 2 Model of Data Flow as Seen by Session Control. Functional Description Page 16 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 that no data will be lost. Section 3.1 details the data flow 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 NSP messages: o Data messages o Acknowledgment messages o Control messages Table 1 summarizes the functions performed by each NSP message. Section 8 describes the message formats in detail. Functional Description Page 17 Table 1 NSP Messages +----------------+-----------------+---------------------------------+ | Type | Message | Description | |====================================================================| | Data | Data Segment | Carries a portion of a Session | | | | Control message. (This has | | | | been passed to Session Control | | | | from higher DNA layers and | | | | Session Control has added its | | | | own control information.) | +----------------+-----------------+---------------------------------+ | Data | Interrupt | Carries urgent data, origina- | | (also called | | ting from higher DNA layers. | | Other-Data) |-----------------+---------------------------------| | | Data Request | Carries data flow control | | | | information (also called Link | | | | Service message). | | |-----------------+---------------------------------+ | |Interrupt Request| Carries interrupt flow control | | | | information (also called Link | | | | Service message). | +----------------+-----------------+---------------------------------+ | Acknowledgment | Data | Acknowledges receipt of either | | | Acknowledgment | a Connect Confirm message or | | | | one or more Data Segment | | | | messages, and optionally an | | | | Other Data message. | | |-----------------+---------------------------------+ | | Other Data | Acknowledges receipt of one or | | | Acknowledgment | more Interrupt, Data Request or | | | | Interrupt Request messages. | | |-----------------+---------------------------------+ | | Connect | Acknowledges receipt of a | | | Acknowledgment | Connect Initiate message or | | | | Retransmitted Connect Initiate | | | | message. | +----------------+-----------------+---------------------------------+ (to be continued) Functional Description Page 18 Table 1 (Cont.) NSP Messages +----------------+-----------------+---------------------------------+ | Type | Message | Description | |====================================================================| | Control | Connect Initiate| Carries a logical link connect | | | | request from a Session Control | | | | module. | | |-----------------+---------------------------------+ | | Connect Confirm | Carries a logical link connect | | | | acceptance from a Session | | | | Control module. | | |-----------------+---------------------------------+ | | Disconnect | Carries a logical link connect | | | Initiate | rejection or disconnect request | | | | from a Session Control module. | | |-----------------+---------------------------------+ | | No Resources | Sent when a Connect Initiate | | | | message (or Retransmitted | | | | Connect Initiate message) is | | | | received and there are no | | | | resources to establish a new | | | | port (also called Disconnect | | | | Confirm message). | | |-----------------+---------------------------------+ | | Disconnect | Acknowledges the receipt of a | | | Complete | Disconnect Initiate message | | | | (also called Disconnect Confirm | | | | message). | | |-----------------+---------------------------------+ | | No Link | Sent when a message is received | | | | for a non-existing link (also | | | | called Disconnect Confirm | | | | message). | | |-----------------+---------------------------------+ | | No Operation | Does nothing (included for | | | | compatibility with NSP V3.1). | +----------------+-----------------+---------------------------------+ Functional Description Page 19 2.6 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) 2. Error control (Section 2.6.2) 3. Flow control (Section 2.6.3) 4. Segmentation and reassembly of user data messages (Section 2.6.4) 2.6.1 Establishing And Destroying Logical Links - A source NSP and a destination NSP exchange messages 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 described in Section 3.1. The message exchanges below will take place correctly in an implementation, if the algorithms in Section 4 are followed. .--------------------------------. .---------------------------. | Source | | Destination | |--------------------------------| |---------------------------| | Session | | | |Session | | Control | NSP | | NSP |Control | |--------------------------------| |---------------------------| | | | | | | | CONNECT-XMT -->Connect -------------> | | | | Initiate | | | | | | | | | | | | <------------ Connect | | | | | | Acknowledgment | | | | | | | | | | <------------ Connect | | | | | | Confirm<-------- ACCEPT | | | Data | | | | | | Acknowledgment ---------> | | | | | | | | `--------------------------------' `---------------------------' Figure 3 Connection with Acceptance Functional Description Page 20 .--------------------------------. .---------------------------. | Source | | Destination | |--------------------------------| |---------------------------| | Session | | | |Session | | Control | NSP | | NSP |Control | |--------------------------------| |---------------------------| | | | | | | | CONNECT-XMT -->Connect -------------> | | | | Initiate | | | | | | | | | | | | <------------ Connect | | | | | | Acknowledgment | | | | | | | | | | <------------ Disconnect | | | | | | Initiate<------- REJECT | | | Disconnect | | | | | | Complete ------------> | | | | | | | | `--------------------------------' `---------------------------' Figure 4 Connection with Rejection .-------------------------------. .--------------------------. | Source | | Destination | |-------------------------------| |--------------------------| | Session | | | |Session | | Control | NSP | | NSP |Control | |-------------------------------| |--------------------------| | | | | | | | CONNECT-XMT -->Connect ---------------> | | | | Initiate | | | | | | | | | | | | <-------------- No Resources | | | | | | | | `-------------------------------' `--------------------------' Figure 5 Connection Attempt with No Resources Functional Description Page 21 .-------------------------------. .--------------------------. | Source | | Destination | |-------------------------------| |--------------------------| | Session | | | |Session | | Control | NSP | | NSP |Control | |-------------------------------| |--------------------------| | | | | | | | CONNECT-XMT -->Connect --------. | | | | | Initiate | | (Connect Initiate | | | | | | returned to sender | | | | <-------' by Routing) | | | | | | | | `-------------------------------' `--------------------------' Figure 6 Connection Attempt with No Communication .-------------------------------. .--------------------------. | Source | | Destination | |-------------------------------| |--------------------------| | Session | | | |Session | | Control | NSP | | NSP |Control | |-------------------------------| |--------------------------| | | | | | | | CONNECT-XMT -->Disconnect ---------------> | | | | Initiate | | | | | | | | | | | | <-------------- Disconnect | | | | | | Complete | | | | | | | | `-------------------------------' `--------------------------' Figure 7 Disconnection 2.6.2 Error Control - NSP 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 in each subchannel are numbered sequentially by the transmitting NSP. The receiving NSP returns an acknowledgment quickly. Otherwise, the transmitting NSP retransmits the message. It is not necessary to acknowledge each message individually. Acknowledgment of a given numbered message implies acknowledgment of all messages with a lower number (modulo the maximum message number). Functional Description Page 22 Figure 8 depicts the segment acknowledgment operation. Section 8 specifies the format of the acknowledgment messages. .-. |1| The data-transmitting NSP assigns a transmit number to a message, `-' transmits the message, and starts a timer. .-------------------. .------------------. | | .---------------------. | | | | | transmit number = n | | | | |--| Data Segment Message|-->| | | Data-transmitting | `---------------------' | Data-receiving | | NSP | | NSP | | | .---------------------. | | | | | transmit number = m | | | | |--| "Other Data" Message|-->| | | | `---------------------' | | `-------------------' `------------------' Data Subchannels .-. |2| If the timer times out, the message is retransmitted. `-' .-. |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. .--------------------. .----------------. | | .----------------------. | | | | | transmit number = n+1| | | | |--| Data Segment Message |-->| | | Data-transmitting | `----------------------' | Data-receiving | | NSP | | NSP | | | .----------------------. | | | | | transmit number = m+1| | | | |--| "Other Data" Message |-->| | | | `----------------------' | | `--------------------' `----------------' Data Subchannels .-. |4| When the message with the first transmit number is received by `-' the data-receiving NSP, it returns that number as an acknowledg- ment number within the first acknowledgment. .-. |5| If the next data message transmit number received is equal to the `-' current acknowledgment 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. Functional Description Page 23 .------------. .- - - - - - - - . .---------------. .-----------. | | . receive ack. . | receive ack. | | | | | . number = n . | number = n + 1| | | | |<--. Data .--| Data |--| | | | . Acknowledgment . | Acknowledgment| | | | Data- | . Message* . | Message | | Data- | |transmitting| `- - - - - - - - ' `---------------' | receiving | | NSP | .------------------. | NSP | | | | receive ack. | | | | | | number = m | | | | |<-----------| "Other Data" |----------| | | | | Acknowledgment | | | | | | Message | | | `------------' `------------------' `-----------' 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. .-. |6| However, if the data-receiving NSP receives a data message trans- `-' mit number less than or equal to the current receive acknowledg- ment number for that subchannel, the data segment is discarded. The data-receiving NSP sends an acknowledgment back to the data- transmitting NSP. The acknowledgment contains the receive acknowledgment number. .-. |7| If 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 24 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. 2.6.3.1 Normal Data Flow Control - Flow control requires two algorithms for normal data: 1. 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. 2. An algorithm executed by a data-transmitting NSP that determines if a Data Segment message may be sent. In addition, an "on/off" 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 send," the data-transmitting NSP may not transmit normal data. When 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 end of the 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 o Segment flow control o Session Control message flow control The choice of flow control is indicated via fields in Connect Functional Description Page 25 Initiate, Retransmitted Connect Initiate and Connect Confirm messages. 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. A 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. No flow control. If the data-receiving NSP selected "no flow control," the data-transmitting NSP may transmit data at any time (subject to the "on/off" constraint). .-. |1| NSP/Node A send a Connect Initiate message to NSP/Node B: `-' .------------------. | Connect Initiate |---------------> `------------------' .-. |2| NSP/Node B, having received the Connect Initiate message, returns `-' a Connect Confirm message. A field in the message indicates that NSP/Node B expects segment flow control: .-------------------------. <----------------| Connect : : | | Confirm : : | `-------------------A-----' "I want segment flow control"---------' .-. |3| NSP/Node A's data base has the initial value of 0 for its request `-' count variable for normal data segment flow control: .-----------------. | FLOWrem_dat=0 | | .-----------. | `--' `--' .-. |4| NSP/Node B sends Data Request message containing a flow control `-' 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): .-------------------------. <---------------| Data : | | Request : | `------------------A------' "I can receive n messages"----------' Functional Description Page 26 .-. |5| NSP/Node A sets FLOWrem_dat to n: `-' .-----------------. | FLOWrem_dat=n | | .-----------. | `--' `--' .-. |6| NSP/Node A executes algorithm to determine if Data Segment `-' Number 1 can be sent (highest acknowledged Data Segment message plus the current request count must be greater than or equal to the number of the next Data Segment message sent): * . . . . * 0+n>=1? *--NO--can't send . . . . * | YES | SEND .-. |7| The answer to the above is YES, so NSP/Node A sends Data Segment `-' number 1: .----------------. | Data Segment 1 |-----------------> `----------------' .-. |8| NSP/Node B acknowledges receipt of first data segment: `-' .------------------------. <---------------| Data Acknowledgment | | of segment number 1 | `------------------------' .-. |9| NSP/Node A subtracts 1 from its flow control request count: `-' .-----------------. | FLOWrem_dat=n-1 | | .-----------. | `--' `--' Figure 9 Example of Segment Flow Control for Normal Data on a Logical Link (shown in one direction only) Segment flow control. Figure 9 shows an example of the operation of segment flow control. Segment flow control operates in the following manner: If 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 Segment message that has Functional Description Page 27 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 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 flow control. If the data-receiving NSP selected Session Control message flow control, the data-transmitting NSP cannot send a segment if the number of end-of-message segments between the highest acknowledged segment and the segment in question (exclusive) is greater than or equal to the count. The 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 segment flow control). Once a Data Segment has been given permission to be transmitted, the permission will never be withdrawn. 2.6.3.2 Interrupt Data Flow Control - All NSPs use interrupt data flow control for moving 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 message acknowledged by the interrupt-receiving NSP. Functional Description Page 28 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 contained in a single Session Control buffer into segments. A data-receiving NSP reassembles the segments. The data-transmitting 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 well 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 size cannot be larger than the node's Routing Layer will permit. 2. The maximum length that the data-receiving NSP can receive. The SEGSIZE field in the Connect Initiate and Connect Confirm messages, exchanged 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 sequence, 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," which 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 6 specifies in 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 29 2.7.1 Data Bases And Buffer Pools - The following is a model of the NSP data bases: 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 that they remain set until the user changes them. 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. Reserved 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. Functional Description Page 30 .---------. | SESSION | | CONTROL | `---------' | v .-----------. | INTERFACE | | ROUTINES | `-----------' | ^ | .-------------------' | `---------------. | | | .------. v | v `------' .--------------. | .------------. |CACHE | | SEGMENTATION | | | REASSEMBLY |<-->|AND | | MODULE | | | MODULE | |COMMIT| `--------------' | `------------' |POOLS | ^ v ^ `------' | .--------. | .--------------. `--------' .-----------. | TRANSMIT | | PORT | | RECEIVE | | PROCESSES |<------->| DATA |<-------->| PROCESSES | `--------------' | BASES |<-----. `-----------' | | `--------' | | | | | | | `------. | | .-------. v v .----------. | v `-------' .----------. .----------. `----------' | .------------. |RECEIVE| |TRANSMIT | | TRANSMIT | | LARGE | | | RECEIVE | |BUFFER | |ALLOCATION| | FORMAT |<->| AND | `->| DISPATCHER |<->|POOL | |MODULE | | MODULE | | SMALL | | MODULE | | | `----------' `----------' | TRANSMIT | `------------' `-------' | | BUFFER | | | | POOLS | | | `----------' | | | | .-------------. | `---->| ROUTING |<-------' `-------------' Figure 10 Interrelationship of NSP Components Node data base. The node data base contains a collection of node descriptors. A node descriptor is required for each remote 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). 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 31 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 of receive buffers required to receive an NSP message from Routing. Commit buffer pool. The commit buffer pool is an optional pool which contains commit buffers used for data that the receiving node may commit to storage 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 storage 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. 2.7.2 Modules - NSP modules perform specialized functions. There are two kinds of modules: 1. A process is a module that is independent of other modules, but uses the services of some other modules. It is designed as if it were executing on a processor dedicated to it. 2. A 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. Implementations need 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. It polls Routing for 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 Page 32 states. Each Session Control port has a set of these processes. Reassembly routine. The reassembly routine determines the flow control policy, maintains the 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. It queues messages to Routing. It 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 routine. The transmit allocation routine receives requests for permission to transmit from the transmit processes. It allocates permission to transmit in a way that guarantees that when more than one logical link is established to the same destination at the same time each provides useful communication services. 3 NSP INTERFACES This section describes the three external NSP interfaces: 1. Control interface 2. Network Management interface 3. Routing interface The interface functions are described as calls to subroutines in the following format: 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 polling to obtain "buffer returned" notifications. A "buffer" argument denotes a system-dependent buffer descriptor that contains location and length information. A "port id" is a system-dependent number identifying a port. Although not described in the following NSP Interfaces Page 33 functions, an invalid port identifier causes an error. Note that an implementation is not required to code the interfaces as calls to subroutines. The calls specify functions only. It may be useful to refer to the port state descriptions in Section 4.1 when studying the following interface functions. 3.1 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 can communicate with each other via a logical link. The calls, described by function, are as follows: STATUS (; NSP status) returns: NSP is halted. NSP is running; minimum receive buffer size (NSPbuf -- Table 3, Section 5.1) returned 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 address of the requesting node; the buffer receives the NSP Interfaces Page 34 incoming connect data. When the port state 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 transmit 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; confidence) returns: 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 ascertain if the physical path supporting the link is connected. The result of this testing is the probable state of connectivity. It is not a guaranteed state. Session Control may issue this call to determine when to 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 35 CONNECT-XMT (destination [,circuit [,nexthop]], buffer; return) destination: 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 if circuit is a broadcast circuit) buffer:: contains connect data returns: port allocated; port id returned port not allocated -- insufficient resources port not allocated -- NSP halted This function allocates a port and requests a logical link connection. After a logical link has been successfully formed, 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; return) returns: connect request accepted by destination -- port in RUNNING state; accept data returned in buffer connect request rejected by destination -- port in REJECTED state; reject data returned in buffer 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, NSP 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 36 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. If the connect request is accepted, up to 16 bytes of accept data may be returned in the buffer. If 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; return) returns: link accepted port not in CONNECT-RECEIVED state This function accepts a connect request from a remote Session Control module. The call supplies a buffer containing up to 16 bytes of accept data. REJECT (port id, value, buffer; return) returns: 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; return) returns: 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 37 ABORT-XMT (port id, value, buffer; return) returns: 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 to 16 bytes of abort data. DISCONNECT-RCV (port id, value, buffer; return) returns: 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; return) xmtflag: 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 o not-end-of-message Section 2.4.4 describes data flow. returns: buffer queued buffer not queued -- insufficient resources port not in RUNNING state This function queues a transmit buffer to a port for transmitting normal data on a logical link. NSP refuses to queue the buffer either if it lacks the resources to do so or if the port is not in the RUNNING state. NSP Interfaces Page 38 XMT-POLL (port id; return) returns: no transmit complete transmit complete -- buffer descriptor returned This function returns a transmit buffer to Session Control. DATA-RCV (port id, buffer, rcvflag; return) rcvflag: a flag indicating whether data truncation is allowed. It may have either of the following values: o no truncation allowed o truncation allowed returns: buffer queued buffer not queued -- insufficient resources buffer not queued -- buffer too small and no truncation was specified in rcvflag 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; return) returns: no buffer returned (Either no receive buffers are queued to the port or there is no receive data 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 39 buffer returned empty -- port not in RUNNING, DISCONNECT-INITIATE, DISCONNECT-COMPLETE, or 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-message" 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. If 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 if 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 "end-of-message," may result in data and status being given to the data-receiving Session Control either in two buffers, as given 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-message." 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. A data-receiving Session control module may mix calls with the "truncation allowed" rcvflag with calls with the "no truncation allowed" rcvflag. NSP Interfaces Page 40 If Session Control closes a port that has receive buffers queued via the DATA-RCV call, NSP returns these buffers immediately. INTERRUPT-XMT (port id, buffer; return) returns: 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. NSP may refuse a request to send interrupt data if it is unable to queue the data internally. The buffer may be up to 16 bytes long. INTERRUPT-RCV (port id, buffer; return) returns: 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. 3.2 Network Management Interface Network Management can perform the following functions using NSP's Network Management interface: 1. Initialize or halt NSP. 2. Read and set some of NSP's local parameters and variables. 3. Read NSP's remote node variables and counters. Clear NSP's remote node counters. 4. Read (one event at a time) and clear NSP's event queue. The interface is modeled as a collection of functions provided by subroutines. Each call represents a specific function. In each NSP Interfaces Page 41 return, the variable in parentheses is its name appearing in the data base descriptions in Tables 3 and 4, Section 5. 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. All 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: 1. NSP closes all ports. 2. NSP will refuse to open a new port. 3. NSP returns all Session Control buffers to Session Control. 4. NSP freezes its counters and event queue. LOCAL-READ-ADDRESS (; address) return: NSP's node address (NSPself) This function reads NSP's node address. LOCAL-READ-INACTIVITY (; inactivity) return: NSP's inactivity timer (NSPinact_tim) This function returns the interval after which, if there is no NSP Interfaces Page 42 data going in either direction on a link, NSP checks the link. NSP checks the link by sending 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 (; delay) return: NSP's delay factor (NSPdelay) 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 (; weight) return: NSP's delay weight (NSPweight) 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 (; retransmit) return: NSP's retransmit threshold (NSPretrans) 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 (; maximum ports) return: NSP's maximum ports number (NSPmax) This function returns the maximum number of ports NSP has concurrently had assigned to a logical link (in other words, concurrently in a state other than OPEN or CLOSED). This is called NODE MAXIMUM LOGICAL LINKS ACTIVE in the DNA Network Management Functional Specification. NSP Interfaces Page 43 LOCAL-READ-TOTAL (; total ports) return: 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 (; version number) return: NSP's version number (NSPversion) This function returns the local NSP's version number. For this version, the value returned is 4.0. 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 to the remote node (NODEdelay) This function returns the estimated round trip delay to the remote node. NSP Interfaces Page 44 REMOTE-READ-ACTIVE (node; active) return: the number of active logical links to the remote NSP (NODEactive) 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 Specification. REMOTE-READ-BYTES RECEIVED (node; bytes received) return: the number of user data bytes received (NODEbyt_rcv) 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 total number of user data bytes sent to the remote node. REMOTE-READ-MESSAGES RECEIVED (node; messages received) return: the total number of messages received from the remote node (NODEmsg_rcv) This function returns the total 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 the remote node (NODEmsg_xmt) This function returns the total number of NSP messages sent to the remote node. This includes retransmissions. NSP Interfaces Page 45 REMOTE-READ-CONNECTS RECEIVED (node; connects received) return: the total number of NSP Connect Initiate messages received from the remote node (NODEcon_rcv) This 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 sent to the remote node (NODEcon_xmt) This function returns the number of NSP Connect Initiate messages sent to the remote node. 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 Initiate messages rejected by the 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 the number of response timeouts received from the destination NSP. REMOTE-READ-AND-CLEAR (node, value; qualifier) value: the numerical value for the corresponding qualifier. qualifier: one of the following, defined above: o REMOTE-READ-BYTES RECEIVED o REMOTE-READ-BYTES SENT o REMOTE-READ-MESSAGES RECEIVED o REMOTE-READ-MESSAGES SENT NSP Interfaces Page 46 o REMOTE-READ-CONNECTS RECEIVED o REMOTE-READ-CONNECTS SENT o REMOTE-READ-CONNECTS REJECTED o REMOTE-READ-TIMEOUTS returns: the selected information This function reads and then clears a node-dependent NSP counter. READ-QUEUE (; return) returns: event queue empty the first entry on the event queue. One of the following events: invalid message 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. NSP 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." The DNA Network Management Functional Specification describes NSP Interfaces Page 47 return formats. CLEAR-QUEUE This function clears NSP's internal event queue. 3.3 Routing Interface NSP requires a Routing service for its operation. A Routing service provides NSP with the ability to send datagrams (containing NSP 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, destination, returnflag [,circuit[,nexthop]], buffer, tryhard; return) source: 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 if the destination node is inaccessible. The flag may have one of the following values: o false -- do not return packet o true -- return packet circuit: an internal NSP mechanism selector (used for loop testing). One of: o unspecified o 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 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 NSP Interfaces Page 48 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) only if it has insufficient resources to queue the buffer. If the destination node is currently unreachable, then Routing accepts the buffer, although it 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 queued by Routing buffer returned to NSP buffer: a buffer previously given to Routing via a ROUTING-TRANSMIT call This function checks to see if a previously queued transmit buffer can be returned to NSP. 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[,nexthop]], buffer, tryhard; return) source: a source node address destination: a destination node address circuit: an internal NSP mechanism selector (used for loop testing). One of: NSP Interfaces Page 49 o unspecified o 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 node addresses -- contains a normal packet buffer returned -- contains a "return to sender" packet This function checks to see if a previously queued receive buffer can be returned to NSP. 4 NSP STATES This section describes the states and state transitions required for normal NSP operation. 4.1 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 architecture 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 the normal port states. NSP States Page 50 Table 2 Port States +----------------------------------+---------------------------------+ | (Symbol) State | Explanation | |====================================================================| | (O) OPEN | The local Session Control has | | | issued an OPEN call which | | | created the port. | +----------------------------------+---------------------------------+ | (CR) CONNECT-RECEIVED | NSP has received a Connect | | | Initiate message. (The remote | | | port is or was in the | | | CONNECT-INITIATE state.) | +----------------------------------+---------------------------------+ | (DR) DISCONNECT-REJECT | The local Session Control has | | | issued a REJECT call while the | | | port was in the | | | CONNECT-RECEIVED state. | +----------------------------------+---------------------------------+ | (DRC) DISCONNECT-REJECT-COMPLETE | NSP has received a Disconnect | | | Complete message while in the | | | DISCONNECT-REJECT state. (The | | | remote port is or has been in | | | the REJECTED state.) | +----------------------------------+---------------------------------+ | (CC) CONNECT-CONFIRM | The local Session Control has | | | issued an ACCEPT call, while | | | the port was in the | | | CONNECT-RECEIVED state. | +----------------------------------+---------------------------------+ | (CI) CONNECT-INITIATE | The local Session Control has | | | issued a CONNECT-XMT call, | | | which created this port. | +----------------------------------+---------------------------------+ | (NR) NO-RESOURCES | NSP has received a No Resources | | | message while in the | | | CONNECT-INITIATE state. (The | | | remote NSP did not have an | | | available port in the OPEN | | | state.) | +----------------------------------+---------------------------------+ | (NC) NO-COMMUNICATION | NSP has received its own | | | Connect Initiate message | | | while in the CONNECT-INITIATE | | | state because Routing was | | | unable to deliver the message. | +----------------------------------+---------------------------------+ | (CD) CONNECT-DELIVERED | NSP has received a Connect | | | Acknowledgment message while in | | | the CONNECT-INITIATE state. | | | (The destination port is or has | | | been in the CONNECT-RECEIVED | | | state.) | +----------------------------------+---------------------------------+ NSP States Page 51 Table 2 (Cont.) Port States +----------------------------------+---------------------------------+ | (Symbol) State | Explanation | |====================================================================| | (RJ) REJECTED | NSP has received a Disconnect | | | Initiate message while in the | | | CONNECT-INITIATE or | | | CONNECT-DELIVERED state. (The | | | remote port is or has been in | | | the DISCONNECT-REJECT state.) | +----------------------------------+---------------------------------+ | (RUN) RUNNING | NSP has either received a | | | Connect Confirm message while | | | in the CONNECT-INITIATE or | | | CONNECT-DELIVERED state or | | | received a Data, Data Request, | | | Interrupt Request, Data | | | Acknowledgment or Other Data | | | Acknowledgment message while in | | | the CONNECT-CONFIRM state. The | | | logical link may be used for | | | sending and receiving data. | | | (Either the remote port is or | | | was in the CONNECT-CONFIRM | | | state or the remote port | | | entered the RUNNING state from | | | the CONNECT-DELIVERED state.) | +----------------------------------+---------------------------------+ | (DI) DISCONNECT-INITIATE | The local Session Control has | | | issued a DISCONNECT-XMT call or | | | an ABORT-XMT call while in the | | | RUNNING state. | +----------------------------------+---------------------------------+ | (DIC) DISCONNECT-COMPLETE | NSP has received either a | | | Disconnect Complete message or | | | a Disconnect Initiate message | | | while in the | | | DISCONNECT-INITIATE state. | | | (The remote port is or has been | | | in either the | | | DISCONNECT-NOTIFICATION state | | | or the DISCONNECT-INITIATE | | | state.) | +----------------------------------+---------------------------------+ | (DN) DISCONNECT-NOTIFICATION | NSP has received a Disconnect | | | Initiate message while in the | | | RUNNING state. (The remote | | | port is or has been in the | | | DISCONNECT-INITIATE state.) | +----------------------------------+---------------------------------+ NSP States Page 52 Table 2 (Cont.) Port States +----------------------------------+---------------------------------+ | (Symbol) State | Explanation | |====================================================================| | (CL) CLOSED | The local Session Control has | | | issued a CLOSE call (normally | | | while the local port was in the | | | DRC, DN, DIC, NC, NR or CI | | | state). This is not really a | | | state of the port, but is used | | | for descriptive purposes to | | | indicate that the port is not | | | there. | +----------------------------------+---------------------------------+ | (CN) CLOSED-NOTIFICATION | NSP has received a No Link | | | message while in the | | | DISCONNECT-INITIATE, | | | DISCONNECT-REJECT, RUN or | | | CONNECT-CONFIRM state. (The | | | remote NSP closed the remote | | | port.) | +----------------------------------+---------------------------------+ NSP States Page 53 Figure 11, following, summarizes the normal port state transitions. These transitions correspond with those in Table 2. .----. .----. .----. .----. | O | | CC |++>|RUN |<++++++++++++++++++++++++++| CD | `----' .->`----'.--`----' `----' + .-' .-' `+++++++++. .+++++++++++++' ^ v .-' v v v + .----.-' .----. .----. .----. .----. + | CR | | DI |++>|DIC | | DN | | RJ | + `----' `----' `----' `----' `----' + | + | | .---' + v v | | | + .----. .----. | .' | .----. .----. | DR |+++++++>| CN | | .-' .-' | NC |<++++++++| CI | `----' `----'-. | .-' .-' `----' .---`----' + `-. | .-' .-' .----' .-----' + v v v v .-' .-' .-' v .----. .----.<-' .-' .-' .----. |DRC |---------------->| CL |<----' .-' | NR | `----' `----'<----------' `----' A | `---------------------------------' LEGEND: .--. | | contains port state (Table 2) `--' ++++> result from an action by NSP ----> result from a Session Control call NOTES 1. A state from which an exit can be made by a ++++> arrow is a potentially unstable state. 2. A state from which the only exits are ----> arrows are stable states. 3. 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 Port State Diagram A transition to CLOSE from any state other than those connected by NSP States Page 54 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 the only kind of transition that can occur that is not shown in Figure 11. 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 (O) state. If 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 CI/O. A logical link can be in only one state at a time. NSP implementations that follow the model in Section 6 will make the transitions correctly. An NSP may fail to associate two ports. This can happen in the following situations: o 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. o If there are no ports managed by the remote NSP in the OPEN state. In this case, NSP places the requesting port in the NO-RESOURCES state. o If the network is not operating properly (e.g. is badly congested) and successive 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 from the CL/DI and DI/CL 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 NSP States Page 55 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. NSP States Page 56 .----. * An exit is made to the CL/CL state from | CI | this state if the port that is still | O | open is closed by Session Control. `----' + v .----. .----. .----. .----. .----.* | CI |<--| CI |-->| CI | | CL |++++>| CL | | CC | | CR | | DR | ,>| DR | | CN | `----' `----' `----' | `----' `----' + + + | + v v v | v .----. .----. .----. | .----.* | CD |<--| CD |-->| CD | | | CL | | CC | | CR | | DR | | | DRC| `----' `----' `----' | `----' + + | ^ v v | | .----. .----. | .----. .----.* |RUN | | RJ |- | RJ |---->| RJ | |CC | | DR |++>|DRC | | CL | `----' `----' `----' `----' + v .----. .----. .----. .----. .----.* |RUN |-->|RUN |+++++++++++>| DN |++++>|DN |-->| DN | |RUN | |DI | | DI | |DIC | | CL | `----' `----' `----' `----' `----' | | | | v v v | .----. .----. .----. .----. | |DI |-->| DI |++>|DIC |-->| CL |++++ | |RUN | | DI | |DI | | DI | + | `----' `----' `----' `----' + | + + + + + | + v v v + | + .----. .----. .----.* + | + |DI |++>|DIC | | CL | + | + |DIC | |DIC | | CN | + | + `----' `----'\ `----' + | + | \ \ + | v v \ \ + v .----. .----. .----. \ \ `>.----.* | DI |-->| DI |++>| CN | \ `-------->|CL | | DN | | CL | | CL | \ |DIC | `----' `----' `----' `--- `----' + + | v + v .----.* .----. +++++++++++++++++>.----.* | CL |<--|DIC |---------------------->|DIC | | DN | |DN | |CL | `----' `----' `----' Figure 12 Logical Link State Diagram NSP States Page 57 LEGEND: .--. | | 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 1. A state from which an exit can be made by a +++++> arrow is a potentially unstable state. 2. A state from which the only exits are -----> arrows are stable states. 3. A state from which an exit can be made by more than one +++++> arrow is a state from which the exit is non-deterministic. 4. 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. 5. If 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 NSP 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 Page 58 5 NSP DATA BASES AND BUFFER POOLS This section specifies the variables and parameters in the data bases and buffer pools described in Section 2.2: o NSP's internal data base (Section 5.1) o Session Control port data base (Section 5.2) o Reserved port data base (Section 5.3) o Node data base (Section 5.4) o Buffer pools (Section 5.5) 5.1 NSP's Internal Data Base This data base contains NSP's internal variables and parameters. Network Management can modify some of these (Section 3.2). Table 3 describes the data base. NSP Data Bases and Buffer Pools Page 59 Table 3 NSP's Internal Data Base +--------------+------------+-----+----------------------------------+ | | Initial |Bit | | | Name | Value |Width| Definition | |====================================================================| | NSPstate | "halted" | 1 | State: "halted" or "running" | |--------------+------------+-----+----------------------------------+ | NSPself | 0 | 16 | The node address of this NSP | |--------------+------------+-----+----------------------------------+ | NSPinact_tim | 0+ | * | NSP's inactivity time value (in | | | | | system-dependent units). 0 means| | | | | "no time value" (Section 7.4). | |--------------+------------+-----+----------------------------------+ | NSPdelay | 2+ | 8 | NSP's "delay factor" (Sect. 6.6) | |--------------+------------+-----+----------------------------------+ | NSPweight | 3+ | 8 | NSP's "round trip delay estima- | | | | | tion factor" (Section 6.6). | |--------------+------------+-----+----------------------------------+ | NSPretrans | 5+ | 8 | NSP's "retransmit threshold" for | | | | | determining confidence in network| | | | | connectivity for a logical link | | | | | (Section 7.5). | |--------------+------------+-----+----------------------------------+ | NSPmax | 0 | * | The maximum number of ports that | | | | | NSP has had simultaneously in a | | | | | state other than OPEN. | |--------------+------------+-----+----------------------------------+ | NSPversion | 4.0 | * | NSP's version number. | |--------------+------------+-----+----------------------------------+ | NSPtotal | * | * | The