DNA FS SESSION CONTROL SECON.RNO [31,1] EDITED 10/17/80 Page 2 1.0 INTRODUCTION This document describes the functions, interfaces, operation, and protocols of Session Control. As part of the DIGITAL Network Architecture (DNA), Session Control models the software that provides system-dependent functions related to creating, maintaining, and destroying logical links. A logical link is a virtual connection between two user-level software modules (end users) in the same node or in different nodes of the same network. DNA is the model on which DECnet implementations are based. A DECnet network is a family of software modules, data bases, hardware components and facilities used to tie DIGITAL systems together for resource sharing, distributed computation or remote system communication. DNA is a layered structure. Modules within each layer perform distinct functions. Modules within a single 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 some other system-dependent method. In this document, interfaces are described in terms of calls to subroutines. This specification describes Phase III Session Control. In Phase II DNA, Session Control was part of the Network Services layer. Phase III DNA, however, logically separates Session Control from Network Services and defines the interface between the newly distinct layers. A glossary at the end of this document defines many Session Control terms. This document assumes that the reader is familiar with computer communications and DECnet. The implementors of DECnet systems compose the primary audience for this document, which may also be of interest to anyone wishing to know details of DECnet structure. The other DNA Phase III functional specifications are: DNA Data Access Protocol (DAP) Functional Specification, Version 5.4.0, Order No. AA-D601B-TC DNA Digital Data Communications Message Protocol (DDCMP) Functional Specification, Version 4.2.0, Order No. AA-D599B-TC DNA Maintenance Operations Protocol (MOP) Functional Specification, Version 2.2.0, Order No. AA-D602B-TC DNA Transport Functional Specification, Version 1.3.0, Order No. AA-J059A-TK DNA Network Management Functional Specification, Version 2.0.0, Order No. AA-J060A-TK DNA Network Services (NSP) Functional Specification, Version 3.2.0, Order No. AA-D600B-TC The DNA General Description (Order No. AA-H202B-TK) provides an overview of the network architecture and an introduction to each of the functional specifications. Page 3 3 BLANKS HERE 1.1 Relation to DIGITAL Network Architecture Figure 1 shows the relationship of Session Control to the DNA hierarchy. Each layer in DNA consists of functional modules and protocols. Generally, modules provide services to the next higher layer and use the services of the next lower layer. The service relationship is reflected in the way the interfaces are modeled as calls to subroutines. Note, however, that the Network Management layer directly interfaces with each of the lower layers. Also, all the layers above Session Control interface directly with it. Modules of the same type in the same layer communicate with each other to provide their services. The rules concerning this communication and the messages required constitute the protocol for those modules. Typically, these messages are exchanged between equivalent modules in different nodes. However, equivalent modules within the same node can also exchange messages. Figure 1 Relation of Session Control to DNA Page 4 2 BLANKS HERE The functional components of Session Control are as follows: User layer. The highest layer, it supports user services and programs. Network Management layer. This 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. Network Application layer. Modules in this layer support network functions, such as remote file access and file transfer, used by the two higher layers. Session Control layer. This layer defines the system-dependent aspects of logical-link communication, which allows messages to be sent from one node to another in a network. Network Services layer. This layer defines the system-independent aspects of logical link communication. Transport layer. Modules in this layer route messages, called packets, between source and destination nodes. Data Link layer. This layer defines the protocol concerning data integrity and physical channel management. Physical Link layer. This 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 communications lines. 1.2 Functional Description The Session Control layer and the Network Services layer work together to make logical links available to end users within a network. End users are modules that reside in the User, Network Application, or Network Management layers (see Figure 1). A logical link is a virtual communication channel that temporarily connects two end users so that they can exchange data. From the perspective of Network Services, each logical link connects two Session Control modules in the same or in different nodes. The purpose of Session Control is to form a bridge between the end users requiring logical link service and Network Services which actually creates, maintains, and destroys logical links. An end user communicates directly with Session Control to request logical link service. The form of this communication, which is the end user interface, varies from one operating system to another. However, the functions that this interface provides an end user, regardless of the local system, include: o Requesting a logical link to an end user o Receiving a logical link request from an end user o Accepting or reject a logical link request o Sending and receive data Page 5 o Terminating a logical link Page 6 1 BLANK HERE These functions are similar to those that Session Control requests from Network Services. In response to requests from end users, Session Control makes parallel requests to Network Services. Unlike the end user interface, however, the Network Services interface is not system-dependent. It is specified in detail (Section 2.1) and standard for all implementations of DNA. Session Control facilitates Network Services by performing the following system-dependent tasks: o Mapping node names to node addresses. A Session Control module maintains a node name mapping table that defines the correspondence between a node name and either a node address or a channel number. (The channel number is used only for loopback testing.) The table enables the Session Control module to select the destination node address or channel number for outgoing connect requests to Network Services. For incoming connect requests from Network Services, the Session Control module uses the table to identify the node from which the request originated. o Identifying end users. A Session Control module executes a system-dependent algorithm to determine if an existing end user corresponds to the destination end user specified in an incoming connect request. It also performs additional functions related to passing a connect request to an existing end user. See Section 5.2. o Validating incoming connect requests. A Session Control module uses access control information included in an incoming connect request to perform system-dependent validation functions. Section 5.0, which discusses Session Control operation in detail, describes how Session Control performs these functions. 1.3 A Session Control Model The model defined by the Session Control layer provides an interface to Network Services for end users that reside in a "user" space created by an operating system. It also provides an interface that can be used by Network Management. The relation to, or interface with, the operating system is system-dependent. Unlike modules that implement other DNA layers, a Session Control module is not self-contained -- it cannot be specified in isolation from non-DECnet modules. Session Control represents the point (or one of the points) at which DECnet is integrated with an operating system. Figure 2 represents a model of Session Control operating within a network node. As the figure shows, Session Control requires two data bases, a node-name mapping data base and a data base that contains the state of Session Control and optional default connection timers. Any other data bases or components required by a Session Control module are system-dependent. Page 7 Figure 2 A Session Control Model Page 8 2.0 SESSION CONTROL INTERFACES Session Control maintains four interfaces between itself and its environment: o Interface to Network Services o Interface to end users o Interface to Network Management o Interface to the resident operating system This section describes the functions of the first three interfaces. The Network Services interface is described first because it is more precisely defined than the end user interface. Furthermore, the end user interface is basically derived from the Network Services interface. The operating system interface is entirely system-dependent and therefore cannot be modeled in this specification. The Network Services and Network Management interface functions are expressed as calls to subroutines in the following format: FUNCTION (input; output) In general, there are two types of subroutines: 1. Those performing a function that is completed immediately. 2. Those queuing a buffer for transmitting or receiving data. For buffer-queuing 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. (See the following section for a definition of a port.) Although not described in the following functions, an invalid port identifier causes an error. NOTE An implementor is not required to code the interfaces as subroutines. The calls specify functions only. 2.1 The Network Services Interface The Network Services interface provides Session Control with logical link service. Using this service, Session Control can create one or more logical links to other Session Control modules in the same network. Network Services uses individual databases called ports to manage the logical links it creates. Network Services and Session Control modules refer to logical links in terms of their associated ports. As a result, many of the functions described below include references to port ids and port states. See Appendix A for a definition of ports and other related terms. Page 9 1 BLANK HERE In the following description of the Network Services interface, the terms "source" and "destination" distinguish the requestor 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 ( ; status) returns: Network Services is halted. Network Services is running; the implementation's minimum receive buffer size is returned This function reads the status of Network Services and obtains a minimum receive buffer size if Network Services is running. This is the one Network Services 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 requestor node address when this node receives a connect request buffer: a buffer to receive incoming connect data returns: port allocated; port identifier returned port not allocated; insufficient resources port not allocated; Network Services halted This function allocates a port in Network Services for receiving a logical link connect request. The source variable and the buffer receive the node address of the requesting node and the incoming connect data, respectively. When the port state indicates an incoming connect request is received, Session Control receives the source node address in the source variable and the incoming data in the buffer. Appendix A describes port states. CLOSE (port id) This function deallocates a port. When a port is closed, Network Services 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 (see Appendix A). Page 10 3 BLANKS HERE CONFIDENCE (port id; confidence) returns: network probably connected network probably disconnected This function obtains Network Services' assessment of connectivity. Network Services periodically tests a logical link once it is formed to ascertain if the network supporting the logical link is connected. The testing determines Network Services' assessment of connectivity. The assessment is not guaranteed to be accurate. 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 obtains the state of a port that is in any state other than CLOSED. Appendix A describes the port states. Because Session Control's operation is not necessarily synchronized with that of Network Services, it is possible that this call will not detect every state transition. This is especially true for state transitions that occur very quickly. However, this is not a problem because the intervening undetected states can be logically deduced as described in Appendix A. CONNECT-XMT (destination, channel, buffer; return) destination: destination node address channel: an internal Network Services mechanism selector used to enable loop testing. Channel is either unspecified (for normal use) or a system-dependent line number representing the line Network Services is to use for its messages establishing this logical link (for Network Management loop tests) buffer: a buffer containing up to 200 bytes of data to be transmitted. returns: port allocated; port id returned port not allocated; insufficient resources port not allocated; Network Services 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 channel 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 channel argument is set to "unspecified." Page 11 3 BLANKS HERE CONNECT-STATUS (port id, buffer; return) returns: connect request accepted by destination; port in RUNNING state connect request rejected by destination; port in REJECTED state port in neither RUNNING nor REJECTED state This function obtains accept or reject data returned as a result of a previous connect request. If the return is one of the first two, Session Control receives any available accept or reject data from Network Services. Once this is done, a Network Services 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 Appendix A). 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, 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 buffer containing up to 18 bytes of reject data. Page 12 3 BLANKS HERE DISCONNECT-XMT (port id, 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 buffer containing up to 18 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 insure that the link will be properly disconnected, not aborted. ABORT-XMT (port id, 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 have received all previously transmitted data before receiving the abort notification. The call supplies a buffer containing up to 18 bytes of abort data. DISCONNECT-RCV (port id, 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. Up to 18 bytes of data may be returned in the buffer. Page 13 3 BLANKS HERE 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 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. Network Services refuses to queue the buffer either if it lacks the resources to do so or if the port is not in the RUNNING state. XMT-POLL (port id; return) returns: no transmit complete transmit complete; buffer descriptor returned This function causes Network Services to notify Session Control whether or not a transmission has completed. If a transmission completed, Network Services 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. Refer to Appendix A. Page 14 3 BLANKS HERE 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 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. Network Services returns receive buffers along with buffer descriptors to Session Control in the order in which data was placed in them. (See the Network Services Functional Specification for further details.) 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. Network Services 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. Page 15 3 BLANKS HERE 2.2 The End User Interface Because the form of Session Control's interface to end users is system-dependent, this specification does not use subroutine calls to model the functions of this interface as it does for the Network Services and Network Management interfaces. In general, however, the functions available at the end user interface are similar to those provided by the Network Services interface. The remainder of this section describes how the end user interface can differ in detail from the Network Services interface. Specifically, the length of some fields may be limited to a value less than that supported by Network Services to allow for the insertion of Session Control header information. In addition, Session Control may accept additional flags or variables at the end user interface. Session Control functions differ from Network Services interface functions in one of two ways: the maximum length of data allowed is different, or additional arguments are possible. Specific instances of the ways in which Session Control and Network interface functions differ are described below. o Node name mapping. The end user refers to nodes by name rather than by address. On outgoing connections, Session Control translates the destination node name into a node address or, in the case of loopback testing, into a channel number. On incoming connections, Session Control translates the source node address into a node name if the node address is in the node name mapping table. Otherwise, no remote node identification is passed to the user. o Opening a port. The function equivalent to opening a Network Services port to receive an incoming request may allow an end user to supply a destination end user name. o Connect data. In a connect request, an end user can supply up to 16 bytes of connect data. This value is less than the amount of connect data that Network Services will accept because Session Control must use some of the connect data it gives to Network Services to contain destination and source end user names as well as access control information. The additional arguments that an end user may pass to Session Control in a connect request are as follows. Section 5.0 explains how these arguments may be used. o Destination end user name o Source end user name o Access control information o One or more "error tolerance" variables o Incoming connect requests. When Session Control delivers an incoming connect request to an end user, it may deliver the destination end user name, the source end user name, and the received access control information, as well as the end user connect data. The maximum amount of end user connect data that Session Control can deliver is 16 bytes. Page 16 1 BLANK HERE o Connect reject or disconnect request data. The maximum amount of data that an end user can include with a connect reject or disconnect request is 16 bytes. Session Control uses the additional 2 bytes available from Network Services for a disconnect or reject reason code. Similarly, the maximum amount of reject or disconnect data that can be delivered to the end user requesting a connection is 16 bytes. o Error tolerance arguments. The function that accepts an incoming connect request may allow the end user to supply one or more "error tolerance" arguments. 2.3 The Network Management Interface Using its interface to Session Control, Network Management can exert control in three ways: 1. It can control and monitor the state of Session Control. 2. It can modify the node name mapping table. 3. It can optionally set and read two Session Control parameters used in handling outgoing and incoming connect requests. In addition, the Network Management Event Logger can monitor the two events logged by Session Control. These events are described in Section 2.3.4. 2.3.1 Session Control States - All Session Control modules support at least two operational states: OFF and ON. Furthermore, a Session Control module may support either or both of two additional states: RESTRICTED and SHUT. Table 1 below defines these states. Table 1 Session Control States State Description OFF Session Control is halted and no logical links are operational. ON Session Control is running and able to provide logical link service. SHUT Session Control is running and supporting existing logical links but it will refuse any new connect requests, either incoming or outgoing. RESTRICTED Session Control is running and supporting existing logical links. It will attempt to initiate new logical links on request (CONNECT-XMT). However, it will not accept any new logical links (ACCEPT) unless the requesting user has sufficient privilege. This determination is system-dependent. Page 17 2 BLANKS HERE Figure 3 below describes the possible transitions from one Session Control state to another. A single arrow represents a transition caused by a Network Management request. A double arrow represents a transition caused either by a Network Management request or by an internal Session Control transition. Figure 3 Session Control State Diagram Because a Session Control module is usually implemented as part of, or closely coupled to, an operating system, its initialization is often coupled to the operating system's initialization and is not modeled in this specification. The state of a Session Control module following such initialization is system-dependent. The calls described below represent Network Management requests to change the state of Session Control. A Session Control module has the option of not supporting any of these calls while it is in the ON state after initialization. OFF ( ; return) returns: success failure This function halts Session Control by changing it to the OFF state. ON ( ; return) returns: success failure This function enables Session Control to provide logical link service by changing its state to ON. Page 18 2 BLANKS HERE SHUT ( ; return) returns: success failure This function changes Session Control's state to SHUT. If a Session Control module accepts the SHUT call, then it moves automatically to the OFF state after the last logical link has disconnected. RESTRICTED ( ; return) returns: success failure This function changes Session Control's state to RESTRICTED. STATUS ( ; state) state: OFF ON SHUT RESTRICTED This function reports the current state of Session Control to Network Management. 2.3.2 Defining the Node Name Mapping Table - Network Management can define entries in the node name mapping table. Each table entry associates a node name with a node address or channel number. Section 4.0 explains how Session Control uses this table. The maximum length of the table is system-dependent, but restrictions that do apply include the following: o No node name can be in the table more than once. o No node address can be in the table more than once. o No channel number can be in the table more than once. Network Management uses the following functions to access Session Control's node name mapping table: ADD-TO-TABLE (name, number; return) name: a node name number: a node address or channel number returns: success failure; the node name, node address, or channel number is already in the table This function adds an entry to the table. The way an implementation distinguishes a node address from a channel number is system-dependent. Page 19 3 BLANKS HERE REMOVE-FROM-TABLE (name; return) name: a node name returns: success failure; the node name is not in the table. This function removes an entry from the node name mapping table. CHANGE-TABLE (name, number; return) name: a node name number a node address or channel number returns: success failure; the node specified is not in the table failure; the node address or channel number is already in the table This function modifies an existing table entry. Network Management can use the function to change the node address or channel number associated with a node name. READ-TABLE (number; return) number: a node address or a channel number returns: the node name mapped to the specified node address or channel number failure; the table does not contain the node address or channel number specified 2.3.3 Default Connection Timers - A Session Control module can optionally have two default values for connection timers: one for incoming connect requests and one for outgoing connect requests. At the option of Session Control, Network Management may set and read the default timer values. Network Management can therefore perform the following functions if Session Control uses the default timer values and also allows Network Management to control them. SET-OUTGOING-TIMER (time; ) time: the default outgoing timer in seconds This function sets a default timer value for outgoing connect requests. Session Control starts a timer when it issues a connect request to Network Services. If the port that Network Services opens for the request does not enter the NO-RESOURCES, NO-COMMUNICATION, REJECTED, or RUNNING state (Appendix A) before the timer expires, Session Control issues a timeout rejection to the end user requesting the connection and Session Control closes the port. Such timer processing is system-dependent. If the end user includes an "error tolerance" argument in the connect request, that argument may override the default timer set by Network Management. Page 20 3 BLANKS HERE READ-OUTGOING-TIMER ( ; time) time: the current default out-going timer in seconds This function reports to Network Management the default value currently set for the outgoing timer. SET-INCOMING-TIMER (time; ) time: the default incoming timer in seconds This function allows Network Management to set Session Control's default incoming timer value. When Session Control receives an incoming connect request, it can optionally start an incoming timer. If the destination end user does not accept or reject the connect request before the timer expires, Session Control issues a connect reject to Network Services, including two bytes of reject data as a reject code (see Section 6.0). Such timer processing is system-dependent. READ-INCOMING-TIMER ( ; time) time: the current default incoming timer in seconds This function reports to Network Management the default value currently set for the incoming timer. 2.3.4 Session Control Events - Network Management can read and clear Session Control's internal event log, which is a queue of event records. The two events logged by Session Control are: o Node State Change. Session Control has changed its state. The new state is logged. o Access Control Failure. Session Control has received a connect request from Network Services which it rejects for access control reasons. The event log records the source node address and all connect request data except the user connect data and password. Page 21 3 BLANKS HERE 3.0 SESSION CONTROL MESSAGES Session Control's message protocol defines messages sent on a logical link as connect data, reject data, and disconnect data. These Session Control messages are described in Sections 3.2 and 3.3 according to the notation described below. This notation is the same as that used in other DIGITAL Network Architecture specifications. 3.1 Message Format Notation The following notation is used to describe the messages contained herein: FIELD (LENGTH) : CODING = description of field where: FIELD the name of the field being described LENGTH the length of the field as: 1. A number meaning number of 8-bit bytes (octets) 2. A number followed by a "B" meaning number of bits 3. The letters "EX-n" meaning extensible field. n is a number that specifies the maximum length of 8-bit bytes in the protocol before interpretation, as described below. If no number is specified, the current maximum length is 1 byte. Extensible fields are variable in length consisting of 8-bit bytes. The high-order bit of each byte indicates whether the next byte is part of the same field. A 1 means the next byte is part of this field. A 0 indicates the next byte is the last byte. The low-order 7-bits of each byte are information bits. Extensible fields can be binary or bit-map. If they are binary, then 7-bits from each byte are concatenated into a single binary field. If they are bit-map, then 7-bits from each byte are used independently or in groups as information bits. NOTE The bit definitions define the information bits after removing the extension bits and compressing the bytes. 4. The letters I-n indicate an image field; n is a number specifying the maximum length of 8-bit bytes in the image. A 1-byte count of the length of the remainder of the field precedes the image. Image fields are variable in length and may be null (count=0). All 8 bits of each byte are information bits. The meaning and interpretation of each image field is defined with that specific field. 5. In addition, the notation *-19 means that the field is not more than 19 bytes long and is defined further along in the message description. Page 22 1 BLANK HERE CODING the representation type used as follows: A 7-bit ASCII B binary BM bit map (each bit or group of bits has independent meaning) C constant null interpretation data dependent CONVENTIONS 1. If both the length and coding are omitted, the field represents a generic field with a number of subfields specified in the description. 2. Any bit or field that is stated to be "reserved" must be zero unless otherwise specified. 3. All numeric values in this section are decimal unless otherwise noted. 4. Bits are numbered with bit 0 on the right (low-order, least-significant bit) and bit 7 on the left (high-order, most-significant bit). For convenience, when the graphic form of a 2-byte field is given, it will be shown converted to a 16-bit word. When a subfield of a message field contains more than one bit, it should be considered a binary value. 5. Unless otherwise specified, the numbers that appear at the top of the message formats represent bit positions. 6. Brackets around a field indicate its presence in a message is optional. 3.2 Connect Data A Connect Data message has the following form: DSTNAME SRCNAME MENUVER RQSTRID PASSWRD ACCOUNT USRDATA DSTNAME (*-19) : Is the destination end user name (see below) SRCNAME (*-19) : Is the source end user name (see below) MENUVER (EX) : BM Is the field format and version information: Bit 0=1 RQSTRID, PASSWRD, ACCOUNT fields included Bit 1=1 USRDATA field included Bits 2-4=0 Reserved Bits 5,6 Is the Session Control version: 0 = Version 1.0 Page 23 1-3 = Reserved Page 24 1 BLANK HERE RQSTRID (I-39) : B Is the source user identification for access verification PASSWRD (I-39) : B Is the access verification password ACCOUNT (I-39) : B Is the link or service account data USRDATA (I-16) : B Is the end user connect data An end user name has the following form: FORMAT OBJTYPE NAME FORMAT (1) : B Is the end user name format: 0 = Format 0 1 = Format 1 2 = Format 2 3-255 = Reserved OBJTYPE (1) : B Is the object type. It may not be 0 for format 0; it must be 0 for formats 1 and 2. For format 0: NAME (null) Is not present For format 1: NAME (I-16) : B Is an end user descriptor For format 2: NAME Is GRPCODE, USRCODE, DESCRPT GRPCODE (2) : B Is a group code USRCODE (2) : B Is a user code DESCRPT (I-12) : B Is an end user descriptor 3.3 Reject and Disconnect Data A Reject or Disconnect message has the following form: REASON DATA-CTL REASON (2) : B a reason code (see Section 6.2) DATA-CTL (I-16) : B user data. The length of this field is ascertained from the total length of reject or disconnect data received from Network Services. It may be null. Page 25 3 BLANKS HERE 4.0 DATA BASES The Session Control model includes two data bases which are described in the following section: o The node name mapping table o The Session Control state and default connection timer table 4.1 The Node Name Mapping Table The node name mapping table defines the correspondence between node names and node addresses or channel numbers. Session Control uses the table to identify either the destination node named in an outgoing connect request or the source node that has sent an incoming connect request. The table should contain an entry for: o Every destination node that an end user will specify to Session Control in an outgoing connect request o For every node likely to send a connect request to Session Control. Network Management defines the table entries and can change, remove, and read existing entries. These functions are described in Section 2.3.2. Section 5.0 describes the mapping table's role in processing incoming and outgoing connect requests. 4.2 The Session Control State and Default Timer Table This table is an internal data base that contains the current state of Session Control and optionally contains default incoming and outgoing connection timers. Network Management can access this table by means of the interface functions described in Sections 2.3.1 and 2.3.3. Section 5.0 explains how Session Control uses the default connection timers if it chooses to implement them. Page 26 3 BLANKS HERE 5.0 SESSION CONTROL OPERATION Session Control performs the following basic operations: o Requests logical link connections on behalf of end users. o Receives connect requests addressed to end users. o Sends and receives logical link data. o Disconnects and aborts logical links. o Optionally monitors logical links. This section describes how the Session Control model performs these operations. 5.1 Requesting a Logical Link Connection Session Control performs four tasks when it receives a logical link connection request from an end user (the source): 1. Identifies the destination node address or channel number. It may use a node name mapping table to identify the destination node address or channel number for Network Services when the end user specifies a node name. A Session Control module also has the option of maintaining an "alias" node name mapping table, which maps an additional set of node names to those entered in the mandatory table. The existence, maintenance, and use (except as just defined) of either a node name mapping table or an alias mapping table is system-dependent. 2. Formats connect data to be passed to Network Services. Section 3.2 describes how Session Control formats a connect data message. How Session Control obtains the destination and source end user names, the access control information, and the end user connect data that make up the message is system-dependent. 3. Issues a connect request to Network Services. If sufficient resources are available, Network Services opens a port for the connection requested by Session Control. The request is unsuccessful if Network Services then places the port in the NO-RESOURCES, NO-COMMUNICATION, or REJECTED state (Appendix A). In this case, Session Control returns information to the source end user indicating that the connect request has failed. The extent to which Session Control gives the end user specific information regarding the failure is system-dependent. The information that Session Control can provide is based on either the port's state if it was NO-RESOURCES or NO-COMMUNICATION or the first two bytes of reject data if the port's state was REJECTED. In the latter case, Session Control must make user reject data, if any, available to the source end user. If Network Services places the port in the RUNNING state, Session Control then indicates to the source end user that the connect request succeeded. Session Control must also make accept data, if any, available to the end user. Page 27 1 BLANK HERE 4. Optionally starts an outgoing connection timer. This timer has the following effect on Session Control's operation. If Network Services does not place the port associated with the request in the NO-RESOURCES, NO-COMMUNICATION, REJECTED, or RUNNING state before the timer expires, Session Control returns a timeout rejection to the source end user and closes the port. As stated previously, the outgoing connection timer is optional and timer processing is system-dependent. If a Session Control module chooses to use the default timer and supports the SET-OUTGOING-TIMER function described in Section 2.3.3, the default timer value is that most recently set by Network Management. Session Control may also allow the end user to provide its own timer value in an "error tolerance" argument included in its connect request. Such an argument overrides the default value set by Network Management. 5.2 Receiving a Connect Request Session Control maintains one or more ports in the OPEN state in order to detect incoming connect requests. (See the Network Services interface OPEN function, described in Section 2.1.) Network Services notifies Session Control of an incoming request by changing the state of one of these ports to CONNECT-RECEIVED. When Session Control detects the port's new state (using the STATE function, Section 2.1), it performs the following six tasks: 1. Obtains data for the incoming connect request. It obtains the destination end user name, source end user name, access control information, and end user connect data for the incoming connect request. Session Control obtains this information by parsing the connect data received from Network Services, which is formatted according to the message protocol described in Section 3.2. 2. Validates access control information. It validates the access control information in a system-dependent manner. For example, one Session Control module may log the logical link onto the local system. Another Session Control module may perform no validation of its own and pass the information directly to the end user for validation. These are only examples; there are no restrictions on how to process access control information. 3. Identifies, creates, or activates the destination end user. It either maps the destination end user name to an existing end user or creates or activates a destination end user to receive the connect request. A destination end user name is in one of two forms: o A system-dependent name, indicated by a zero (0) object type. The name itself consists of a sequence of bytes interpreted in a system-dependent way by the destination Session Control module. o A system-independent service, indicated by a non-zero object type (a one-byte number) and no name. Page 28 1 BLANK HERE To identify the destination end user, Session Control executes a system-dependent algorithm. The destination end user name and/or the access control information received in the connect data may be inputs to the algorithm. Executing the algorithm may result in one of the following outcomes: o The destination end user exists and can receive a new connect request. o The destination end user exists but cannot receive a new connect request (for example, its "mailbox" queue may be full or it may already be using its maximum number of "network logical units"). o The destination end user does not exist. In this case, Session Control can optionally create or activate an end user to receive the connect request. How Session Control activates or creates the end user is system-dependent. If Session Control cannot identify, create, or activate a destination end user, it issues a REJECT to Network Services, including two bytes of reject data (see Section 6.0). 4. Maps the source node's address or channel number to a node name. After identifying, creating, or activating a destination end user, Session Control uses a node name mapping table to map the source node's address or channel number to a node name. If Session Control cannot find an entry that corresponds to the source node's address or channel number, it identifies the source node as "unknown." 5. Delivers the incoming connect request to the end user. If Session Control has identified, created, or activated a destination end user, it delivers the incoming connect request to the end user in a system-dependent way. Session Control also delivers information that identifies the source node of the connect request. The form that this information takes is system-dependent, but it may be one of the following: the source node's name, the node identification "unknown," or a channel number. If the end user accepts the connection, Session Control issues an ACCEPT to Network Services and passes along any user accept data (up to 16 bytes). If the end user rejects the connection, Session Control issues a REJECT to Network Services, including a two-byte reject code (see Section 6.0) and up to 16 bytes of reject data, if the destination end user supplied any. 6. Optionally starts an incoming connection timer. It can optionally start an incoming connection timer when it makes the connect request available to the destination end user. If the end user does not accept or reject the connect request before the timer elapses, Session Control issues a reject to Network Services, including two bytes of reject data (see Section 6.0). Such timer processing is system-dependent. However, if a Session Control module uses such a timer and supports the SET-INCOMING-TIMER function described in Section 2.3.3, the value of the incoming connect timer is the default value most recently set by Network Management. Page 29 3 BLANKS HERE 5.3 Sending and Receiving Data Because the interface between end users and Session Control is system-dependent, Session Control can handle requests to send and receive data in several ways. Section 5.3.1 describes two data buffering models and Section 5.3.2 describes three possible data transfer interfaces. 5.3.1 Data Buffering Models - The two models described are the end user buffering model and the Session Control buffering model. The End User Buffering Model -- This model is characterized as follows: 1. When an end user transmits a buffer of data, Session Control temporarily receives ownership of the buffer. To the end user, it appears that the data is being transmitted directly out of the buffer -- while Session Control "owns" the buffer, the end user cannot modify the data without nullifying the guarantees of data integrity. To regain buffer ownership, the end user polls Session Control for a "transmit complete." 2. When an end user supplies a buffer to receive data, Session Control temporarily receives ownership of the buffer. To the end user, it appears that the data is being received directly into the buffer. As also applies to a transmit buffer, the end user cannot modify the buffer while Session Control owns it without nullifying the guarantees of data integrity. To regain ownership of the buffer and to receive the data it contains, the end user polls Session Control for a "receive complete." The Session Control Buffering Model -- This model is characterized as follows: 1. When an end user attempts to transmit a buffer of data, Session Control either accepts or rejects the transmit request. If Session Control accepts the request, the data in the transmit buffer appears to have been moved to a Session Control transmit buffer while the request was being processed. The end user does not need to poll Session Control to regain ownership of the buffer nor can it in any way nullify the guarantee of data integrity. 2. When an end user supplies a receive buffer, Session Control either returns the buffer empty with a "no data" indication or returns the buffer with data and a "data returned" indication. If data is returned, it appears to the end user that the data was moved into the buffer from a Session Control receive buffer while the receive request was being processed. The end user does not need to poll Session Control to regain ownership of the buffer nor can it in any way nullify the guarantee of data integrity. 5.3.2 Data Transfer Interfaces - A Session Control module sends and receives data via one of three data transfer interfaces: message, segment, or stream. Page 30 1 BLANK HERE 1. The Message Interface. This interface, which is unconcerned with network packet size, allows an end user to send or receive a large amount of information. On transmission, Session Control uses Network Services' DATA-XMT function with "xmtflag" set to "end-of-message" to send the entire buffer of end user data. To receive data via the message interface, the end user passes a receive buffer to Session Control. In turn, Session Control uses the DATA-RCV function with "rcvflag" set to "truncation allowed" to pass the buffer to Network Services. If the receive buffer is smaller than the corresponding transmit buffer, the transmitted data that overflows the receive buffer is lost. Session Control can use either of the buffering models described above to operate the message interface. 2. The Segment Interface. This interface ensures that a receiving end user never loses any information from data truncation. Using the segment interface, an end user sends and receives data in buffers that correspond to Network Services packets. In other words, a transmitting end user cannot send a buffer larger than the packet size, and a receiving end user cannot provide a buffer smaller than the packet size. When transmitting data, an end user provides the "xmtflag" value that Session Control passes to Network Services. When an end user makes a request to receive data, Session Control sets "rcvflag" to "no truncation allowed". In addition, an end user has access to a function that returns the segment (that is, Network Services packet) size. Session Control can use either of the buffering models described above to operate the segment interface. 3. The Stream Interface. When using this interface, an end user views the data it sends and receives as a sequence (that is, stream) of bytes, words, and so on, occasionally separated by an "end-of-message" marker. The stream interface is basically the same as the segment interface except that the size of the Network Services packet does not restrict the size of end user transmit or receive buffers. Transmit buffers can be larger than the packet size and receive buffers can be smaller than the packet size. Session Control must use the Session Control buffering model to operate the stream interface. 5.4 Disconnecting and Aborting a Logical Link This section describes the Session Control models for sending a disconnect or abort request and receiving a disconnect or abort request. Page 31 1 BLANK HERE 1. Sending disconnect or abort requests. When an end user instructs Session Control to disconnect or abort a logical link, Session Control issues either a DISCONNECT-XMT or an ABORT-XMT call, respectively, to Network Services. Either call passes a two-byte disconnect code (see Section 6.0) and up to 16 bytes of disconnect data if the requesting end user supplied any. After requesting a disconnection or abort, Session Control may continue to provide receive buffers until Network Services places the appropriate port in the DISCONNECT-INITIATE-COMPLETE state. Upon detection of this state, Session Control closes the port. Because Network Services does not guarantee to complete a disconnect or an abort within a bounded period of time, Session Control can optionally start a timer when it issues its request. If Network Services does not place the relevant port in the DISCONNECT-INITIATE-COMPLETE state before the timer elapses, Session Control closes the port. The timer value may be a default or it may be an "error tolerance" argument provided by an end user in a connect request or connect accept function (see Section 2.2). Depending on the system, Session Control may or may not return completion status to the end user that requested the disconnection or abort. 2. Receiving a disconnect or abort request. When a Session Control module has issued a DISCONNECT-XMT or an ABORT-XMT to Network Services, Network Services forwards the request to a destination Network Services module. The destination Network Services then places the appropriate port in the DISCONNECT-NOTIFICATION state. In turn, the destination Session Control module detects the state of the port, obtains disconnect data from Network Services, and closes the port. The first two bytes of the disconnect data constitute a reason code for the disconnection. How Session Control interprets the reason code depends on the type of node in which the end user that requested the disconnection resides: o If the node is a Phase III system, the first two bytes of disconnect data equal either 0 (zero) or 9. Zero indicates a disconnect request from the remote end user; 9 indicates an abort request from the remote end user. o If the node is a Phase II system, the two bytes may equal zero, which indicates a disconnect request, or they may be nonzero, which indicates an abnormal disconnection. It depends on the system whether or not Session Control supplies the destination end user with additional information about the reason for an abnormal disconnection. Page 32 3 BLANKS HERE 5.5 Monitoring a Logical Link A Session Control module can optionally monitor a logical link in a system-dependent manner. The purpose of such monitoring would be to detect the probable disconnection of the network between the nodes at either end of a logical link or the failure of Network Services to deliver transmitted data in a timely fashion. How Session Control performs this optional function, is system-dependent. Furthermore, the information that a Session Control module uses to monitor a link is also system-dependent. End users might be able to control logical link monitoring by supplying an error tolerance variable in a connect request or connect accept issued to Session Control (see Section 2.2). One possible monitoring operation is described below: Example of Monitoring Operation: Session Control can monitor the confidence variable for a logical link. The confidence variable is Network Services' assessment of a logical link's connectivity, that is, whether the network supporting the logical link is connected. (See the CONFIDENCE function, described in Section 2.1.) If the variable is false, indicating a probable disconnection of the network, Session Control can start a timer, either a default value or a user-supplied "error tolerance" variable. If the confidence variable does not return to true before the timer expires, Session Control can close the port associated with the logical link. Page 33 3 BLANKS HERE 6.0 ERROR CODES This section describes the types of errors that Session Control returns to end users and to other Session Control modules. o Errors that Session Control returns to end users are described in Section 6.1. o Errors that one Session Control module sends to another in the REASON field of a disconnect or reject message (Section 3.3) are described in Section 6.2. NOTE The term "object," which appears in several of the error descriptions below, means end user. 6.1 Error Codes Returned to End Users The error code numbers and corresponding reasons (capitalized phrases) given below are standard for all implementations of Session Control. Every implementation of Session Control can generate error codes 0, 4, 5, 6, 9, and 34. Two error codes (0 and 38) have two reasons for the same code number. In these cases, the state of the logical link, as perceived by the user, determines which reason (and therefore which phrase) applies to the error. The following description groups the errors into two categories: o Errors returned in response to a connect request o Errors returned with a disconnect notification. Connect request errors: Code Number Reason 0 REJECTED BY OBJECT The destination end user rejected a connect request. 1 NETWORK RESOURCES No resources are available for a new logical link. (The missing resources may be in the local or in the remote system.) 2 UNRECOGNIZED NODE NAME The destination node name specified in a connect request cannot be translated -- the node name mapping table does not contain a corresponding entry. 3 REMOTE NODE SHUT DOWN The destination Session Control is in the SHUT or RESTRICTED state (Section 2.3.1) and therefore cannot handle incoming connect requests. Page 34 1 BLANK HERE 4 UNRECOGNIZED OBJECT The destination end user specified in a connect request does not exist. 5 INVALID OBJECT NAME FORMAT The specification of the destination end user in a connect request was not in correct object name format. (This error is returned only in those systems in which the source end user can control the format of the destination process name.) 6 OBJECT TOO BUSY The destination end user does not have sufficient resources to handle a new logical link. 10 INVALID NODE NAME FORMAT The destination node name in a connect request had an invalid format. 11 LOCAL NODE SHUT DOWN The local Session Control is in the OFF or SHUT state (Section 2.3.1) and therefore cannot handle outgoing connect requests. (Some implementations may return this reason only in the SHUT state if Session Control is unavailable in the OFF state.) 34 ACCESS CONTROL REJECTION The access control information in a connect request was invalid and therefore rejected by the destination Session Control. 38 NO RESPONSE FROM OBJECT The destination end user did not respond to a connect request. (It may have received the connect request but crashed before accepting or rejecting it.) 39 NODE UNREACHABLE The node to which a connect request has been sent is unreachable. Disconnect notification errors: Code Number Reason 0 DISCONNECT BY OBJECT The end user disconnected a running logical link. 8 ABORT BY MANAGEMENT The logical link was disconnected by third party (by a party other than the communicating end user). Page 35 1 BLANK HERE 9 ABORT BY OBJECT The remote end user has aborted the link. 38 NODE OR OBJECT FAILED A third party has aborted the link; or the end user or node at the opposite end of the link has crashed. 6.2 Reject and Disconnect Data Error Codes A Session Control module specifies one of the codes defined below in the REASON field of a reject or disconnect data message. The REASON field consists of the first two bytes of the data. The codes are decimal. Table 2 below shows the correspondence between the Session Control to Session Control error codes described in this section and the error codes Session Control returns to end users, described in Section 6.1. Code Number Reason 0 No error. 3 The node is shutting down. 4 The destination end user does not exist. 5 A connect request contained an invalid destination end user name. 6 The destination end user does not have sufficient resources to handle a new logical link. 7 Unspecified error. 8 A third party (that is, a process other than either end user) has aborted the logical link. 9 An end user has aborted the logical link. 32 The node does not have sufficient resources to handle a new logical link. 33 The destination end user does not have sufficient resources to handle a new logical link. 34 A connect request contained an unacceptable RQSTRID or PASSWORD field; Session Control therefore rejected the request. 36 A connect request contained unacceptable ACCOUNT information. The requesting end user is not authorized or the account balance is unacceptable. 38 The end user has aborted, timed out, or cancelled a connect request. 43 The image data field (RQSTRID, PASSWORD, ACCOUNT, USRDATA) of Page 36 a connect data message was too long. Page 37 2 BLANKS HERE Table 2 Session Control to Session Control Codes Mapped to Session Control to End User Codes Session Control Session Control to to Session Control End User Reject codes: 0 0 3 3 4 4 5 5 6 6 34,36,43 34 38 38 Disconnect or abort codes: 0 0 8 8 9 9 38 38 Page 38 APPENDIX A PORT AND LOGICAL LINK STATES Ports and port states are important factors in Session Control's interface to Network Services. This appendix explains what ports are and defines the states that Network Services can assign to them. For more detailed information on this subject, refer to the DNA Network Services Functional Specification. A.1 PORTS Every logical link set up by Network Services is distinguishable from all other links. To differentiate one link from another, Network Services assigns a port to each logical link it sets up, where a port is a space in memory (generally in a dedicated or shared pool) that contains control variables for managing the link. Each node within a network has a number of available ports, which are allocated and controlled by Network Services. Because each end of a logical link has its own port, the creation of a link can be thought of as the association of one port with another. Session Control asks Network Services to allocate or "open" a port when it receives an end user request for a logical link or when it needs a port open to receive an incoming connect request. If sufficient resources are available, Network Services opens a port as requested. When Session Control closes a port, Network Services deallocates the port's resources. Network Services also maintains a "confidence" variable in each port that has been opened. Session Control can access this variable, which is useful in detecting network failures. A.2 PORT STATES At any given time, each end or port of a logical link is in a particular state, which is determined by Session Control requests and Network Services messages pertaining to the link. The possible states at the ends of a link are called port states. The state that Network Services associates with a port is represented by a variable in the port data base. Table 3 below defines all the possible port states. At any time, a port is in only one state. Page 39 2 BLANKS HERE Table 3 Port States (Symbol) State Explanation (O) OPEN The local Session Control has issued an OPEN call which allocated the port. (CR) CONNECT-RECEIVED NSP has received a Connect Initiate message. (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 does 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 Transport was unable to deliver the message. (CD) CONNECT-DELIVERED NSP has received a Connect Acknowledgment message while in the CONNECT-INITIATE state. (A destination port is or has been in the CONNECT-RECEIVED state.) (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.) (continued on next page) Page 40 1 blank here Table 3 (Cont.) Port States (Symbol) State Explanation (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. (DI) DISCONNECT-INITIATE The local Session Control has issued a DISCONNECT-XMT 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.) (CL) CLOSED The local Session Control has issued a CLOSE call 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 or DISCONNECT-REJECT state. (The remote NSP closed the remote port.) Page 41 2 blanks here Figure 4 below summarizes the normal port state transitions. These transitions correspond to those described in Table 3 above. Figure 4 Port State Diagram A.3 LOGICAL LINK STATES At any given time, a logical link is also associated with a particular state, which is determined by the combination of possible port states at each end of the link. The product of the two sets of port states is called the logical link state. When one Session Control module attempts to form a connection to a second Session Control module, Network Services places the requesting port in the CONNECT-INITIATE (CI) state. Network Services then attempts to assocate the source, local port with a destination port that is in the OPEN (O) state. If the association between the two ports is successful, a logical link exists and its initial state is CI/O. Page 42 1 blank here Figure 5 below shows the normal logical link state transitions. At any time, a logical link can be in only one state. Figure 5 Logical Link State Diagram Page 43 APPENDIX B OBJECT TYPES The object type code values that have been defined are listed below. The numbers listed are decimal. Object Type Process Type 0 General task, user process 1 File access (FAL/DAP-Version 1) 2 Unit Record Service (URDs) 3 Application Terminal Services (ATS) 4 Command Terminal Services (CTS) 5 RSX-11M Task Control-Version 1 6 Operator Services Interface 7 Node Resource Manager 8 IBM 3270-BSC Gateway 9 IBM 2780-BSC Gateway 10 IBM 3790-SDLC Gateway 11 TPS Application 12 RT-11 DIBOL Application 13 TOPS-20 Terminal Handler 14 TOPS-20 Remote Spooler 15 RSX-11M Task Control-Version 2 16 TLK Utility 17 File Access (FAL/DAP-Version 4 and any subsequent version) 18 RSX-11S Remote Task Loader 19 NICE Process Page 44 1 blank here Object Type Process Type 20 RSTS/E Media Transfer Program (NETCPY) 21 RSTS/E Homogeneous Network Command Terminal Handler 22 Mail Listener (DECnet-based electronic mail system) 23 Host Terminal Handler 24 Concentrator Terminal Handler 25 Loopback Mirror 26 Event Receiver 27 VAX/VMS Personal Message Utility 28 FTS Page 45 GLOSSARY confidence A Network Services variable (CONFIDENCE) that indicates the probable connectedness of the physical network supporting a logical link. See Sections 2.1 and 5.5. end user A module that runs in the "user space" of a network node and communicates with Session Control to obtain logical link service. In relation to the DNA hierarchy, an end user module resides in the User, Network Application, or Network Management layer. incoming connection timer A timer that Session Control can optionally start when it receives an incoming connect request. If the timer (measured in seconds) expires before the destination end user responds, Session Control issues a connect reject to Network Services. See Section 2.3.3. logical link A virtual channel between two end users in the same node or in separate nodes. Session Control acts as an interface between an end user requiring logical link service and Network Services which actually creates, maintains, and destroys logical links. See Section 1.2. Network Management The DNA layer that enables operator control over and observation of network parameters and variables. Network Management also provides down-line loading, up-line dumping, and testing functions. Network Services (NSP) The DNA layer immediately below Session Control which enables the creation, maintenance, and destruction of logical links, and which performs data flow control and end-to-end error control, and which segments and reassembles messages sent across the logical links. node name mapping table A table that defines the correspondence between node names and node addresses or channel numbers. Session Control uses the table to identify destination nodes for outgoing connect requests and source nodes for incoming connect requests. See Sections 2.3.2 and 4.1. Page 46 1 blank here outgoing connection timer A timer that Session Control can optionally start when it issues a connect request to Network Services. If the port associated with the request does not enter one of four specific states before the timer expires, Session Control issues a timeout rejection to the requesting end user and asks Network Services to close the port. See Section 2.3.3. port A collection of control variables and parameters for managing logical links. Each logical link has a port at each end. Each Network Services at each node has a number of available ports. When Session Control requests a logical link or requests a port be opened to receive an incoming connect request, NSP allocates a port if sufficient resources are available. See Sections 1.2.1 and 1.2.2 and Appendix A. Session Control The DNA layer directly above NSP. Session Control defines the system-dependent aspects of logical link communication. Session Control provides functions such as name-to-address translation, process addressing, and in some systems, access control. Transport The DNA layer directly below NSP that provides NSP with routing, congestion control, and packet lifetime control services.