    Network Working Group                                        A. Bogdanov
    Request for Comments: 3018                                     NKO "ORS"
    Category: Experimental                                     December 2000

                  Unified Memory Space Protocol Specification

    Status of this Memo

       This memo defines an Experimental Protocol for the Internet
       community.  It does not specify an Internet standard of any kind.
       Discussion and suggestions for improvement are requested.
       Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2000).  All Rights Reserved.

    Abstract

       This document specifies Unified Memory Space Protocol (UMSP), which
       gives a capability of immediate access to memory of the remote nodes.

    Conventions used in this document

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC-2119 [2].

       The following syntax specification uses the augmented Backus-Naur
       Form (ABNF) as described in RFC-2234 [3].

    Table of Contents

       1.  Introduction...................................................4
       2.  The UMSP Model.................................................5
         2.1  128-bit Address Space.......................................5
         2.2  Computing Model.............................................7
         2.3  System Architecture.........................................9
       3.  Instruction Format............................................11
         3.1  Instruction Header.........................................12
         3.2  Extension Headers..........................................15
         3.3  Instruction Operands.......................................17
         3.4  Address Formats............................................17
       4.  Response of the Instructions..................................19
         4.1  RSP, RSP_P.................................................20
         4.2  SND_CANCEL.................................................20
       5.  Jobs Management...............................................21

    Bogdanov                      Experimental                      [Page 1]

    RFC 3018             Unified Memory Space Protocol         December 2000

         5.1  Job Initiate...............................................23
           5.1.1  CONTROL_REQ............................................24
           5.1.2  CONTROL_CONFIRM........................................25
           5.1.3  CONTROL_REJECT.........................................26
         5.2  Task Initiate..............................................26
           5.2.1  TASK_REG...............................................26
           5.2.2  TASK_CONFIRM...........................................27
           5.2.3  TASK_REJECT............................................28
           5.2.4  TASK_CHK...............................................28
         5.3  Establishment of session connection........................29
           5.3.1  SESSION_OPEN...........................................29
           5.3.2  SESSION_ACCEPT.........................................31
           5.3.3  SESSION_REJECT.........................................31
           5.3.4  Connection Profile.....................................32
         5.4  Session Closing............................................33
           5.4.1  SESSION_CLOSE..........................................34
           5.4.2  SESSION_ABEND..........................................35
         5.5  Task Termination...........................................35
           5.5.1  TASK_TERMINATE.........................................36
           5.5.2  TASK_TERMINATE_INFO....................................36
         5.6  Job Completion.............................................37
           5.6.1  JOB_COMPLETED..........................................37
           5.6.2  JOB_COMPLETED_INFO.....................................38
         5.7  Activity Control of Nodes..................................38
           5.7.1  _INACTION_TIME.........................................39
           5.7.2  STATE_REQ..............................................40
           5.7.3  TASK_STATE.............................................41
           5.7.4  NODE_RELOAD............................................42
         5.8  Work without session connection............................42
       6.  Instructions of Exchange between VM...........................44
         6.1  Data Reading/Writing Instructions..........................45
           6.1.1  REQ_DATA...............................................45
           6.1.2  DATA...................................................46
           6.1.3  WRITE..................................................46
           6.1.4  WRITE_EXT..............................................47
         6.2  Comparison Instructions....................................47
           6.2.1  CMP....................................................47
           6.2.2  CMP_EXT................................................48
           6.2.3  Response to Comparison Instructions....................48
         6.3  Control Transfer Instructions..............................48
           6.3.1  JUMP, CALL.............................................48
           6.3.2  RETURN.................................................49
         6.4  Memory Control Instructions................................50
           6.4.1  MEM_ALLOC..............................................50
           6.4.2  MVCODE.................................................50
           6.4.3  ADDRESS................................................51
           6.4.4  FREE...................................................51
           6.4.5  MVRUN..................................................51

    Bogdanov                      Experimental                      [Page 2]

    RFC 3018             Unified Memory Space Protocol         December 2000

         6.5  Other Instructions.........................................52
           6.5.1  SYN....................................................52
           6.5.2  NOP....................................................53
         6.6  Work with Objects..........................................53
           6.6.1  Reading/Writing of the Objects Data....................54
             6.6.1.1  OBJ_REQ_DATA.......................................54
             6.6.1.2  OBJ_WRITE..........................................55
             6.6.1.3  OBJ_WRITE_EXT......................................56
           6.6.2  Comparison Instructions of the Objects Data............56
             6.6.2.1  OBJ_DATA_CMP.......................................56
             6.6.2.2  OBJ_DATA_CMP_EXT...................................57
           6.6.3  Execution of the Objects Procedures....................57
             6.6.3.1  CALL_BNUM..........................................57
             6.6.3.2  CALL_BNAME.........................................58
             6.6.3.3  GET_NUM_PROC.......................................59
             6.6.3.4  PROC_NUM...........................................59
           6.6.4  The Objects Creation...................................59
             6.6.4.1  NEW, SYS_NEW.......................................60
             6.6.4.2  OBJECT.............................................61
             6.6.4.3  DELETE.............................................61
           6.6.5  The Objects Identification.............................61
             6.6.5.1  OBJ_SEEK...........................................62
             6.6.5.2  OBJ_GET_NAME.......................................62
       7.  Chains........................................................62
         7.1  Sequence...................................................63
         7.2  Transaction................................................64
           7.2.1  _BEGIN_TR..............................................64
           7.2.2  EXEC_TR................................................65
           7.2.3  CANCEL_TR..............................................66
         7.3  Fragmented instruction.....................................66
         7.4  Buffering..................................................67
         7.5  Acknowledgement of chains..................................69
         7.6  Base-displacement Addressing...............................70
       8.  Extension Headers.............................................71
         8.1  _ALIGNMENT.................................................71
         8.2  _MSG.......................................................71
         8.3  _NAME......................................................72
         8.4  _DATA......................................................72
         8.5  _LIFE_TIME.................................................72
       9.  Search of resources...........................................73
         9.1  VM_REQ.....................................................75
         9.2  VM_NOTIF...................................................75
       10.  Security Consideration.......................................77
       11.  Used Abbreviations...........................................78
       12.  References...................................................79
       13.  Author's Address.............................................80
       14.  Full Copyright Statement.....................................81

    Bogdanov                      Experimental                      [Page 3]

    RFC 3018             Unified Memory Space Protocol         December 2000

    1  Introduction

       UMSP is the network connection-oriented protocol.  It corresponds to
       session and presentation layers of model OSI.  The protocol is
       designed for implementation in a wide class of systems, from simple
       devices based on the dedicated processors, up to universal computers
       and clusters.

       For the data exchange, the protocol uses transport layer service with
       reliable delivery.  It is possible to use not providing reliable
       delivery protocol for the transmission of not requiring
       acknowledgement data.  This document describes use TCP and UDP.

       The creation of network environment for the organization 128-bit
       address space of memory distributed between Internet nodes is the
       basic purpose of the protocol UMSP.  The protocol defines algorithm
       of the connections management and format of network primitives.  It
       doesn't control local memory on the node.

       As against the traditional network protocols, the user applications
       on different nodes interact not by the network primitives exchanging
       or working with the dataflows, but by immediate data reading/write or
       control transfers to the code in virtual memory of the remote node.
       The user's application can know nothing about existence of the
       protocol and network, and simply use the instructions with 128-bit
       addresses.

       Firstly, it is supposed to use UMSP in systems based on the virtual
       machines (VM), executing the pseudo-code.  However, the protocol may
       be used in systems executing a processor code, for example, in
       clusters or in universal operational systems, for the organization of
       the distributed virtual address space.  Besides, the minimal profile
       of the protocol may be used in simple devices, which do not have the
       operational system.

       The protocol gives various means for set the connection parameters
       and allows building systems with a high protection level without
       restriction applications functionalities.

       UMSP can essentially simplify the distributed systems development
       process.  It gives an opportunity to unite not only information, but
       also calculating resources of the large number of polytypic computers
       without significant expenses for the programs standardization and
       development.

    Bogdanov                      Experimental                      [Page 4]

    RFC 3018             Unified Memory Space Protocol         December 2000

    2  The UMSP Model

    2.1  128-bit Address Space

       UMSP is based on the 128-bit distributed address memory space model.
       The 128-bit address contains the information about the network type,
       network node address and local memory address.  It has the following
       format:

       Octets
        0      1                                                    16
       +------+--------------+--------------------+----------------+
       |Header|     FREE     |     NODE_ADDR      |    MEM_ADDR    |
       +------+--------------+--------------------+----------------+

       Complete address length is fixed and is equal to 16 octets.

       Header

          1 octet.  Address header field completely defines the address
          format.  The header has the following format:

          Bits
           0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |      ADDR_LENGTH      |  NET_TYPE | ADDR_CODE |
          +-----+-----+-----+-----+-----+-----+-----+-----+

          ADDR_LENGTH

             4 bits.  The length of the network address.  This field
             contains the number of octets in the NODE_ADDR field.  The
             value 0 is not allowed.

          NET_TYPE

             2 bits.  The network type.  This field specifies a type of
             network, in which the node is.

          ADDR_CODE

             2 bits.  The length code of the local memory address.  The
             value of this field specifies the length of the local memory
             address.  The following values of the field and appropriated to
             them length of the field MEM_ADDR are defined:

    Bogdanov                      Experimental                      [Page 5]

    RFC 3018             Unified Memory Space Protocol         December 2000

                %b00 - 16 bit
                %b01 - 24 bit
                %b10 - 32 bit
                %b11 - 64 bit

          The values combination of the three fields of heading is named
          address format number.  These fields unequivocally define a
          network, in which the node is located.  Format number writes as
          follows:

             N <ADDR_LENGTH> - <NET_TYPE> - <ADDR_CODE>

          For example, N 4-0-2 defines the address with length of the node
          network address 4 octets and memory address with the length 32
          bits.  The network type 0 for such address format is defined for
          the network IPv4 in the presented document.  If the network type
          is equal to zero, it may be missed during the writing of the
          address format number.  For example, format N 4-0-2 and 4-2 are
          equivalent.  If both fields NET_TYPE and ADDR_CODE are set to
          zero, they may be omitted.  Thus, a format number writes as one
          figure.

          One or several address format numbers must be assigned for each
          global network, included in unified system.

       FREE

          0 - 12 octets.  This field is unused by the protocol.  It may
          contain any additional information, which is necessary for the
          control system of the node memory.  If this field is not used, the
          zero value must be set in all octets.  Using of this field results
          that the network instructions must contain only complete 16 -
          octet address and the short address of local memory cannot be
          used.

       NODE_ADDR

          1 - 13 octets.  The node address.  The format of this field is
          defined separately for each address format number.  The field of
          the node address should not necessary precisely correspond to the
          real network address.  If the real network address is longer than
          this field, it is necessary to organize in the network a subset of
          supporting the protocol UMSP addresses.

    Bogdanov                      Experimental                      [Page 6]

    RFC 3018             Unified Memory Space Protocol         December 2000

       MEM_ADDR

          16/24/32/64 bits.  The address of local memory.  This field is the
          memory address in system, which is set by a field NODE_ADDR.  The
          node completely responds for its memory control.  The protocol
          does not define the order of using and format of this field.

       128-bit address for the user applications is one field.  The user
       code cannot know about a physical arrangement of addressed memory.

       The 128-bit memory address may be transmits between nodes, as the
       data, for example, in the buffer of function parameters, or in the
       instruction of copying the data.  Therefore, it must identify the
       given node from any other nodes unequivocal.

       Any certain algorithm, connecting real network and 128-bit address,
       does not exist.  All used address formats must be known beforehand.

       As UMSP has its own address space, it can unite several global
       networks.  The nodes can have internal local networks or subordinated
       addressable devices connected with the node by the not-network
       communications.  Any node by address format number must have an
       opportunity to define the gateway respond for routing of this
       address.

    2.2  Computing Model

       Computing model is three-layer:

          (1) Job
          (2) Task
          (3) Thread of control

       The job corresponds to the user application.  The job is distributed
       and can simultaneously be executed on many nodes.  The job control is
       carried out centralize, from the node named as Job Control Point
       (JCP).  One JCP can control the some jobs.  JCP can be located on the
       same node, on which the job is created, or on any other addressed net
       point.

       The task is the job presentation on the separate node.  The task
       includes one or several computing threads of control.  The job has
       only one task on each node.

       The job is finished, when the appropriate user application is
       finished.  At the end of the job all tasks of this job on all nodes
       are finished.

    Bogdanov                      Experimental                      [Page 7]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The job has its isolated 128-bit address space.  The address space is
       segmented.  A segment is the local memory of one node.  Besides, the
       protocol allows working with objects.  The objects are separate
       associative memory of the node.

       The task thread represents the concrete control thread, which are
       executed by VM in the certain node.  The thread can read and write to
       any address of 128-bit address space of the job.  The control
       transfer to the address from other (remote) node, results to the
       creation of the new thread on the remote node.  The continuous code
       segment cannot be distributed on several nodes.  In addition, it is
       impossible to receive continuous memory area distributed on several
       nodes.

       The protocol does not demand to support the different tasks of not-
       crossed memory space from the separate VM node.  The supporting of
       multi-thread is not also the obligatory requirement.

       The 128-bit Global Job Identifier (GJID) is defined by protocol.  It
       is assigned on JCP, which will control the job.  All active GJID have
       the unique values in the unified system at each moment of time.

       The job can contain VM code of different types.  Different types VM
       can be situated on one or different nodes.  The mechanism of
       association of different VM types in groups on one node is
       stipulated, so to the non-uniform code can be executed on one node in
       a context of one job.  The groups are described in details in section
       9.  VM, incorporated in groups, must work in common memory space (to
       have a common subsystem of memory control).

    Bogdanov                      Experimental                      [Page 8]

    RFC 3018             Unified Memory Space Protocol         December 2000

    2.3  System Architecture

       System structure, based on using Virtual Machines, is given in the
       following figure:

                  Node 1                              Node 2
                 --------                            --------

          +--------------------+              +--------------------+
          | User Application 1 |              | User Application 1 |
          +-----------------------+           +-----------------------+
             | User Application N |              | User Application N |
             +--------------------+              +--------------------+

       +-----+  +-----+       +-----+      +-----+  +-----+       +-----+
       | VM1 |  | VM2 | . . . | VMn |      | VM1 |  | VM2 | . . . | VMn |
       +--+--+  +--+--+       +--+--+      +--+--+  +--+--+       +--+--+
          |        |             |            |        |             |
        +--------------------------+        +--------------------------+
        |                          |        |                          |
        | +-----+  U M S P         |        |          U M S P         |
        | | JCP |                  |        |                          |
        | +-----+                  |        +-------------+------------+
        +-------------+------------+                      |
                      |                             +-----+-----+
                +-----+-----+                       |    TCP    |
                |    TCP    |                       +-----+-----+
                +-----+-----+                             |
                      |                                   |
                      +-----------------/                 |
                                       /------------------+
                                      /
                                      |
                                +-----+-----+
                    Node N      |    TCP    |
                   --------     +-----+-----+
                                      |
                         +------------+------------+
                         | +-----+                 |
                         | | JCP | U M S P         |
                         | +-----+                 |
                         +-------------------------+

             Figure 1. Structure of the system based on use VM.

    Bogdanov                      Experimental                      [Page 9]

    RFC 3018             Unified Memory Space Protocol         December 2000

       One or several VM are working on upper level for UMSP.  The VM layer
       is not network level.  Last network level is UMSP.  Therefore, VM
       layer has no its own network primitives and uses together with UMSP
       the same field of operation code.

       The end services user of the protocol is the user code, which is
       executed by the virtual machine.  It has the instructions with the
       128-bit address.  VM translates these instructions to network
       commands, which are transmitted through the UMSP protocol for the
       executing by the remote machine.  Internal organization VM, command
       system and API can be anyone.  The protocol defines only format of
       primitives, which the virtual machines exchange through a network.

       The protocol does not control the jobs memory.  Control of memory
       should realize VM.  If a few VM works on one node, they may have the
       common memory space or may be completely isolated.

       UMSP uses the transport layer with reliable delivery for the data
       exchange.  This document defines of using TCP.  For the transfer of
       not requiring acknowledgement data may be used UDP.  Thus, the
       connection through TCP is obligatory.  Use of multiple connections
       TCP with multiplexing is supposed.  The control of transport
       connections is not the part of the UMSP protocol.

       The UMSP instructions do not contain network addresses of the
       receiver and sender.  The protocol requires that one address UMSP
       must correspond to the one transport layer address.  Accordingly, it
       is necessary to define unequivocal the node address on transport
       layer by the 128-bit address of memory.

       Except the TCP, it is possible to use other transport protocols or
       not network communications.  The following requirements are showed to
       them:

          o  Reliable delivery.  The transport layer must inform about
             delivery or its impossibility;
          o  The violation of a sequence of transmitted segments is allowed;
          o  The duplication of segments is not allowed;
          o  At emergency reload of nodes it is necessary to guarantee
             identification of segments concerning session connections,
             assigned up to reload;
          o  Use connectionless-mode is possible.

       VM is the independent program and the interaction with the protocol
       is necessary for it only when it executes the instructions with the
       128-bit address, concerning to other node.  VM can execute several

    Bogdanov                      Experimental                     [Page 10]

    RFC 3018             Unified Memory Space Protocol         December 2000

       user tasks.  Each task can contain several threads of control.  VM
       must be able to interpret the application instructions with the 128-
       bit address to one or several instructions of the UMSP protocol.

       The session connection opens between nodes for the data exchange.
       One connection is relational only with one job.  There may be several
       session connections for the different jobs simultaneously between two
       nodes.  Besides, the protocol provides the connectionless data
       exchange.

       The exchange between UMSP nodes can include the instructions of the
       following type:

          o  Immediate reading/write in memory;
          o  Requests of allocation/free memory;
          o  Comparison instructions;
          o  Call-subroutine and unconditional jump instructions;
          o  Synchronization instructions;
          o  Work with objects instructions - reading / writing in memory of
             objects and execution of objects procedures.

       UMSP does not trace the user control threads.  VM must provide itself
       the necessary order of performance of the instructions.

       The length of UMSP instructions does not depend on segment length of
       the transport layer.  The segmentation is provided for transfer of
       the long instructions.  The packing of the short instructions in one
       segment with a possibility of compression of headings is used for its
       transfer.  The minimal size of necessary for work segment is 6
       octets.  For realization of all functions, it is necessary 54 octets.

    3  Instruction Format

       The UMSP instruction includes the basic header, extension headers and
       operands.  All fields have variable length.

       +----------------+----------------------+------------------------+
       |     Header     |   Extension headers  |       Operands         |
       +----------------+----------------------+------------------------+

       The header contains operation code and the information necessary for
       the instruction interpretation.

       The optional extension headers contain the additional information,
       not defined in basic header.

       The operands contain instructions data.

    Bogdanov                      Experimental                     [Page 11]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The instruction format allows calculating common instruction length,
       without knowing definition of separate operation code.

       The instructions headers provide for the short and extended format
       for maintenance of the effective protocol work in wide range of
       network speeds.  Besides, there is a simple algorithm of the headers
       compression.

       The all instructions and extension headers the identifiers are given
       which enter the name by upper case symbols.  The identifiers of the
       instructions begin with the letter.  The identifiers of the extension
       headers begin with underlining symbol.

    3.1  Instruction Header

       The header has the following format:

        Octets:
           +0                              +1
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       0: |            OPCODE             |ASK|  PCK  |CHN|EXT| OPR_LENGTH|
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       2: |                        OPR_LENGTH_EXT                         |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       4: |                         CHAIN_NUMBER                          |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       6: |                         INSTR_NUMBER                          |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       8: |                                                               |
          +                          SESSION_ID                           +
          |                                                               |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       12:|                                                               |
          +                            REQ_ID                             +
          |                                                               |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

       OPCODE

          1 octet.  The operation code.  Value of this field is identified by
          the instruction.  Values of operation codes are divided into the
          following intervals:

                 1 - 112  management instructions
               113 - 127  reserved
               128 - 223  instructions of exchange between VM
             0, 224, 255  reserved

    Bogdanov                      Experimental                     [Page 12]

    RFC 3018             Unified Memory Space Protocol         December 2000

       ASK

          1 bit.  The flag of response necessity.  This flag defines
          presence of field REQ_ID in header.  If ASK = 1, there is field
          REQ_ID in the instruction.  If EXT = 0, the field REQ_ID in the
          instruction are absent.

       PCK

          2 bits.  The Header compression attribute.  These bits are used
          for packing instructions headers transmitted on one connection TCP
          or for sending of the several instructions in one package UDP.
          Use of these bits is based on the assumption that two following in
          succession instructions concern to one session connection, or one
          chain, with a high probability.  The PCK bits have one of the
          following values:

          %b00 - The instruction does not belong to the definite session.
                 The fields CHAIN_NUMBER, INSTR_NUMBER and SESSION_ID are
                 absent in header of such instruction.
          %b01 - The given instruction concerns to the same session
                 connection, as previous.  The field SESSION_ID in the
                 instruction header is absent.
          %b10 - The given instruction belongs to the same connection and
                 same chain, as previous.  The fields CHAIN_NUMBER,
                 INSTR_NUMBER and SESSION_ID in header of such instruction
                 are absent.  The INSTR_NUMBER value of the current
                 instruction calculates by addition of one to INSTR_NUMBER
                 value of the previous instruction.
          %b11 - The given instruction may does not concern to the same
                 session, as previous.  The field SESSION_ID is present at
                 it.  The presence of fields CHAIN_NUMBER and INSTR_NUMBER
                 is defined by CHN flag.

       CHN

          1 bit.  The flag of chain.  Transmitted on one session connection
          and concerning one job instructions, may be unified in a chain.
          Chains are considered in details by section 7.  If SEQ = 1, the
          instruction is connected with chain and there are fields
          CHAIN_NUMBER and INSTR_NUMBER (if PCK is not set to %b10) at it.
          If bit CHN = 0, the instruction is not connected with chains and
          there are no fields CHAIN_NUMBER and INSTR_NUMBER in it.

    Bogdanov                      Experimental                     [Page 13]

    RFC 3018             Unified Memory Space Protocol         December 2000

       EXT

          1 bit.  The flag of extension headers presence in the instruction.
          If EXT = 1, there is one or more extension headers in the
          instruction.  If EXT = 0, the extension headers in the instruction
          are absent.

       OPR_LENGTH

          3 bits.  The number of 32 bit words in the operands field.  The
          value 0 defines absence of operands field.  The value %b111
          specifies use of the extended header format.  In the extended
          format, the length of operands is defined by the field
          OPR_LENGTH_EXT, and the field OPR_LENGTH is not used.

       OPR_LENGTH_EXT

          2 octets.  The number of 32 bit words in the operands field.  The
          field OPR_LENGTH_EXT is present in header, only if OPR_LENGTH =
          %b111.  If OPR_LENGTH < > %b111, the field OPR_LENGTH_EXT is
          absent.  If OPR_LENGTH_EXT = 0, the field of operands is absent.
          There are following reasons, on which it is necessary to use field
          OPR_LENGTH_EXT instead of OPR_LENGTH:

             (1) If operands length must be more than 24 octets
             (2) If making the fields alignment of 4 octets is more
                 effective, than compression of header of 2 octets.

       CHAIN_NUMBER

          2 octets.  The number of chain.  This field contains number of
          chain, to which the given instruction concerns.  The values %x0000
          and %xFFFF are reserved.

       INSTR_NUMBER

          2 octets.  The instruction number.  This field contains the serial
          number of instruction in a chain.  The numbering begins with zero.
          Value %xFFFF is reserved.

       SESSION_ID

          4 octets.  It is the identifier of the session connection assigned
          by the instruction receiver.  During the session connection
          opening, each side sets its own identifier to connection and
          informs it to other side.  The zero value of this field specifies
          that the instruction does not concern to the definite session.
          The value %xFFFFFFFF is reserved.

    Bogdanov                      Experimental                     [Page 14]

    RFC 3018             Unified Memory Space Protocol         December 2000

       REQ_ID

          4 octets.  The request identifier.  It is uses for establishment
          of correspondence between requests and responds to it.

       Further, the identifier OPR_LENGTH is used at the description of the
       instructions format.  It means using of OPR_LENGTH_EXT field, if
       OPR_LENGTH = %b111.  The instruction with length of operands, which
       are not exceeding 24 octets, may be transmitted with header in the
       short format (OPR_LENGTH < > %b111) or in the extended format
       (OPR_LENGTH = %b111).  Both forms are equivalent.

       Minimal header length in the short format is 2 octets, in the
       extended format - 4 octets.  Maximal header length is 16 octets.

    3.2  Extension Headers

       If the EXT flag in the instruction header set to 1, the instruction
       contains from one up to thirty extension headers.  The extension
       headers are used for the following purposes:

       o  For sending of the service information which were not provided in
          the basic header.
       o  For sending of the data of length more than 262240 octets in one
          instruction.

       The extension headers have the following common format:

       Octets:
           +0                              +1
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       0: |HXT|       HEAD_LENGTH         |       HEAD_LENGTH_EXT         |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       2: |                   continued HEAD_LENGTH_EXT                   |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       4: |HSL|HOB|HRZ|     HEAD_CODE     |         HEAD_CODE_EXT         |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       6: |                           RESERVED                            |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       8: |                                                               |
          /                             DATA                              /
          /                                                               /
          |                                                               |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    Bogdanov                      Experimental                     [Page 15]

    RFC 3018             Unified Memory Space Protocol         December 2000

       HXT

          1 bit.  Specify length of the field of data length.  If HXT = 0,
          length of the extension header is defined by a field HEAD_LENGTH.
          The field HEAD_LENGTH_EXT in this case is absent.  If HXT = 1,
          length of header is defined by unification of fields HEAD_LENGTH
          and HEAD_LENGTH_EXT.

       HEAD_LENGTH

          7 bit.  The number of 16 bit words in DATA field.  If HXT = 0,
          this is independent field.  If HXT = 1, it is the senior bits of
          complete length field.

       HEAD_LENGTH_EXT

          3 octets.  The number of 16 bit words in DATA field.  If HXT = 0,
          this field is absent.  If HXT = 1, it is the younger bits of
          complete length field.

       HSL

          1 bit.  The flag of last header.  It is set to 1 for last
          extension header in the instruction.  In other extension headers,
          this flag is set to 0.

       HOB

          1 bit.  The flag of obligatory processing.  It defines the order
          of the instruction processing, if the receiving node does not know
          purpose of the extension header or cannot process it by any
          reason.  If HOB = 1, instruction must not be carried out.  If HOB
          = 0, it does not influence on the instruction processing.  The
          protocol must process all extension headers, irrespective of
          errors presence.

       HRZ

          1 bit.  The field is reserved for the future expansions.  This
          field must not be analyzed by the protocol on receiving.  It must
          be set to 0 at sending.

       HEAD_CODE

          5 bits.  If HXT = 0, the field contains the extension header code.
          If HXT = 1, this field joins the field HEAD_CODE_EXT.  It is the
          senior bits of the header code.

    Bogdanov                      Experimental                     [Page 16]

    RFC 3018             Unified Memory Space Protocol         December 2000

       HEAD_CODE_EXT

          1 octet.  If HXT = 0, this field is absent.  If HXT = 1, it is the
          younger bits of the header code.

       RESERVED

          2 octets.  If HXT = 0, this field is absent.  If HXT = 1, this
          field is reserved for further use.  The field RESERVED must not be
          analyzed by the protocol during the receiving in the current
          realization of the protocol.  It must be set to 0 at sending.

       DATA

          The data field of the extension header.  If HXT = 0, the length of
          field is 0 - 254 octets, if HXT = 1, the length is 0 - 4 * 10^9
          octets.  The format of this field is defined separately for each
          value of the header code.

       On the receiving side, the extension headers must be processed in
       that order, in what they follow in the instruction.  If the
       instruction contains more than 30 extension headers, it is considered
       erroneous.  It is necessary to break off the session connection, on
       which it was transmitted, after the reception of such instruction.

       The identifiers HEAD_LENGTH and HEAD_CODE are used further in the
       text at the description of the extended headers format.  It assumes
       using of fields HEAD_LENGTH + HEAD_LENGTH_EXT and HEAD_CODE +
       HEAD_CODE_EXT, if HXT = 1.  The headers with the code 0 - 30 can be
       sent in short (HXT = 0) and in extended (HXT = 1) format.

    3.3  Instruction Operands

       The operands field contains the instruction data.  The length of
       operands field is showed in OPR_LENGTH or OPR_LENGTH_EXT and it is
       multiple to four octets.  If necessary, 1 - 3 zero-value octets are
       padded in the end of a field.  Maximal length of operands is 262140
       octets.  The extension headers are used, if the instruction must
       contain longer data.

       The format of the operands field is defined separately for each
       instruction.

    3.4  Address Formats

       The following address format numbers are definite for nodes,
       immediately connected to the global IPv4 network:

    Bogdanov                      Experimental                     [Page 17]

    RFC 3018             Unified Memory Space Protocol         December 2000

          N 4-0-0 (4)
          N 4-0-1 (4-1)
          N 4-0-2 (4-2)

       The appropriate formats of 128-bit addresses:

       Octets:
          +0              +1              +2              +3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0: |0 1 0 0|0 0|0 0|                   Free                        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       4: |                              Free                             |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       8: |            Free               |           IP address          |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       12:|           IP address          |      Local memory address     |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0: |0 1 0 0|0 0|0 1|                   Free                        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       4: |                              Free                             |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       8: |     Free      |                  IP address                   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       12:|   IP address  |             Local memory address              |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0: |0 1 0 0|0 0|1 0|                   Free                        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       4: |                            Free                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       8: |                         IP address                            |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       12:|                     Local memory address                      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Free

          It is not used by the protocol.

       IP address

          It sets the node address in the global IPv4 network.

    Bogdanov                      Experimental                     [Page 18]

    RFC 3018             Unified Memory Space Protocol         December 2000

       Local memory address

          It is described in section 2.1.

       IP-address defines the nodes of the given type unequivocally.  The
       TCP is used for the interaction with such nodes.  For sending of not
       requiring response instructions, using UDP is allowed.  IANA has
       assigned ports TCP and UDP 2110.  This port must be open for the
       listening (receiving).  TCP node, initialing the connection opening,
       or the UDP node, carrying out the package sending, can use any port.
       Using several TCP connections with multiplexing is supposed.

    4  Response of the Instructions

       The protocol instructions are divided into two types:

          (1)  The management instructions transmitted on UMSP layer (OPCODE
               = 1 - 112).
          (2)  The instructions of the exchange between VM (OPCODE = 128 -
               223).

       The processing of two types of the instructions differs as follows:

       o  The field of the identifier of request REQ_ID is formed by the
          protocol in the instructions of the first type, and it is formed
          by VM for the instructions of the second type.
       o  The protocol must analyze the field REQ_ID and compare it with the
          instructions, transmitted earlier, after receiving of the response
          instruction of the first type.
       o  The protocol must not analyze the field REQ_ID after receiving of
          the response instruction of the second type.  This instruction is
          simply sent to VM.

       The response instructions have the field ASK equal to 1.  It means,
       that the header have the field REQ_ID.  The value taken from the
       confirmed instruction is written into the field REQ_ID.  The response
       instruction does not require response.

       A few VM can be connected to the protocol on the node.  Everyone VM
       can work in its own address space.  The identifiers of requests for
       different VM can coincide.  Therefore, instruction is identified by
       two fields:

       o  The session identifier SESSION_ID, which is connected with
          definite VM.
       o  The request identifier REQ_ID.

    Bogdanov                      Experimental                     [Page 19]

    RFC 3018             Unified Memory Space Protocol         December 2000

    4.1  RSP, RSP_P

       "Response" (RSP) and "Response of the protocol" (RSP_P) instructions
       have the identical format.  The difference is only in the operation
       code:

          OPCODE = 129/1  ; correspondingly to RSP/RSP_P
          ASK = 1
          PCK = %b01/11
          EXT = 0/1
          CHN = 0
          OPR_LENGTH = 0/1
          SESSION_ID and REQ_ID - The values is taken from the confirmed
                                  instruction.
          Operands:
             2 octets: The basic return code.
             2 octets: The additional return code.
          The optional extension header:
             _MSG - contains the arbitrary error description.

       The instruction without operands is used for the positive response.
       It is equivalent to zero values of the field of the basic and
       additional return codes.

       The zero basic return code is used for positive response.  The
       additional return code may have non-zero value.

       The instruction with non-zero basic return code is used for negative
       response.  The basic return code defines the error category.  The
       additional return code identifies an error.

       The instruction RSP is formed upon the VM request.  The return codes
       must be received from VM.  If the protocol cannot deliver the
       requiring response instruction to VM, it forms negative response RSP
       independently.

       The instruction RSP_P is always formed at the UMSP layer.  If the
       protocol cannot define on what instruction the RSP_P is transmitted,
       nothing actions is executed.

    4.2  SND_CANCEL

       There can be a necessity to cancel sending after the part of the data
       have been already transmitted and have occupied the buffer on the
       reception side, by sending of the long fragmented instructions or
       transactions.  The protocol provides the instruction "The sending is
       canceled" (SND_CANCEL) for this purpose.  This instruction has the
       following fields value:

    Bogdanov                      Experimental                     [Page 20]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 2
          ASK = 0
          PCK = %b01/10/11
          EXT = 0/1
          CHN = 1
          OPR_LENGTH = 1
          SESSION_ID - The value is taken from the cancelled chain.
          CHAIN_NUMBER - Number of the chain, which sending is cancelled.
          INSTR_NUMBER - Always has zero-value.
          Operands:
             2 octets: The basic return code.
             2 octets: The additional return code.
          The optional extension header:
             _MSG - contains the arbitrary error description.

       The instruction SND_CANCEL is used for the cancel of the partially
       transmitted transaction or fragmented instruction.  At the receiving
       the SND_CANCEL instruction, all the earlier received data in the
       chain are rejected.

    5  Jobs Management

       The jobs management includes the following functions:

       o  Initiation and completion of jobs;
       o  Initiation and completion of tasks;
       o  Opening and closing of session connections;
       o  Activity control of nodes.

       The instructions with OPCODE = 1 - 112 are used for jobs management.
       These instructions must be sent through TCP.  Use UDP is not allowed,
       even if the instructions do not demand response.

       UMSP bases on model with the centralized control of the separate job.
       The reason is that the pointers control is not obviously possible in
       the decentralized system.  Any task can be finished at any moment or
       the node can be reloaded.  There is no way guaranteeing the
       notification about in the decentralized system all other nodes, on
       which the job works.  As the job continues to exist - the task
       concerning the job can be initiated on the same node again.  This
       task can allocate new dynamic resources.  The addresses for the again
       allocated resources can be crossed with addresses of resources, which
       existed on the node before the task restart.  The old pointers can be
       kept on other nodes.  It may be the formally correct pointers, but
       they will actually specify other objects.  The uncontrollable work of
       the application can be consequence of such situation.

    Bogdanov                      Experimental                     [Page 21]

    RFC 3018             Unified Memory Space Protocol         December 2000

       UMSP solves this task as follows:

       o  It allows defining the node, on which the task was completed,
          precisely.
       o  If the task on the node is finished before end of the job, all
          nodes, on which the job is executed, are notified of it.
       o  The repeated task initialization on the node is allowed, while all
          nodes will receive the message about the first task end.

       The protocol does not control the pointers.  VM supervises the
       pointers correctness.  VM must have architecture, in which 128 - bit
       pointers are stored in special memory areas, for this purpose.  The
       protocol informs VM about the nodes, on which task have finished the
       work.  VM must make all pointers concerning such tasks, invalid.  It
       results in exclusive situations at the access under these pointers.
       If the application provides processing exceptions, it keeps the
       capacity for work, or it is finished emergency.  Such decision allows
       excluding unguided applications working.

       For the decision of the specified questions at UMSP level, the
       control job node is defined for each job.  It names Job Control Point
       (JCP).  It may be the same node, on which the job is initiated, or it
       can be another dedicated node.  The basic JCP function is to trace
       the initialization and the end of the job tasks.  Besides, the
       dedicated JCP node may be used for the centralized users
       identification and the attack protection.

       The following identifiers are definite for the jobs and tasks
       control:

       o  Locally Task Identifier (LTID) is assigned to each active task on
          the node.  LTID length is equal to the length of local memory
          address defined for the node.  All LTID on the node must give
          unique values at each moment of time.  It is allowed to establish
          LTID, used earlier in the already completed tasks, for the again
          initiated tasks.
       o  JCP assigned the Control Task Identifier (CTID) to each task of
          the job.  Its length is equal to length of the local address
          memory on the node JCP.  All CTID on the JCP must give unique
          values at each moment of time.  As against LTID, the CTID value is
          chosen with some restrictions.
       o  Globally Task Identifier (GTID) is assigned to each task.  GTID
          has the same format, as the 128 - bit address of node memory has.
          The address of local memory is replaced on LTID in it.
       o  Globally Job Identifier (GJID) is assigned to the each job.  GJID
          is defined on the JCP node.  It has the same format, as the 128 -
          bit address of node JCP memory has.  The address of local memory

    Bogdanov                      Experimental                     [Page 22]

    RFC 3018             Unified Memory Space Protocol         December 2000

          is replaced on CTID of the first (initial) task of the job in it.
          GJID is used in the procedure of session connection opening for
          the definition JCP, which controls the job.

       LTID and CTID are written at the instructions in the field of length
       2/4/8 octets.  If the allocated for identifier field in the
       instruction is longer than identifier, LTID (CTID) writes in the last
       octets.  In the initial octets, the value 0 must be written.  If
       received LTID (CTID) is shorter than the local memory address, it is
       necessary to pad it with the zero octets in the beginning.

       GTID and GJID are written at the instructions in the field of length
       4-16 octets.  The field FREE is not present at these identifiers (see
       section 2.1).  It is considered, that it contains the zero-value
       octets.  Length of the identifier is defined in header of the
       address.

       By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN,
       the protocol uses timeout.  The value of timeout is assigned by node
       and must be more than three intervals of the maximal time of delivery
       at the transport layer.  The timeout is not influenced the waiting
       period in queue to the transport layer.

    5.1    Job Initiate

       The job concerns to the user application executed on VM.  The UMSP
       job initialization can be made simultaneously with the application
       user start or during its working.

       The task, appropriated to its job, is initialized on the node
       together with the job.  LTID is binding to this task.

       If the node, on which the user application was loaded, is chosen for
       JCP, the question of the job initialization lays beyond the scope of
       the network protocol.

       Other node can be chosen as JCP for the following reasons:

       o  The job initialization node is connected to network by slow-speed
          or overloaded channel.  It is undesirable to send the managing
          traffic.
       o  The node has no computing possibilities for conducting the
          managing tables.
       o  The authentication on the detailed node is necessary.

       If the other node is chosen for JCP, the node, that initiates the
       job, must register the job at JCP.

    Bogdanov                      Experimental                     [Page 23]

    RFC 3018             Unified Memory Space Protocol         December 2000

    5.1.1     CONTROL_REQ

       The instruction "To request a control" (CONTROL_REQ) is sending from
       the node, initial the job, to JCP of other node.  The instruction has
       the following values of fields:

          OPCODE = 3
          PCK = %b00
          CHN = 0
          ASK = 1
          EXT = 0/1
          OPR_LENGTH = 2/3  ; Depends on LTID length.
          REQ_ID - The value is assigned by the sender node protocol and
                   then will be sent in the response.
          Operands:
             4 octets: The control parameters profile.  This field has the
                       following format:

                bits
                 0     1     2     3     4     5     6     7
                +-----+-----+-----+-----+-----+-----+-----+-----+
                |                                               |
                +                 JOB_LIFE_TIME                 +
                |                                               |
                +-----+-----+-----+-----+-----+-----+-----+-----+
                | CMT |    Reserved     |        VERSION        |
                +-----+-----+-----+-----+-----+-----+-----+-----+
                |                   Reserved                    |
                +-----+-----+-----+-----+-----+-----+-----+-----+

                JOB_LIFE_TIME

                   2 octets.  The job lifetime in seconds.  The zero-value
                   signifies that the restriction of the job lifetime is
                   unused.

                CMT

                   1 bit.  The flag of several JCP using.  This field is
                   reserved for the future expansion of the protocol.

                VERSION

                   1 octet.  The number of the UMSP version.  It must
                   contain the value 1.

    Bogdanov                      Experimental                     [Page 24]

    RFC 3018             Unified Memory Space Protocol         December 2000

                Reserved

                   3 + 8 bits.  All bits must be set to 0.

             4/8 octet: LTID of task of the job, assigned on the node, which
                        initiate the job (by the sender of this
                        instruction).
          The optional extension headers:
             _JOB_NAME  -  This header contains the name of the Job.  Is
                           assigned once and must not change further.
             _INACT_TIME - This header contains the inaction time (see
                           section 5.7).

       At reception of the CONTROL_REQ instruction JCP checks the LTID value
       from the received instruction and makes the following:

       (1) If the node, which has sent CONTROL_REQ, already has registered
           on JCP the active job with such LTID, the notification about
           abnormality end of the registered job is sent, as is described in
           section 5.5.2 (it is considered, that the node was reloaded).
           After that, the sanction to an initiation of the new job is sent.
       (2) If the node has no registered job with received LTID, it allows
           the new job initiation at once.

       If JCP confirms the control, it will send the instruction
       CONTROL_CONFIRM, or else CONTROL_REJECT.

    5.1.2     CONTROL_CONFIRM

       The instruction "To confirm the control" (CONTROL_CONFIRM) is sent
       from JCP as the positive response to CONTROL_REQ instruction.
       CONTROL_CONFIRM has the following values of fields:

          OPCODE = 4
          PCK = %b00
          CHN = 0
          ASK = 1 ; The instruction does not need to be responded.  This flag
                    specifies presence of the REQ_ID field.
          EXT = 0/1
          OPR_LENGTH = 1-4 ; Depends of length of the GJID.
          REQ_ID - The value is taken from the instruction CONTROL_REQ
          Operands:
             4-16 octets: The GJID assigned to the job on the JCP.

       The sending of the instruction CONTROL_REQ means request of control
       and request of task initiation.  Assigned to the task CTID is part
       GJID (field of the local memory address).

    Bogdanov                      Experimental                     [Page 25]

    RFC 3018             Unified Memory Space Protocol         December 2000

    5.1.3     CONTROL_REJECT

       The instruction "To reject the control" (CONTROL_REJECT) is sent from
       JCP as the negative response to CONTROL_REQ instruction.
       CONTROL_REJECT has the following values of fields:

          OPCODE = 4
          PCK = %b00
          CHN = 0
          ASK = 1.  The instruction does not need to be responded.  This flag
                    specifies presence of the REQ_ID field.
          EXT = 0/1
          OPR_LENGTH = 1/2 ; Depends on presence of the control parameters
                             profile field.
          REQ_ID - The value is taken from the instruction CONTROL_REQ
          Operands:
             2 octets: The basic error code.  The zero-value is not
                       available.
             2 octets: The additional error code.
             4 octets: The control parameters profile (see section 5.1.1),
                       that is allowed by JCP.  This is optional field.
          The optional extension headers:
             _INACT_TIME - This header contains the inaction time (see
                           section 5.7).
             _MSG - contains the arbitrary error description.

    5.2    Task Initiate

       The job is executed on several nodes simultaneously.  The task,
       appropriate to it, must be initialized on each node.  There is
       corresponding only one task to one job on the node.  Each task must
       be connected only with one job.

       The task is initiated together with the job on the node, which had
       created the job.  On the other nodes, the task is initiated during
       the receiving of the first request on the opening of the session
       connection, which is appropriate to the job.  The request about
       openings of session connection contains GJID.  GJID contains the JCP
       address.  It is necessary to receive the sanction from JCP for the
       task start.  If the request about the opening of session has been
       received from JCP node, it is not necessary to request the sanction.

    5.2.1     TASK_REG

       The instruction "To register a task" (TASK_REG) is sent from the
       node, which initials the task, to JCP of the remote node.  The
       instruction has the following values of fields:

    Bogdanov                      Experimental                     [Page 26]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 6/7/8 ; For length CTID of 2/4/8 octets.
          PCK = %b00
          CHN = 0
          ASK = 1
          EXT = 0/1
          OPR_LENGTH = 2-8  ; Depends on length of the GTID and LTID.
          REQ_ID - The value is assigned by the sender node protocol and
                   then will be sent in the response.
          Operands:
             2/4/8 octets: CTID of the task initiated the job.  It CTID is a
                           part GJID from the instruction SESSION_OPEN.
             4-16 octets: GTID, assigned on the node, initialed session
                          connection.  GTID is formed of sender addresses (at
                          transport layer) and field LTID of the instruction
                          SESSION_OPEN.
             2/4/8 octets:  LTID, assigned on the node, initialed the task
                            (by the sender of this instruction).
          The optional extension headers:
             _INACT_TIME - This header contains the inaction time (see
                           section 5.7).

       The instruction TASK_REG must be sent only if the task with given
       GJID was not initiated on the node.

       JCP confirms initiation of a task at observance of the following
       conditions:

       (1) Task with received GTID already has registered on JCP.
       (2) Task with LTID for the node requesting for initiation has not
           registered.

       In all other cases, JCP will not confirm a task.

       If JCP confirms the task, it will send the instruction TASK_CONFIRM,
       differently TASK_REJECT.

    5.2.2     TASK_CONFIRM

       The instruction "To confirm the task" (TASK_CONFIRM) is sent from JCP
       as the positive response to TASK_REG.  TASK_CONFIRM has the following
       values of fields:

          OPCODE = 9
          PCK = %b00
          CHN = 0
          ASK = 1.  The instruction does not need to be responded.  This flag
                    specifies the field REQ_ID presence.
          EXT = 0/1

    Bogdanov                      Experimental                     [Page 27]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPR_LENGTH = 1/2  ; Depends on length of the CTID.
          REQ_ID - The value is taken from the instruction TASK_REG.
          Operands:
             4/8 octets: The CTID assigned to the task on the JCP.
          The optional extension headers:
             _JOB_NAME - This header contains the name of the Job.

    5.2.3     TASK_REJECT

       The instruction "To reject the task" (TASK_REJECT) is sent from JCP
       as the negative response to TASK_REG instruction.  TASK_REJECT has
       the following values of fields:

          OPCODE = 10
          PCK = %b00
          CHN = 0
          ASK = 1.  The instruction does not need to be responded.  This flag
                    specifies presence of the REQ_ID field.
          EXT = 0/1
          OPR_LENGTH = 1
          REQ_ID - The value is taken from the instruction CONTROL_REQ
          Operands:
             2 octets: The basic error code.  The zero-value is not
                       available.
             2 octets: The additional error code.
          The optional extension headers:
             _INACT_TIME - This header contains the inaction time (see
                           section 5.7).
             _MSG - contains the arbitrary error description.

    5.2.4     TASK_CHK

       With the purposes of a safety the node, which have received request
       about the opening of session connection, may check up at JCP the
       node, which has initialed connection, even if the task was already
       initiated.

       The instruction "To check up the task" (TASK_CHK) is sent from the
       node, which has received the instruction of the establishment of
       session connection SESSION_OPEN, to JCP.  The task with given GJID,
       must have existed on the node already.  The instruction TASK_CHK
       format coincides with TASK_REG.  OPCODE = 11.  The response to the
       instruction TASK_CHK JCP forms instructions TASK_REG similarly.

       JCP confirms the instruction TASK_CHK if a task with received GTID
       and LTID already has registered on JCP.

       The sending of the TASK_CHK is optional.

    Bogdanov                      Experimental                     [Page 28]

    RFC 3018             Unified Memory Space Protocol         December 2000

    5.3    Establishment of session connection

       The session connection is established between two tasks of one job.
       The connection is established under the VM initiative and it is used
       for the exchange of the instructions between VM.

       One session connection must be connected only with one task on the
       node.  The task may have several connections with different nodes.
       Between two nodes must be only one session connection with one GJID.

       The request about the establishment of session connection contains
       the global identifier of the job GJID.  If the node receives the
       request about the establishment of connection with GJID, which is not
       presented on the given node, VM must create a new task.  If the task
       has been already initialized, the new task is not created.

       The session connection needs to be established over TCP.  After the
       connection is established, the sending of the instructions, which are
       not require of execution response, is possible through UDP.  One TCP
       connection may be used by several session connections.  One session
       connection may use several TCP connections.

       The protocol allows working without the establishment of session
       connection.  The node must have VM by default, which must execute the
       instructions without the establishment of connection.

       At the establishment of session connection, the sides agree about the
       used VM type and the subset of the protocol functions.  The session
       connection UMSP may be asymmetrical.  It means, that two sides of one
       connection can be connected with VM of the different type and provide
       the different subset of the protocol functions.

       If at an establishment of session connection the zero-type VM is
       used, it specifies group VM (see section 9).  The zero-value of
       realization VM is not allowed.

       The procedure of the establishment of session connection may contain
       from 2-way up to 8-way handshakes.

    5.3.1     SESSION_OPEN

       The instruction "To open a session" (SESSION_OPEN) is used for the
       initiation of session connection and for the specification of
       connection parameters during handshake.  It has the following values
       of fields:

    Bogdanov                      Experimental                     [Page 29]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 12
          PCK = %b00/11.  In the first instruction (initial) the value of
                           this field is set to %b00.  In all subsequent -
                           %b11.
          CHN = 0
          ASK = 1
          EXT = 0/1
          OPR_LENGTH = 6 - 10 ; Depends on length GJID and LTID.
          SESSION_ID - In the first instruction this field is absent.  In all
                       subsequent, it contains the identifier of sessions,
                       assigned by the instruction receiver.
          REQ_ID - This field contains the session connection identifier,
                   assigned by the instruction sender.
          Operands:
             2 octets: The VM type required from the addressee.
             2 octets: The VM version required from the addressee.
             4 octets: The profile of connection required from the
                       instruction addressee.
             2 octets: The VM type of the sender.
             2 octets: The VM version of the sender.
             4 octets: The profile of connection given by the instruction
                       sender.
             2 octets: The number of 256 octet blocks in the buffer,
                       allocated for session ("window"), on the side of the
                       sender of this instruction (see section 7.4).  The
                       zero-value specifies absence of the buffer.
             4-16 octets: GJID.
             4/8 octets: LTID of the sender task, assigned on the node -
                         sender of the instruction.  It is used in the
                         instruction TASK_REG (as a part of the field GTID).

       If the VM type and version, required from the addressee, have the
       value 0, the receiving node independently chooses the VM type and
       reports it in the response.  The establishment of connection without
       binding to VM or VM group is not allowed.

       Totally, it can be transmitted up to 7 instructions SESSION_OPEN at
       the establishment of connection.  The instruction SESSION_ACCEPT is
       used for the response of the establishment of connection.  For the
       refusal of connection the instruction, SESSION_REJECT is used.

       It is possible to refuse connection on any step.  It is necessary
       either to confirm connections, or to refuse it on the eighth step.

       During the establishment of connection the following parameters may
       be changed:

    Bogdanov                      Experimental                     [Page 30]

    RFC 3018             Unified Memory Space Protocol         December 2000

       o  VM type and VM version;
       o  profiles of connection.

       If the repeated request about opening of session connection is
       received from the definite node, while one connection with received
       GJID have been already established, the following variants are
       possible:

       (1) If the request has arrived from the node JCP, it is necessary:
           o  To finish the existing task emergency and to deallocate all
              dynamic resources belong to it.
           o  To initiates a task without request of the JCP sanction again.
           o  To confirm the establishment of connection.
       (2) If the request arrived not from the JCP node, it is necessary to
           refuse the establishment of new session connection.  The existing
           task does not need to be changed.

    5.3.2     SESSION_ACCEPT

       The instruction "To accept the session" (SESSION_ACCEPT) is used for
       positive response to the establishment of session connection.  It has
       the following values of fields:

          OPCODE = 13
          ASK = 1
          PCK = %11
          EXT = 0/1
          CHN = 0
          OPR_LENGTH = 0
          SESSION_ID - This field contains the session connection identifier
                       of assigned by the node of the addressee of the
                       instruction.
          REQ_ID - This field contains the session connection identifier,
                   assigned by the instruction sender.

    5.3.3     SESSION_REJECT

       The instruction "To reject the session" (SESSION_ACCEPT) is used for
       negative response to the establishment of session connection.  It has
       the following values of fields:

          OPCODE = 14
          ASK = 0
          PCK = %b11
          EXT = 0/1
          CHN = 0
          OPR_LENGTH = 1

    Bogdanov                      Experimental                     [Page 31]

    RFC 3018             Unified Memory Space Protocol         December 2000

          SESSION_ID - This field contains the session connection identifier
                       of assigned by the node of the addressee of the
                       instruction.
          Operands:
             2 octets: The basic error code.  The zero-value is not
                       available.
             2 octets: The additional error code.
          The optional extension headers:
             _MSG - contains the arbitrary error description.

    5.3.4     Connection Profile

       The profile of connection is defined in 4-octet field of flags.  The
       flags have identifiers S0 - S31.  The number in the identifier is
       defining the serial number of bit.  If the flag is set to 1, the
       function, connected with it, is provided.  If the flag is set to 0,
       the function, connected with it, is not provided (not required).  The
       list of functions, determined at the establishment of session
       connection, are described further.

       Work with chains:

          S0 - Use of fragmented instructions.
          S1 - Use of sequences.
          S2 - Use of transactions.

       Establishment of connection:

          S3 - Use the exchange of the data without the establishment of
               connection.
          S4 - Use the exchange of the data with the establishment of
               connection.

       The instructions format:

          S5  - Reserved.  Must have set to 0.
          S6  - Use of 16-octet address in the exchange instructions.
          S7  - Use of the compressed form of header of the instruction
                (OPR_LENGTH < > %b111) is allowed
          S8  - Use of the extension form of header of the instruction
                (OPR_LENGTH = %b111) is allowed
          S9  - Use of the extension headers with the data field up to 254
                octets of length.
          S10 - Use of the extension headers with the data field up to 4 *
                10^9 octets of length.
          S11-S15  Maximal length of the data field in operands in the 4
                   octet words.  These bits are the common field.  Maximal
                   length in octets is computed under the formula:

    Bogdanov                      Experimental                     [Page 32]

    RFC 3018             Unified Memory Space Protocol         December 2000

                      <max length> = (<value of this field> + 1) * 4.
                   If the value is equal %b1111, maximal length of the data
                   is defined by the instruction format.
          S16-S19  These bits are the common field.  In the profile required
                   from the addressee of the instruction, this field
                   contains the version of the UMSP.  It must is set to the
                   value %b0001.  In the profile given sender of the
                   instruction, this field contains priority of the job.  The
                   more is value of this field, the more priority.  The
                   priority of the job is used:
                   o In queues on sending to the transport layer for the
                     instructions of the job.
                   o For set of sending priority of the transport layer.
                   o For set of computing priority of the task.
          S20 - making the border multiple of 4 octets.  If S16 = 1:
             (1)  OPR_LENGTH = %b111
             (2)  Each extension header and the field of operands begin with
                   the border multiple of four octets.
             (3)  The necessary number of zero octets is added in the end of
                  each header.
          S21 - Use of the procedures name of objects.
          S22 - Use of the objects name.

       The permissible instructions:

          S23 - The response of the execution on VM (instruction RSP) is
                provided.
          S24 - Use of data reading and comparison instructions.
          S25 - Use of data writing instructions.
          S26 - Use of control transfer instructions.
          S27 - Use of synchronize instruction.
          S28 - Use of instructions of work witch objects.
          S29 - Use of the immediate access to memory of object.  If this
                flag is set to 0, the access to object is solved only
                through its procedures.  If S28=0, this flag must be set to
                0.
          S30 - Use of instruction MVRUN in zero-session.
          S31 - Reserved.  Must have set to 0.

    5.4    Session Closing

       Initiate closing session connection the node must only, which has
       initiated its establishment.  It uses the SESSION_CLOSE instruction
       for this purpose.  The procedure of break of connection is 3-way
       handshake.  The procedure of unconditional emergency end of
       connection is stipulated.  It can be transmitted by any node.

    Bogdanov                      Experimental                     [Page 33]

    RFC 3018             Unified Memory Space Protocol         December 2000

       Let node A is the initiator of the establishment of a session, and
       the node B is the second side of connection.  The node A must send
       the instruction SESSION_CLOSE for closing session.  The node A may
       recommence sending of the instructions after sending of this
       instruction.  It means that it has refused closing connection.  The
       instructions of response (see section 6) does not influence on the
       closing of connection.  The node, which has sent SESSION_CLOSE, does
       not use the timeout and can be waiting for the response beyond all
       bounds long.

       The node B, after reception of the instruction SESSION_CLOSE, sends
       in the answer the instruction RSP_P.  The zero basic return code
       responds closing session.  The non-zero basic return code cancels
       closing session.  After sending of positive response, the node must
       not use connection during 30-second timeout.  If the instruction
       SESSION_ABEND or any other instruction, except response instruction,
       has not been received from the node A after the expiration of this
       time, the node send the instruction SESSION_ABEND and considers the
       session connection closed.

       The node A sends the instruction SESSION_ABEND after reception of
       positive response on the instruction SESSION_CLOSE.  After that, the
       connection is considered closed.  The node A may refuse closing of
       connection.  For this purpose, any instruction is sent, including
       NOP.  In this case, the procedure of end interrupts, and the session
       connection is translated in the working state.

    5.4.1     SESSION_CLOSE

       The instruction "To close the session" (SESSION_CLOSE) initiates the
       end of session connection.  It has the following values of fields:

          OPCODE = 15
          PCK = %b01/11
          CHN = 0
          ASK = 0
          EXT = 0/1
          OPR_LENGTH = 0/1
          SESSION_ID - Contains the session identifier assigned by the
                       addressee.
          Operands:
             2 octets: The basic termination code.
             2 octets: The additional termination code.
          The optional extension header:
             _MSG - contains the arbitrary message.

       The operands may be absent.  It is equivalent to the zero exit code.

    Bogdanov                      Experimental                     [Page 34]

    RFC 3018             Unified Memory Space Protocol         December 2000

    5.4.2     SESSION_ABEND

       The instruction "Abend of session" SESSION_ABEND is applied to
       unconditional end of session.  The node, which has sent this
       instruction, finishes the exchange of the data on connection at both
       sides, not waiting responses from other node.  The instruction has
       the following values of fields:

          OPCODE = 16
          PCK = %b01/11
          CHN = 0
          ASK = 0
          EXT = 0/1
          OPR_LENGTH = 0/1
          SESSION_ID - Contains the session identifier assigned by the
                       addressee.
          Operands:
             2 octets: The basic termination code.
             2 octets: The additional termination code.
          The optional extension header:
             _MSG - contains the arbitrary message.

       The operands may be absent.  It is equivalent to the zero termination
       codes.

    5.5    Task Termination

       The task is finished during the process of the job finishing at the
       normal end of the user application working.  This procedure is
       described in the following item.  The following situations require
       finishing the task irrespective of the job:

       o  There are not enough of computing resources for maintenance of the
          task on the node;
       o  The node finishes the work;
       o  If VM has accepted such decision for the internal reasons.

       The references to the resources allocated by the task can be on any
       node, on which the job is carried out.  Therefore, all nodes must be
       notified of the end of the task.

       Node, finishing the task, must abnormally close all session
       connections joining the finished task (to send the instruction
       SESSION_ABEND).

    Bogdanov                      Experimental                     [Page 35]

    RFC 3018             Unified Memory Space Protocol         December 2000

    5.5.1     TASK_TERMINATE

       The instruction "To terminate the task" (TASK_TERMINATE) is sent from
       the node, on which the task is finished, to JCP.  The instruction has
       the following values of fields:

          OPCODE = 17
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0/1
          OPR_LENGTH = 2/3  ; Depends on the length of CTID.
          Operands:
             2 octets: The basic termination code.
             2 octets: The additional termination code.
             4/8 octets: CTID.
          The optional extension header:
             _MSG - contains the arbitrary message.

       After sending of the instruction TASK_TERMINATE to JCP, the node
       sends the instruction of unconditional end of connection
       ABEND_SESSION on all session connections connected with a task.
       After that, the task is considered completed.

       If the basic return code in the instruction TASK_TERMINATE is equal
       to 0, it is not required to notify other nodes about the end of the
       task.  Such situation arises, if the task did not allocate dynamic
       resources.  If the basic return code is unequal to 0, JCP must notify
       about the task end the other nodes, on which the job is carried out,
       after reception of the instruction TASK_TERMINATE.  JCP responds for
       the notification of all nodes of the job about the task end.

    5.5.2     TASK_TERMINATE_INFO

       The instruction "The information on terminating of the task"
       (TASK_TERMINATE_INFO) is used for the notification about the task
       end.  It is sent from JCP to other nodes, on which the job is carried
       out.  The instruction has the following values of fields:

          OPCODE = 18
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0/1
          OPR_LENGTH = 2-5 ; Depends on the length of GTID.
          Operands:
             2 octets: The basic termination code.
             2 octets: The additional termination code.

    Bogdanov                      Experimental                     [Page 36]

    RFC 3018             Unified Memory Space Protocol         December 2000

             4-16 octets: GTID of the terminated task.  JCP forms GTID from
                          LTID (from the instruction TASK_REG) and address
                          of transport layer of the task.
          The optional extension header:
             _MSG - contains the arbitrary message.

       The fields of termination codes are taken from the instruction
       TASK_TERMINATE.  The job must delete (to make invalid) all references
       to resources concerning the node, on which the completed task worked,
       at reception of the instruction TASK_TERMINATE_INFO.

    5.6    Job Completion

       The job is finished, when the appropriated to it the user application
       on the node, on which it was initiated, is finished.  The end of the
       job occurs under the initiative of VM.  Besides, it can be completed
       under the JCP initiative at ending the lifetime of the job or at end
       of the JCP node working.

    5.6.1     JOB_COMPLETED

       The instruction "The task is completed" (JOB_COMPLETED) is sent from
       the node, which initiated the job, in the JCP side.  It has the
       following values of fields:

          OPCODE = 19
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0/1
          OPR_LENGTH = 2/3 ; Depends on the CTID length.
          Operands:
             2 octets: The basic completion code.
             2 octets: The additional completion code.
             4/8 octets: CTID of the completed task of the job.  CTID is a
                         part GJID of the job.
          The optional extension header:
             _MSG - contains the arbitrary message.

       After sending of the instruction JOB_COMPLETED to JCP, the node sends
       on all connected with the session connections of the job the
       instruction of unconditional end of connection ABEND_SESSION.  After
       that, the job is considered completed.

       JCP must notify of the end of the job the nodes, on which the job is
       carried out, after reception of the instruction JOB_COMPLETED.  JCP
       responds for the notification of all nodes of the job about end of
       the job.

    Bogdanov                      Experimental                     [Page 37]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The instruction TASK_TERMINATE_INFO may be transferred under the
       initiative JCP, if node of the task has abnormal terminated work.

    5.6.2     JOB_COMPLETED_INFO

       The instruction "The information on completion of the job"
       (JOB_COMPLETED_INFO) is used for the notification about end of the
       job.  It is sent from JCP to other nodes, on which the job is carried
       out.  The instruction has the following values of fields:

          OPCODE = 20
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0/1 ;
          OPR_LENGTH = 2-5 ; Depends on the GJID length and presence of
                             fields completion code.
          Operands:
             2 octets: The basic completion code.
             2 octets: The additional completion code.
             4-16 octets: GJID of the completed job.
          The optional extension header:
             _MSG - contains the arbitrary message.

       The fields of completion codes are optional.

       The fields of completion codes are taken from the instruction
       JOB_COMPLETED.  At reception of the instruction, JOB_COMPLETED_INFO
       the node must make the following:

       (1)  To remove all session connections, connected to the task.  At
            that, it is not necessary to send network primitives.
       (2)  To abnormally finish the task of the job and to deallocate all
            dynamic resources of the task.

       The instruction JOB_COMPLETED_INFO is used for the end of the job
       under the JCP initiative at the end of lifetime or at end of the JCP
       node working.  In these cases, the node initiated the job is the
       first addressee of the instruction.

       JCP considers the job completed after sending of all instructions
       JOB_COMPLETED_INFO.

    5.7    Activity Control of Nodes

       UMSP unites nodes, which have any arrangement in the network and
       which are not having uniform controls.  Each of nodes can be
       disconnected or reloaded at any moment of time.  However, other nodes

    Bogdanov                      Experimental                     [Page 38]

    RFC 3018             Unified Memory Space Protocol         December 2000

       can be not notified about it.  The fact of breaking or repeated
       establishment of transport connection cannot be the indicator of
       disconnect or restart of the node.  The control of transport
       connections is not the part of the UMSP protocol and the presence of
       transport connection is not obligatory.

       Besides the separate task on the node can be finished emergency.
       Procedure described in section 5.5.1 in this case must be executed.
       If this procedure cannot be executed, must is abnormally finished
       work of the node.

       The JCP executes the functions of the control of nodes activity.  The
       instruction of request of the status TASK_REQ is sent periodically
       between tasks on nodes and JCP for this purpose.

       The following actions JCP are possible at detection of deactivating
       of the node:

       (1)  If the task initiated the job was finished, it is considered,
            that the job is completed.  JCP sends the instruction
            JOB_COMPLETED_INFO to all other nodes, on which the job was
            executed.
       (2)  JCP sends the instruction TASK_TERMINATE_INFO to all other nodes
            of the job, if the task, which has not initiated the job, is
            finished.

       The deactivating of the JCP node imposes the restriction on GJID
       appropriated by it after reloading.  The following variants are
       probable:

       (1)  The disconnection of the JCP node passed normally.  It
            transferred to all nodes, which it has controlled, instruction
            JOB_COMPLETED_INFO.  In this case, it can appropriate anyone
            GJID after reloading.
       (2)  There is the emergency disconnect of the JCP node.  It has not
            informed all nodes about the deactivating.  In this case, it
            must guarantee after reloading, that new GJID will not concur
            witch the GJID, existing up to the reload, during two maximal
            intervals of inactivity time (which sets this JCP).

       The reload of nodes, which are not being JCP, does not impose
       restrictions on LTID established on these nodes.

    5.7.1     _INACTION_TIME

       The extension header "The time of inaction" (_INACTION_TIME) allows
       setting the inaction time of the node (non JCP).  It has the
       following values of fields:

    Bogdanov                      Experimental                     [Page 39]

    RFC 3018             Unified Memory Space Protocol         December 2000

          HEAD_CODE = 2
          HEAD_LENGTH = 1;
          HOB = 1
          DATA contains:
             2 octets: The inaction period.  The number of 0,5 second
             intervals, through which the activity of the node - sender of
             the instruction from the side JCP - will be checked.

       The inaction period must be more than three intervals of the maximal
       time of delivery at the transport layer.  The waiting period in queue
       to the transport layer does not influence on timeout.

       The header _INACTION_TIME may be attached to the following
       instructions:

       (1)  To the instruction TASK_REG.  In this case must be satisfied
            condition - on node there must not be other active tasks, which
            are controlled the JCP of addressee.  The zero-value specifies
            that the activity checking is unused.  The absence of the header
            specifies that the inaction period must be set on the JCP.
       (2)  To the instruction TASK_REJECT, if the time from the instruction
            TASK_REG does not fit for JCP.
       (3)  To the instruction TASK_CONFIRM, if instruction TASK_REG had no
            this header.

       If JCP receives the instruction TASK_REG with the attached heading
       _INACTION_TIME, it must check up presence of active tasks with sender
       node (as it can mean, that the node was reloaded).  If such tasks
       exist, for each of them it is necessary to execute procedure of end
       of the task described in section 5.6.2.  The instruction TASK_CONFIRM
       must be sent only after that.

    5.7.2     STATE_REQ

       The instruction "State Request" (STATE_REQ) is sent from JCP to the
       definite task of other node.  The instruction has the following
       values of fields:

          OPCODE = 21
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0
          OPR_LENGTH = 1/2 ; Depends on the LTID length.
          Operand:
             4/8 octets: LTID, established on the node of the instruction
                         addressee.

    Bogdanov                      Experimental                     [Page 40]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The instruction STATE_REQ will be sent in the defined task but it has
       concern with node.  It is sent, if between the node and JCP was not
       sending of the instruction during inactive time.  The task activated
       after sending of last instruction STATE_REQ does not influence the
       control of activity.

       The instruction TASK_STATE is sent in reply to STATE_REQ.  At
       expectation of the response, the timeout equal to one inaction period
       is used.  After the expiration of the timeout the node is considered
       switched - off.

       If the node not receives of any instructions from JCP during two
       intervals of inaction time, it is considered, that JCP has finished
       the work.  The actions of the node in this case are described in
       section 5.6.2 at receiving the instruction JOB_COMPLETED_INFO.  The
       check of this condition is optional for the node.

       If at JCP there are no active tasks connected with the defined node,
       the control of activity of this node will not be carried out.

    5.7.3     TASK_STATE

       The instruction "Task State" (TASK_STATE) is sent from the definite
       task to JCP.  It serves for the response of the instruction
       STATE_REQ.  The instruction has the following values of fields:

          OPCODE = 22
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0
          OPR_LENGTH = 1/2/3 ; Depends on the CTID length.
          Operands:
             1 octet:  The state code of task.  The following values are
                       defined for this field:
                %x01 - The task is active and has active session
                       connections.
                %x02 - The task is active and have no session connections.
                %x03 - The task is active, have no session connections and
                       have no resources, allocated on the node.
                %x04 - The task is completed.
             1/3 octets: Reserved.  If OPR_LENGTH = 1, then this field has
                         length 1 octet, else 3 octets. JCP must not check
                         the value of this field.  It is established in zero
                         value by sending.
             2/4/8 octets: CTID connected with LTID from the instruction
                           STATE_REQ.

    Bogdanov                      Experimental                     [Page 41]

    RFC 3018             Unified Memory Space Protocol         December 2000

       If OPR_LENGTH = 1 that length of the reserved field is equal to one
       octet and length CTID makes two octets.  In all other cases, length
       of the reserved field is equal 3 octets and length CTID - not less
       than 4 octets.

    5.7.4     NODE_RELOAD

       The instruction "The node was reloaded" (NODE_RELOAD) is sent to JCP
       as the negative response to STATE_REQ instruction.  NODE_RELOAD has
       the following values of fields:

          OPCODE = 23
          PCK = %b00
          CHN = 0
          ASK = 0
          EXT = 0
          OPR_LENGTH = 1/2 ; Depends on the LTID length.
          Operands:
             4/8 octets: LTID.  The value is taken from the instruction
                         STATE_REQ.

       The instruction RELOAD_NODE indicates, that the task with given LTID
       for given JCP on the node is absent.  At reception of this
       instruction, JCP must make the following:

       (1)  To send the instruction STATE_REQ to all tasks of the node,
            which were initiated before a sending of the penultimate
            instruction STATE_REQ.
       (2)  To wait for ending of one inaction interval after sending of the
            last instruction STATE_REQ (on which the negative response is
            received).
       (3)  To send the instructions STATE_REQ to all tasks of the node,
            which were initiated between last and penultimate instructions
            STATE_REQ (not including instructions from item 1).

       For all instructions STATE_REQ the positive response (TASK_STATE) or
       negative response (RELOAD_NODE) must be transmitted.

    5.8    Work without session connection

       The protocol provides the data exchange between nodes without an
       establishment of session connection.  In this case, initialization of
       the job and tasks is not made and JCP is not used.

       The format of the instructions, transmitted without the establishment
       of connection, is completely correspond to the instructions
       transmitted by session connections.  The difference is that the field
       SESSION_ID has zero value or PCK = %b00.

    Bogdanov                      Experimental                     [Page 42]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The node, supporting work without the establishment of session
       connection, must have VM, which executes by default the instructions
       transmitted without the establishment of connection.  In fact, these
       instructions are executed within the framework of a so-called zero-
       session (or zero-task) of this VM.  The memory address space of this
       VM is accessible without a connection establishment.

       The instruction SESSION_INIT with SESSION_ID = 0 and REQ_ID = 0
       allows to specify parameters of its zero-session and to request the
       zero-session parameters of the addressee node.  If the node, which
       has received such instruction, provides the requiring profile, it
       sends the instruction SESSION_ACCEPT.  If the profile is not
       provided, the answerback instruction SESSION_INIT will send, in which
       the field SESSION_ID and REQ_ID also have the value 0.  Actually,
       such instructions of session initialization do not establish
       connection, but have the information meaning.  The exchange of the
       data by zero-session can occur irrespective of its.

       There are the following restrictions at working without connection:

       o  The chain must be sent, only if it is completely located in one
          segment of the transport layer.
       o  It is impossible to request an allocation of memory and to create
          objects (except instruction MVRUN).  This objects is not adhered
          to the definite job and is not automatically release the resources
          at the end of the job, which has created them.
       o  Parameters of functions and the returned values must not contain
          the pointers, because the node can be reloaded at any moment.  It
          will result that the pointers will become invalid or will address
          other objects.

       The protocol cannot check those conditions.  Their realization lays
       on VM wholly.

       The work without establishment of session connection may be used in
       the following systems:

       o  In simple devices, which do not have the operational system;
       o  On servers which are executed a plenty of requests (for work
          without connection of resources is used less);
       o  In systems requiring the fast response to rare requests (if
          keeping of connection is inexpedient).

    Bogdanov                      Experimental                     [Page 43]

    RFC 3018             Unified Memory Space Protocol         December 2000

    6  Instructions of Exchange between VM

       The instructions intended for an exchange between VM uses values
       OPCODE in range 128 - 223.  Depending on length of the operands
       field, several formats of the instruction may be defined for one
       OPCODE.  The complete instruction format is defined by aggregate of
       the values of fields OPCODE and OPR_LENGTH.

       The instruction has the field REQ_ID, if in the instruction header
       flag ASK = 1.  REQ_ID is used for the response identification.  The
       value of this field is specifies by VM.  The response is formed by
       VM, too.  The protocol does not check the response and does not
       analyze the value of the field REQ_ID for the instructions of
       exchange between VM.  One of the instructions RSP, DATA, RETURN,
       ADDRESS, OBJECT or PROC_NUM is used for sending of the response.  The
       instructions of response have ASK = 1 and the value taken from the
       confirmed instruction is record in REQ_ID.  The instructions of
       response do not require the response.

       The instructions of exchange between VM may be sent through UDP at
       observance of the following conditions:

       o  ASK = 0;
       o  The instruction is located in one segment UDP;

       The timeouts and the repeated sending are not used at UMSP layer for
       instructions of exchange between VM.  It is explained to, that the
       time of sending instructions with low priority may be very large
       because of the output queues.  Therefore, the VM must make a decision
       on timeout, as only VM has the complete information on type of the
       transmitted data.  Besides, the transport layer protocol must use the
       timeouts.

       A few VM may be connected to the protocol on the node.  VM may
       simultaneously execute several jobs.  Each job may work in its
       address space.  The protocol determines VM and job, which the
       received instruction must transfer to, on field SESSION_ID value.

       The local memory address is located in the instruction in field of
       length 2/4/8 octets.  If memory address length in the instruction is
       not equal to memory address length defined for the node, the
       following variants are possible:

       o  If memory address length is set in 24 bits for the node, the
          address is writes in the end of 4 - octets field.  The 0 value
          sets in an initial (zero) octet.

    Bogdanov                      Experimental                     [Page 44]

    RFC 3018             Unified Memory Space Protocol         December 2000

       o  If the instruction format assumes the memory address length not
          less than 4 octets, 2-octet address is located in the last octets.
          The first 2 octets must set to zero.
       o  If instruction is the member of a chain and it has the less length
          of the memory address, than it is defined for the node - it is
          considered, that the base-displacement addressing is used.  If the
          value of the memory base is not assigned for the chain -
          instruction is erroneous.
       o  If the instruction is not the member of a chain and has the length
          of memory address less, than it is defined for the node, it is
          considered, that the abbreviated address is used.  The complete
          address length must be received by padding in front of it the
          necessary number of zero-value octets.
       o  In all other cases, the instruction is erroneous.

       Complete 128-bit memory address writes in operands in the 16-octets
       field.  The reason of using of the complete address is that the
       additional information, using by the memory control subsystem in the
       node, may contain in its field FREE (see section 2.1).  If the FREE
       of the complete address is set to zero, it is recommended to use
       local address in operands.

       Operands field has a length, which is an integral number of 32 bits.
       The alignment is making by padding, if necessary, of the zero-value
       octets at the end of the field.

       Header fields of the instructions not defined in the formats
       description are used according to the description from section 3.

       The instruction of the transfer control JUMP, CALL, CALL_BNUM and
       CALL_BNAME may contain the information about VM of the sender.  If VM
       type and VM version of the sender are contains in the instruction,
       the call parameters are formed in a format VM of the sender.  Else,
       the call parameters have format defined by VM of the addressee.  The
       code is always connected with of specific VM.

       All instructions of the protocol work with binary data and do not
       provide operations of formats transformation.

    6.1  Data Reading/Writing Instructions

    6.1.1   REQ_DATA

       The instruction "To request a data" (REQ_DATA) is used for the data
       request from the remote node.  Two instructions REQ_DATA with length
       of the length field 2 and 4 octets are defined.  These instructions
       have the following values of fields:

    Bogdanov                      Experimental                     [Page 45]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 130/131      ; For length of the length field of 2/4
                                  octets.
          OPR_LENGTH = 1/2/3/5  ; Depends on address length.
          Operands:
             2/4 octets: The length field. The number of the required data in
                         octets.
             2/4/8/16 octets: The memory address of the required data.

       The instruction DATA, containing required data, is sent in reply to
       it.  If the data cannot be sent, the instruction RSP with the non-
       zero basic return code, comes back.

    6.1.2   DATA

       The instruction "The data" (DATA) is sent in reply to the instruction
       REQ_DATA and OBJ_REQ_DATA.  The instruction has the following values
       of fields:

          OPCODE = 132
          OPR_LENGTH = 0 - 65535  ; Depends on the immediate data length of
                                    the operand.
          Operands:
             0 - 262140 octets: Immediate data.  If OPR_LENGTH = 0, this
                                field are absent.
          Extension headers:
             _DATA - Contains immediate data.  If OPR_LENGTH <> 0, this
                     header are absent.

       The extension header is used, if the data are more then an maximum
       operands field size.  The data must not be sent simultaneously in
       operands and in the extension header.  To make the length of data
       multiple of 4 octets, 1 - 3 zero-value octets are padded in the end
       of a field.

    6.1.3   WRITE

       The instruction "To write the data" (WRITE) is used for data writing
       on the remote node.  The instruction has the following values of
       fields:

          OPCODE = 133/134/135/136  ; For memory address length of 2/4/8/16
                                      octets.
          OPR_LENGTH = 1 - 65535    ; Depends on length of the immediate
                                      data.
          Operands:
             2/4/8/16 octets: The memory address for writing the data.
             0 - 262136 octets: Immediate data for write.

    Bogdanov                      Experimental                     [Page 46]

    RFC 3018             Unified Memory Space Protocol         December 2000

          Extension headers:
             _DATA - Contains immediate data.  This header is present only,
                     if the data does not contain in operands.

       At address length of 2 octets the data length must be 2 octets.  In
       all other cases, address length must be not less than 4 octets and
       data length must be multiple of 4 octets.  The data must not be sent
       simultaneously in operands and in the extension header.

       The instruction RSP is sent in reply to the instruction WRITE.  The
       zero basic return code defines normal executing.

    6.1.4   WRITE_EXT

       The instruction "The extension writing of data" (WRITE_EXT) is used
       for the data writing on the remote node.  Length of the data may be 1
       - 262132 octets with a step 1 octet.  The instruction has the
       following values of fields:

          OPCODE = 137
          OPR_LENGTH = 3 - 65535  ; Depends on length of the immediate data.
          Operands:
             1 octets: Always set to zero.
             3 octets: The number of the write data in octets.  The zero-
                       value is not available.
             4 - 262132 octets: Immediate data for write.  The data length
                                must be multiple of 4 octets.
             4/8/16 octets: The memory address for writing the data.

       To make the immediate data multiple of four octets, the data is
       padded with 1 - 3 zero-value octets at the end of a field.

       The instruction RSP is sent in reply to the instruction WRITE_EXT.
       The zero basic return code defines normal executing.

    6.2  Comparison Instructions

    6.2.1   CMP

       The instruction "To compare" (CMP) is used for binary data
       comparison.  It has the following values of fields:

          OPCODE = 138/139/140/141  ; For the address length of 2/4/8/16
                                      octets.
          OPR_LENGTH = 1 - 65535    ; Depends on length of the immediate
                                      data.

    Bogdanov                      Experimental                     [Page 47]

    RFC 3018             Unified Memory Space Protocol         December 2000

          Operands:
             2/4/8/16 octets: The memory address for compared data.
             2 - 262136 octets: The immediate data for the comparison.

       At the address length of 2 octets the data length must be 2 octets.
       In all other cases length of the address must not be less than 4
       octets and the data length is multiple to four octets.

    6.2.2   CMP_EXT

       The instruction "The extension compare" (CMP_EXT) is used for binary
       data comparison.  Length of the data may be 1 - 262132 octets with a
       step 1 octet.  The instruction has the following values of fields:

          OPCODE = 142
          OPR_LENGTH = 3 - 65535  ; Depends on length of the immediate data
                                    and the address.
          Operands:
             1 octet: Always set to 0.
             3 octets: The length of compared data in octets.  The zero-value
                       is not available.
             4 - 262132 octets: The immediate data for the comparison.  The
                                length of field is multiple of 4 octets.
             4/8/16 octets: The memory address of compared data.

       To make the immediate data multiple of four octets, the data is
       padded with 1 - 3 zero-value octets at the end of a field.

    6.2.3   Response to Comparison Instructions

       The instruction RSP is sent in reply to the instruction CMP, CMP_EXT
       and OBJ_CMP (see below).  If the comparison was executed, the basic
       return code is equal to zero.  The additional return code is equal to
       -1, if the data at the address memories are less then the data from
       the operand; 0, if they are equal; and 1, if they are more.  If the
       comparison cannot be executed, the basic return code of the
       instruction RSP must be non-zero.

    6.3  Control Transfer Instructions

    6.3.1   JUMP, CALL

       The "Unconditional jump" (JUMP) and "To Call-subroutine" (CALL)_
       instructions have an equal format and differ only by OPCODE.  These
       instructions have the following values of fields:

          OPCODE = 143/144  ; Correspondingly for the JUMP not containing
                              and containing the information about VM.

    Bogdanov                      Experimental                     [Page 48]

    RFC 3018             Unified Memory Space Protocol         December 2000

                   145/146  ; Correspondingly the CALL not containing and
                              containing the information about VM.
          OPR_LENGTH = 2 - 65535  ; Depends on inclusion of the information
                                    about VM, address length and parameters
                                    length.
          Operands:
             2 octets: The VM type of the sender.  If OPCODE=143/145 this
                       field is absent.
             2 octets: The VM version of the sender.  If OPCODE=143/145 this
                       field is absent.
             4/8/16 octets: The address of memory, where is necessary to
                            transfer control.
             2 octets: The number of 32 bit words in the call parameters
                       field.
             4 - 262134 octets: The immediate data are the parameters of a
                                call.

       On the reception side the processing of the instructions of a control
       transfer occurs as follows:

       o  The memory address is checked.  If it has erroneous value, the
          negative response RSP is sent.  At this stage, the correctness of
          parameters of a call may be also checked up.
       o  If the memory address and the parameters of a call have correct
          value, the positive response RSP is sent for the instruction JUMP.
          The transmitting side considers the instruction JUMP executed
          after receiving response.
       o  For response of an execution of the instruction CALL the
          instruction RETURN is sent.  The instruction RETURN may contain
          the returned values.  If there is an exception condition in a
          thread of control created by the CALL instruction, the instruction
          RSP with a non-zero basic return code is sent instead of RETURN.

    6.3.2   RETURN

       The instruction "Return of control" (RETURN) is used at return of
       control from the instructions CALL, MVRUN, CALL_BNUM and CALL_BNAME
       (see below).  Those instructions have the following values of fields:

          OPCODE = 147
          OPR_LENGTH = 0 - 65535  ; Depends on length of the immediate data.
          Operands:
             0 - 262140 octets: Immediate data returned from the subroutine.

       If it is not required to send returned value, the instruction RETURN
       does not contain operands. The data format coincides with the
       instruction, for which the response (format VM of the sender or
       addressee) will be sent.

    Bogdanov                      Experimental                     [Page 49]

    RFC 3018             Unified Memory Space Protocol         December 2000

    6.4  Memory Control Instructions

       UMSP gives means for division of memory for a code and for the data.
       The protocol does not make checks of correctness of operations with
       memory.  The code and the data use common address space.  The control
       of memory is completely realized by VM.

    6.4.1   MEM_ALLOC

       The instruction "To allocate a memory for the data" (MEM_ALLOC) is
       used for request of the allocation of memory under the data.  The
       instruction has the following values of fields:

          OPCODE = 148
          OPR_LENGTH = 1
          Operands:
             4 octets: The size of required memory in bytes.

       For the positive response on the instruction MEM_ALLOC, the
       instruction ADDRESS, for negative - RSP with the non-zero basic
       return code is sent.  The received address can be used by the
       protocol in the instructions of reading/writing, comparison and
       synchronization.

    6.4.2   MVCODE

       The instruction "To move the code" (MVCODE) is used for moving of the
       executable code from one node on another.  The instruction has the
       following values of fields:

          OPCODE = 149
          OPR_LENGTH = 1 - 65535 ; Depends on length of the code field.
          Operands:
             2 octets: The VM type of addressee.
             2 octets: The VM version of addressee.
             0-262136 octets: contains the executable code.
          The extension headers:
             _DATA - contains the executable code.  This header is present
                     only, if the code does not contain in operands.

       The code is always connected with VM of the definite type.  The code
       field is always transparent for the protocol.  It is formed by the VM
       of sender and must contain all the information necessary VM of the
       receiver.  The code must not simultaneously be sent in operands and
       in the extension header.

    Bogdanov                      Experimental                     [Page 50]

    RFC 3018             Unified Memory Space Protocol         December 2000

       For the positive response on the instruction MVCODE, the instruction
       ADDRESS, for negative - RSP with the non-zero basic return code is
       used.  The code transferred on the instruction MVCODE, may be
       executed by the instruction JUMP or CALL.

    6.4.3   ADDRESS

       The instruction "The memory address" (ADDRESS) is used for the
       positive response on the instruction MEM_ALLOC and MVCODE.  ADDRESS
       has the following values of fields:

          OPCODE = 150
          OPR_LENGTH = 1/2/4; Depends on length of the address.
          Operands:
             4/8/16 octets: The address of the allocated memory.

       For the instruction, MEM_ALLOC the address specifies first byte of
       the allocated data area.  For the instruction MVCODE the contents of
       the address is defined VM, by which the code is connected.

    6.4.4   FREE

       The memory allocated with the instructions MEM_ALLOC and MVCODE, must
       be explicitly release.  For this purpose, the instruction "To free
       the memory" (FREE) is used.  It has the following values of fields:

          OPCODE = 151
          OPR_LENGTH = 1/2/4; Depends on length of the address
          Operands:
             4/8/16 octets: the address of free memory.

       VM must free this memory automatically at end of the task on the
       node.

    6.4.5   MVRUN

       The instruction "To move and run" (MVRUN) is used for simultaneous
       move of a code and its execution.  The instruction has the following
       values of fields:

          OPCODE = 152
          OPR_LENGTH = 1 - 65535 ; Depends on length of the code field.
          Operands:
             2 octets: The addressee VM type.
             2 octets: The addressee VM version.
             4 - 262136 octets: Contains an executable code.

    Bogdanov                      Experimental                     [Page 51]

    RFC 3018             Unified Memory Space Protocol         December 2000

          The extension headers:
             _DATA - Contains an executable code.  This header is present
                     only, if the code does not contain in operands.

       The executable code is the transparent buffer with the binary data
       for the protocol.  The format of this field is defined by the VM and
       it must contain all the information necessary for the loader VM of
       the addressee, including parameters of a call.

       The code must not simultaneously be sent in operands and in the
       extension header.

       The answer to the instruction MVRUN is formed similarly to
       instruction CALL.  It is not necessary to release memory allocated
       for a code by this instruction.  The memory must deallocate the VM.

    6.5  Other Instructions

    6.5.1   SYN

       The instruction "To Synchronize" (SYN) is used for the single message
       about the data change.  The instruction has the following values of
       fields:

          OPCODE = 153/154/155 ; For length of the address 4/8/16 octets.
          OPR_LENGTH = 2 - 65535; Depends on length of the data
          Operands:
             4/8/16 octets: The memory address of the tracking data.
             2 - 131068 octets: The initial data.  Length of the data must be
                                multiple of two octets.
             2 - 131068 octets: A mask for comparison.  Length of this field
                                is equal to length of a field of the initial
                                data.

       The tracking data is set by the memory address in the first operand.
       These data are originally compared to the initial data value from the
       second operand.  If the values do not coincide, it is considered,
       that the data have changed.  The third operand allows setting a mask
       for comparison.  Set to one bits of the mask specifies bits in the
       data, which change must be traced.

       The following variants of the answer are probable on the instruction:

       o  If the address of local memory is incorrect, the instruction RSP
          with the non-zero basic return code is sent for the response.
       o  If the data do not change, in the response nothing is sent.
       o  If the data have changed, the instruction DATA with new value of
          the traced data is sent.

    Bogdanov                      Experimental                     [Page 52]

    RFC 3018             Unified Memory Space Protocol         December 2000

    6.5.2   NOP

       The instruction "No operation" (NOP) has the following values of
       fields:

          OPCODE = 156
          OPR_LENGTH = 0 - 65535
          Operands:
             0 - 262140 octets: Encapsulated data.
          Extension headers:
             Any Extension headers.

       The instruction NOP is intended for the decision of the following
       tasks:

       o  Send the control extension headers, when there are no other
          instructions for sending in a session
       o  Encapsulate the fragmented instructions and transactions with the
          established flag of special processing (see section 7).

    6.6  Work with Objects

       The protocol has a set of the instructions being expansion of the
       protocol RPC [6].  As against RPC, UMSP allows immediately to address
       memory on remote nodes and to send the pointers in parameters and
       returned values.

       The UMSP object is identified by the 4-octet number.  The values are
       divided into the following ranges:

            I -> %x00000000 - 1FFFFFFF   are assigned for standard objects
           II -> %x20000000 - 3FFFFFFF   are assigned for users objects
          III -> %x30000000 - 4FFFFFFF   free
           IV -> %x50000000 - DFFFFFFF   transient
            V -> %xE0000000 - FFFFFFFF   reserved

       The objects from a range I must be definite, as standard, and the
       specifications of their interfaces must be published.  The protocol
       does not suppose the private or not described interfaces of standard
       objects.

       The objects from a range II must be registered, but the
       specifications of their interfaces may be optional published.  These
       numbers are applied in cases, when it is required to exclude the
       probable conflict of systems of the different manufacturers.

    Bogdanov                      Experimental                     [Page 53]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The range III can be used freely.  The objects accessible on these
       numbers may be created statically or dynamically.  These objects can
       have any interfaces.

       All objects, concerning ranges I, II and III, is common for all jobs
       on the node, including zero-session.  Their interfaces are accessible
       to all tasks on the node, depending on parameters of authentication.

       The range IV is intended for objects created dynamically within the
       framework of one job.  These objects are the isolated associative
       memory of the job.  The access to these objects must be granted only
       for one job.  The zero-session has no access to these objects.

       The protocol grants the access to the data of object, as to the
       continuous segment of memory.  The memory of objects may be
       overlapping or no overlapping with flat local memory of the node.
       The offset field is used in the instructions of work with the data of
       object.  The offset rules writing are similar to the local address
       rules writing.

       The address memory length of the node, definite for the UMSP
       protocol, limits the maximal data size of one object.  The
       instructions definite in the given section, allow to work with
       associative memory with the theoretical limiting size on one node -
       2^96 (7,9 * 10^28) Byte.

       In addition to the number, the object has the version, 2 octets
       length, and realization, 2 octets length.  The protocol requires
       obligatory compatibility from bottom-up for all realizations of one
       version of object.  The publication of new realization of standard
       object may contain only added interfaces.

       If for the sender of the instruction the version and/or the
       realization of object do not play any role or is unknown, the
       instruction may contain zero fields of the version and realization of
       object or only zero field of realization.  The zero field of the
       version and non-zero field of realization are not allowed.

    6.6.1   Reading/Writing of the Objects Data

    6.6.1.1  OBJ_REQ_DATA

       The instruction "To request the data of object" (OBJ_REQ_DATA) is
       used for request of data of the Object from the remote node.  The
       instruction has the following values of fields:

    Bogdanov                      Experimental                     [Page 54]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 192/193   ; For length of the field of length 2/4 octets.
          OPR_LENGTH = 3/4/5 ; Depends on length of the offset field.
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             2/4 octets: The length of the required data in octets.
             2/4/8 octets: Offset required data from the beginning of object
                           in bytes.

       At length of the length field of 2 octets the offset length must be 2
       octets.  In all other cases, length of the length field and offset
       length must be not less than 4 octets.

       The instruction DATA, containing the required data, is sent for reply
       to instruction OBJ_REQ_DATA.  If the data cannot be transmitted, the
       instruction RSP from the non-zero basic return code comes back.

    6.6.1.2  OBJ_WRITE

       The instruction "To write the data in object" (OBJ_WRITE) is used for
       write of the data in object.  The instruction has the following
       values of fields:

          OPCODE = 194/195/196   ; For length of the offset field of 2/4/8
                                   octets.
          OPR_LENGTH = 3 - 65535 ; Depends on the data length.
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             2/4/8 octets: The offset in object for the data writes.
             2 - 262128 octets: The immediate data for write.
          The extension headers:
             _DATA - Contains immediate data for write.  This header is
                     present, only if the data is not present in operands.

       At length of the field-offset of 2 octets, length of the data must be
       2 octets.  In all other cases, the offset length must be not less
       than 4 octets and the data length is multiple to four.  The data must
       not simultaneously be sent in operands and in the extension header.

       The instruction RSP is sent in reply to the instructions OBJ_WRITE.
       The zero basic return code defines the normal execution.

    Bogdanov                      Experimental                     [Page 55]

    RFC 3018             Unified Memory Space Protocol         December 2000

    6.6.1.3  OBJ_WRITE_EXT

       The instruction "The extension writing of the data in object"
       (OBJ_WRITE_EXT) is used for write of the data in object.  Length of
       the data may be 1 - 262132 octets with the step 1 octet.  The
       instruction has the following values of fields:

          OPCODE = 197
          OPR_LENGTH = 3 - 65535; Depends on the data length and the address
                                  length.
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             1 octet: Always set to 0.
             3 octets: Length written down data in octets.  The zero-value is
                       incorrect.
             4 - 262124 octets: The immediate data for write.  Length of the
                                data is multiple of 4 octets.
             2/4/8 octets: Offset in object for the data write.

       If the length of the written down data is not multiple of four
       octets, the data is padded with 1 - 3 zero octets at the end.

       The instruction RSP is sent in reply to the instructions
       OBJ_WRITE_EXT.  The zero basic return code defines the normal
       execution.

    6.6.2  Comparison Instructions of the Objects Data

    6.6.2.1  OBJ_DATA_CMP

       The instruction "To compare the data of object" (OBJ_DATA_CMP) is
       used for binary comparison of data of the object by the immediate
       data from operands.  The instruction has the following values of
       fields:

          OPCODE = 198/199/200  ; For length of offset field of 2/4/8
                                  octets.
          OPR_LENGTH = 3 - 65535; Depends on length of the data.
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             2/4/8 octets: Offset in object for the compared data.
             2 - 262128 octets: The immediate data for comparison.

    Bogdanov                      Experimental                     [Page 56]

    RFC 3018             Unified Memory Space Protocol         December 2000

       At length of a field of 2 octets offset the data length must be 2
       octets.  In all other cases the offset length must be not less than 4
       octets and the data length is multiple to 4 octets.

       The response to the instruction OBJ_DATA_CMP is described in section
       6.2.3.

    6.6.2.2  OBJ_DATA_CMP_EXT

       The instruction "The extension compare of data of the object"
       (OBJ_DATA_CMP_EXT) is used for binary comparison of data of the
       object by the immediate data from operands.  Length of the data may
       be 1 - 262132 octets with a step 1 octet.  The instruction has
       following values of fields:

          OPCODE = 201
          OPR_LENGTH = 5 - 65535  ; Depends on length of the immediate data
                                    and the address length.
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             1 octet: Always set to 0.
             3 octets: The length of compared data in octets.  The zero-value
                       is incorrect.
             4 - 262124 octets: The immediate data for the comparison.  The
                                length of field is multiple of 4 octets.
             4/8 octets: Offset in object for the compared data.

       To make the immediate data multiple of four octets, the data is
       padded with 1 - 3 zero-value octets at the end.

       The response to the instruction OBJ_DATA_CMP_EXT is described in
       section 6.2.3.

    6.6.3   Execution of the Objects Procedures

    6.6.3.1  CALL_BNUM

       The instruction "To call the object procedure over number"
       (CALL_BNUM) transfers control to the object procedure over indication
       of the number.  The instruction has following values of fields:

          OPCODE = 202/203 ; Accordingly for the instructions not containing
                             and containing the information about VM.
          OPR_LENGTH = 4 - 65535 ; Depends on inclusion of the information
                                   about VM and call parameters length.

    Bogdanov                      Experimental                     [Page 57]

    RFC 3018             Unified Memory Space Protocol         December 2000

          Operands:
             2 octets: The VM type of the sender.  If OPCODE=202 this field
                       is absent.
             2 octets: The VM version of the sender.  If OPCODE=202 this
                       field is absent.
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             4 octets: The number of the called procedure.
             4 - 262128 octets: Parameters of the call.

       The processing on the reception side is made similarly instructions
       CALL (see section 6.3.1).

    6.6.3.2  CALL_BNAME

       The instruction "To call the object procedure over name" (CALL_BNAME)
       transfers control to the object procedure over indication of the
       name.  The instruction has following values of fields:

          OPCODE = 204/205  ; Accordingly for the instructions not
                              containing and containing the information
                              about VM.
          OPR_LENGTH = 3 - 65535 ; Depends on inclusion of the information
                                   about VM and call parameters length.
          Operands:
             2 octets: The VM type of the sender.  If OPCODE=204 this field
                       is absent.
             2 octets: The VM version of the sender.  If OPCODE=204 this
                       field is absent.
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             4 - 262128 octets: Parameters of the call.
          The extension header:
             _NAME - Contains the name of the called procedure.

       The processing on the reception side is made similarly instructions
       CALL (see section 6.3.1).

       The names may have the procedures of the objects belonging to ranges
       III and IV.  The procedures of the objects belonging to ranges I and
       II must not have a name on the UMSP layer.  They must have the number
       only.

    Bogdanov                      Experimental                     [Page 58]

    RFC 3018             Unified Memory Space Protocol         December 2000

    6.6.3.3  GET_NUM_PROC

       The instruction "To get the name of object procedure" (GET_NUM_PROC)
       allows receiving number of the procedure for objects in ranges III
       and IV over procedure name.  The instruction has following values of
       fields:

          OPCODE = 206
          OPR_LENGTH = 2
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
          The extension header:
             _NAME - Contains procedure name.

       For the positive response on the instruction GET_NUM_PROC, the
       instruction PROC_NUM, for negative - RSP with the non-zero basic
       return code is sent.

    6.6.3.4  PROC_NUM

       The instruction "The procedure number" (PROC_NUM) is sent in reply to
       the instruction GET_NUM_PROC.  The instruction PROC_NUM has following
       values of fields:

          OPCODE = 207
          OPR_LENGTH = 3
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.
             4 octets: The number of procedure.

    6.6.4   The Objects Creation

       The objects from the ranges I and II (standard and assigned for the
       user) cannot be created on the remote node through the UMSP
       interface.  These objects must be created only through API of the VM.
       The objects from the ranges III and IV can be created on the remote
       node by the protocol instructions.

       The realization of objects from the ranges I - III (not connected
       with the certain job) is difficult enough.  The reason is that the
       different jobs can have the different address spaces of memory.  The
       pointers must be processed in the context of the job, from which they
       are received.  Besides, these objects must trace the end of the jobs

    Bogdanov                      Experimental                     [Page 59]

    RFC 3018             Unified Memory Space Protocol         December 2000

       for deallocation of dynamic resources.  The specified requirements
       impose essential restrictions on these objects.  The protocol does
       not impose any restrictions on objects from the range IV.

       Unique key identifying object on node, is number of object.  To
       objects from the ranges, III and IV the name may be assigned.  The
       objects from range I and II must not have names on the UMSP layer.
       Within the framework of one task must not be two objects having one
       number or one name.

    6.6.4.1  NEW, SYS_NEW

       The format of both instructions "New object" (NEW) and "New system
       object" (NEW_SYS) is similar.  First instruction creates object in
       the range IV, second - in the range III.  These instructions have the
       following values of fields:

          OPCODE = 208/209; Accordingly for NEW/NEW_SYS.
          OPR_LENGTH = 3
          Operands:
             2 octets: The addressee VM type.
             2 octets: The addressee VM version.
             2 octets: The version of object.
             2 octets: The realization of object.
             4 - 262136 octets: Immediate data necessary for creation of
                                object.
          The extension headers:
             _DATA - Contains immediate data, necessary for creation of
                     object.  This header is present, only if the data is not
                     present in operands.
             _NAME - Contains the name of object.  This header is optional.

       The instruction NEW_SYS is used for the creation of object accessible
       from any job, NEW - for creation of object accessible only from its
       job.  If the object is created, the instruction OBJECT is sent for
       the response.  If the object cannot be created, the instruction RSP
       with the non-zero basic return code is sent.

       The immediate data field is transparent for the protocol.  It is
       formed by the sender VM and it must contain the information, which is
       necessary to the addressee VM for the creation of object.  Data must
       not simultaneously be sent in operands and in the extension header.

       The field SESSION_ID of the instruction cannot have the zero value.
       The dynamic object must be created only in the context of the
       definite job.  The object is always created on VM, with which the
       session is connected.

    Bogdanov                      Experimental                     [Page 60]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The zero values of the version and the realizations of object means,
       that the object have no these values.

       It is possible to register the name of object simultaneously with its
       creation.  The name contains in the _NAME extension header.

       All objects created upon the instructions NEW and NEW_SYS must be
       obviously deleted.  VM must automatically delete all dynamic objects,
       created and not deleted by the task, at the end of the task.

    6.6.4.2  OBJECT

       The instruction "The Object" (OBJECT) is used for the positive
       response on the instruction NEW and NEW_SYS.  The instruction OBJECT
       has following values of fields:

          OPCODE = 210
          OPR_LENGTH = 2
          Operands:
             4 octets: The number of object.
             2 octets: The version of object.
             2 octets: The realization of object.

    6.6.4.3  DELETE

       The instruction "To delete the object" (DELETE) is used for the
       deleting of object created on the instruction NEW or NEW_SYS.  The
       instruction DELETE has the following values of fields:

          OPCODE = 211
          OPR_LENGTH = 1
          Operands:
             4 octets: number of object

       The object may be deleted only from the job, which has created it.
       The instruction RSP is sent in reply to this instruction.

    6.6.5   The Objects Identification

       At registration of object on the node, it may be identify by the
       name, the length of 4 - 254 octets.  The name contains the symbols
       ASCII.  The following versions of the protocol may define other types
       of the name.

       The name identifies with the number of object and is its synonym.
       The names of all active objects in one task on the node must be
       unique.  Thus, all active objects from the range of number I - III

    Bogdanov                      Experimental                     [Page 61]

    RFC 3018             Unified Memory Space Protocol         December 2000

       must have the unique names for all tasks on the node.  The protocol
       allows receiving the number of object by the name and the name of
       object by the number.

    6.6.5.1  OBJ_SEEK

       The instruction "To seek the object" (OBJ_SEEK) is used for seek of
       number of the object by the name.  It has the following values of
       fields:

          OPCODE = 212
          OPR_LENGTH = 0
          The extension header:
             _NAME - contains the name of object for search.

       If the object is found - the instruction OBJECT is sent in the
       answer.  If the object is not found - the instruction RSP with the
       non-zero basic return code is sent for the response.

       The instruction OBJ_SEEK may be sent broadcast through UDP.  In this
       case, it concerns to zero-session.  The instruction may contain the
       field REQ_ID for identification of answers.  The positive responses
       in this case must be sent only.  The response may be transmitted
       through UDP.

    6.6.5.2  OBJ_GET_NAME

       The instruction "To get a name of the object" (OBJ_GET_NAME) is used
       for get of the name of object by number.  It has the following values
       of fields:

          OPCODE = 213
          OPR_LENGTH = 1
          Operands:
             4 octets: number of object for getting

       If the object is present - the instruction OBJECT with the extension
       header _NAME is sent for the response.  If the object is not present
       - the instruction RSP with the non-zero basic return code is sent for
       the response.

    7  Chains

       The instructions, which will be sent on one session connection, can
       be unified in a chain.  The chain is a group of the instructions
       relational with each other.  In one session, several chains
       simultaneously can be transferred.  The chains can be the following
       types:

    Bogdanov                      Experimental                     [Page 62]

    RFC 3018             Unified Memory Space Protocol         December 2000

       o  The sequence.
       o  The transaction
       o  The fragmented instruction.

       If the instruction is included into a chain, the flag CHN should be
       equal 1.  The field CHAIN_NUMBER of header contains number of a
       chain, INSTR_NUMBER - serial instruction number in a chain, since 0.
       The numbering of chains is conducted by the protocol.  In one session
       simultaneously can be transferred up to 65533 chains.  Values of
       numbers of chains %x0000 and %xFFFF reserved by the protocol.  One
       chain can contain up to 65535 instructions.

       The instruction with a zero serial number INSTR_NUMBER should contain
       the extension header describing a chain.  Each type of a chain has
       own initiating extension header.

       _END_CHAIN.  The extension header "End of the chain" is transferred
       in last instruction of chain, irrespective of type of the chain.  It
       has the following values of fields:

          HEAD_CODE = 6
          HEAD_LENGTH = 0
          HOB = 1

       Number of a finished chain contains in a field CHAIN_NUMBER of the
       instruction header, to which the extension header is attached.

       The instructions, included in chains, can be transferred through UDP
       only if all chain is located in one segment.

    7.1 Sequence

       The sequence is a type of a chain, which unites the instructions
       dependent from each other.  The following instruction of a sequence
       can be executed on VM, only if have been executed previous.  If the
       current instruction cannot be executed, all other instructions of the
       given sequence (already sent or expecting sending) simply cancel.
       Due to this, it is possible for one computing control thread not to
       wait for the current instruction positive end and to transfer
       following at once.

       _BEGIN_SQ.  The extension header "To begin a sequence" is transferred
       in the first instruction of the sequence.  It has the following
       values of fields:

          HEAD_CODE = 3
          HEAD_LENGTH = 0
          HOB = 1

    Bogdanov                      Experimental                     [Page 63]

    RFC 3018             Unified Memory Space Protocol         December 2000

       Number of created chain is established in field CHAIN_NUMBER of the
       instruction header, to which the extension header is attached.  The
       field INSTR_NUMBER must have value 0.

       The initiator of creation of a sequence is VM.  It is not obligatory
       that the sequence should have known length beforehand.  It can be
       completed in any moment.  If it is necessary to finish a sequence and
       there are no instructions for sending, the instruction NOP can be
       generated.

    7.2 Transaction

       The transaction is a type of the chain uniting some possibly not
       connected with each other instructions.  All transaction instructions
       must be executed all at once or must not be executed.  It is possible
       to cancel or to confirm transaction execute.  The transaction
       cancellation after execution is not stipulated.  If it is necessary,
       such mechanism should be realized at VM level, because there can be
       instructions in transaction, which are impossible to cancel, for
       example a control transfer.

       The initiator of transaction creation is VM.  The transaction length
       must be known beforehand.  The length will define a way of
       transaction transfer.  It is connected with buffering described in
       section 7.4.

    7.2.1   _BEGIN_TR

       The extension header "To begin a transaction" _BEGIN_TR is
       transferred in the first transaction instruction.  It has the
       following values of fields:

          HEAD_CODE = 4
          HEAD_LENGTH = 1
          HOB = 1
          DATA - Has the following format:

          +---+---+---+---+---+---+---+---+
          |TRE|TRR|TRS|      Reserve      |
          +---+---+---+---+---+---+---+---+
          |           TIME_TR             |
          +---+---+---+---+---+---+---+---+

          TRE

             1 bit.  The flag of obligatory execution.  This flag relates
             only to completely transferred, but have not yet executed
             transaction.  If TRE = 1, the transaction must be executed at

    Bogdanov                      Experimental                     [Page 64]

    RFC 3018             Unified Memory Space Protocol         December 2000

             the expiration of existence time, established by field TIME_TR,
             or at emergency session end.  If TRE = 0, at end of existence
             time the transaction must be cancelled and the negative
             acknowledgement must be transferred, and at emergency session
             end - must be simply cancelled.

          TRR

             1 bit.  The flag of execution after sending.  If TRR = 1, the
             transaction must be executed after sending of all instructions,
             of which it is consists, at once.  Such transaction is executed
             after reception of the instruction with the extension header
             _END_CHAIN.  If TRR = 0, it is necessary to transfer the
             special instruction EXEC_TR of transaction acknowledgement for
             its execution.

          TRT

             1 bit.  The flag of special processing.  It is entered for a
             possibility of the further expansion of the protocol.  If TRT =
             1, before transaction execution it is necessary to make some
             additional actions above the instructions, of which it is
             consists, for example to decipher.  These actions can be
             definite in the additional extension headers transmitted in the
             transaction instructions.  The given document will not define
             cases of use of this flag.  The value TRT must be zero.

          Reserve

             Must be set to 0.

          TIME_TR

             1 octet.  Time of transaction life in 2 - second intervals
             (maximal lifetime - 8 minutes).  The receiving side begins
             readout of this time after receiving all transaction
             instructions.  The value %x00 sets transaction without
             restriction of lifetime.

       In the last instruction of transaction the header, _END_CHAIN is
       always sent.

    7.2.2   EXEC_TR

       This instruction "To execute the transaction" (EXEC_TR) is
       transferred for execution transaction early transferred.  It has the
       following values of fields:

    Bogdanov                      Experimental                     [Page 65]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 158
          ASK = 1
          PCK = %b01/10/11
          CHN = 1
          EXT = 0/1
          CHAIN_NUMBER - Contains the number of chain, which is necessary to
                         execute.
          INSTR_NUMBER = 0
          OPR_LENGTH = 0

    7.2.3   CANCEL_TR

       The instruction "To cancel transaction" (CANCEL_TR) is transmitted
       for a cancellation of execution transaction transmitted before.  It
       has the following values of fields:

          OPCODE = 159
          ASK = 0
          PCK = %b01/10/11
          CHN = 1
          EXT = 0/1
          CHAIN_NUMBER - Contains the number of chain, which is necessary to
                         cancel.
          INSTR_NUMBER = 0
          OPR_LENGTH = 0

       The instructions, of which the cancelled transaction consists, delete
       without a possibility of restoration.

    7.3 Fragmented instruction

       UMSP is designed for work with the transport protocol with the
       limited size of transmitted data segment.  The fragmentation of the
       instructions is made in the following two cases:

       (1)  If the instruction is longer than the maximal segment size of
            transport layer or,
       (2)  If the segment is formed of the several instructions and last
            instruction is not located in it completely.

       The decision on fragmentation is taken to UMSP level.

       The fragmented instruction is encapsulated in several NOP
       instructions.  Then all instructions NOP are transmitted, as one
       chain of special type.  The following algorithm is used during
       encapsulation:

    Bogdanov                      Experimental                     [Page 66]

    RFC 3018             Unified Memory Space Protocol         December 2000

       (1)  The fields SESSION_ID and REQ_ID from the fragmented instruction
            are written in the first NOP instruction.  If field REQ_ID is
            not present in the initial instruction, it must not be in the
            NOP instruction.  The field SESSION_ID always is present in the
            fragmented instructions.
       (2)  Then these fields delete from the initial instruction.  The
            value of all other fields of the header does not change.
       (3)  After that, the initial instruction is divided into fragments of
            necessary length.  Each fragment is located in a field of
            operands of the NOP instruction.  Other data should not be
            entered in operand field.

       _BEGIN_FRG.  The extension header "The first fragment" is transmitted
       to the NOP instruction, which contains the first fragment.  It has
       the following values of fields:

          HEAD_CODE = 5
          HEAD_LENGTH = 0/2 ; Depends on subordination of the chain.
          HOB = 1
          Data:
             2 octets: Number of the parental chain.  Fragmented instruction
                       may be a part of the sequence or transaction.
             2 octets: The instruction number in the parental chain.

       The header _END_CHAIN is transmitted in NOP instruction, which
       contains last fragment.

    7.4 Buffering

       In the given item, the buffering used by the protocol on receiving of
       data is described.  The question of buffering on sending lies beyond
       the scope of the protocol.

       If the instruction is not include in a chain, it is transmitted to VM
       for execution at once and does not require buffering at the protocol
       level.  The interface UMSP - VM must provide asynchronous
       instructions sending.  It is recommended, that the productivity of
       UMSP systems, should allow to process the instructions accepted from
       network, with that speed, with what they were received.  All
       instructions are designed so that carries out the known and limited
       computing loading.  Exception is the instruction of control
       transfers, which must be processed in two stages.  The instruction
       correctness is checked firstly and its scheduling is made.  Then the
       instruction is executed.  At that must be guaranteed that the
       protocol can receive such part of processor time, which would allow
       it to work in stationary mode.  Therefore, the questions of node
       overload are deduced on VM layer and user applications layer, where
       they can be sensible controlled.

    Bogdanov                      Experimental                     [Page 67]

    RFC 3018             Unified Memory Space Protocol         December 2000

       For chains, the protocol provides two schemes of buffering during the
       receiving:

       (1)  At the session connection establishment, the sides agree about
            the allocated buffer ("window") size.  The window always is more
            than the maximal segment of a transport layer.  The transmitting
            side can expect for this buffer without the preliminary
            coordination with the receiving side.  The window size is
            established single for each session connection, and cannot be
            changed in subsequent.  UMSP is designed for using of transport
            layer, which informs about the data delivery.  Therefore
            transmitting side traces the current free size of the window on
            the reception side for each connection without assistance.  If
            the reception side finds out, that the data have been received,
            which cannot be placed in the window, the connection is broken
            off.

       (2)  For transactions and fragmented instructions, which size exceeds
            the window, it is necessary to request the reception node the
            sanctions to sending.  The theoretical limiting size of chain
            transmitting so is 4 Gbytes.

       REQ_BUF.  The instruction "To request the buffer" requests at VM the
       buffer allocation for sending of transaction or large fragmented
       instruction ("Window").  It has the following values of fields:

          OPCODE = 24
          ASK = 1
          PCK = b01/11
          CHN = 0
          EXT = 0/1
          OPR_LENGTH = 1
          Operands:
             4 octets: The buffer required size in octets.  The value is
                       equal to the total size of all instructions of the
                       chain, including the size of the subordinated chains.

       The instruction is formed under the initiative of the protocol and it
       uses the instruction RSP_P as acknowledgement.  However, on the
       reception side the buffer is allocated at VM level, as VM has the
       most complete information about the task.  The interface between UMSP
       and VM must give possibility of asynchronous request of such buffer.

       The instruction REQ_BUF can be used irrespective of the possibility
       to place the chain in the buffer, allocated for session (window).  It
       is necessary to take into account, that the negative acknowledgement
       can be transmitted on this instruction, but using of a "window"
       guarantees sending.

    Bogdanov                      Experimental                     [Page 68]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The subordinated chain on reception uses the buffer of the parental
       chain.

       The sequence sending will not require about the buffer allocation in
       difference of transaction or fragmented instruction.  If the single
       connection TCP is used for sending, the sequence buffering is not
       necessary.  If the multiple connections TCP with multiplexing are
       used, the sequence requires buffering for the disorder instructions.
       In this case, it is necessary to use the buffer, allocated for
       session.

       Transactions, at which flag TRR = 0, always must request the sanction
       for sending by instruction REQ_BUF, even if they can be placed in one
       segment of transport layer.

       The buffering of the fragmented instructions and transactions, at
       which flag TRR = 1, depends on their size:

       o  If the transaction is located in one segment of transport layer,
          it is transmitted without buffering.
       o  If length of a chain is no more then "window", it can be
          transmitted without request of the buffer of window allocation.
          Thus, the place in the buffer must be reserved before the sending
          begins.  The sending cannot be begun, if it is not enough places
          in the buffer.  In this case, it is possible to wait the window
          deallocation or to use the request instruction of the buffer
          allocation at VM REQ_BUF.
       o  If length exceeds the session window size it is necessary to use
          the instruction REQ_BUF.

    7.5 Acknowledgement of chains

       The field REQ_ID in chains of any type is established only in the
       first instruction and concerns to all chain.  The all following
       instructions, including last, do not contain REQ_ID.

       The transport protocol used for chains sending, must inform about the
       end of data transfer, because it is necessary for the transmitting
       side to know the free size of the allocated session window on the
       reception side.

       If the chain uses the allocated VM buffer (the sanction to sending
       REQ_BUF was requested), or the chain completely locates in transport
       layer segment, the protocol on the transmitting side does not trace
       acknowledgement.

    Bogdanov                      Experimental                     [Page 69]

    RFC 3018             Unified Memory Space Protocol         December 2000

       If the sequence is transmitted, the transmitting side receives the
       information about free place of the buffer on the reception side by
       acknowledgement of transport layer delivery.  It can be made, as the
       regulated sequence instructions are transmitted VM at once after
       receiving and release the buffer.

       The fragmented instructions and transactions are not transmitted VM
       until its will be completely accepted.  If session window is use, the
       occupation of places in the buffer can be calculated upon
       acknowledgement of transport layer sending.  To trace free of places
       it is necessary to check execution acknowledgement by VM.  The
       following algorithm of sending is used for this purpose:

       o  The value of field REQ_ID, which has given VM for chain sending,
          is kept and it is enters the value established by the protocol
          instead of it
       o  The new value REQ_ID is transmitted in the first instruction of
          chain
       o  The chain completely collected in the session window on the
          reception side.  After linking, it is transmitted for execution on
          VM.  At that, the chain can continue to occupy a place in the
          buffer.
       o  After execution, VM informs about it to the reception side
          protocol.
       o  The protocol clears place in the allocated buffer.
       o  Then the protocol forms and transmits on chain acknowledgement
          RSP_P, instead of RSP, as in other cases.
       o  The transmitting side protocol corrects size of free place in the
          reception side buffer after reception of acknowledgement RSP_P.
       o  Then the old value REQ_ID is restored and the acknowledgement is
          transmitted to VM.

    7.6 Base-displacement Addressing

       The memory base address for the relative addressing can be
       established for the instructions from one chain.  Thus, it is
       possible to use the abbreviated address memory fields in the
       instructions of chain.  The abbreviated addresses are used, as
       displacement from base.

       _SET_MBASE.  The extension header "To set memory base" establishes
       the value of base address for chain.  It has the following values of
       fields:

          HEAD_CODE = 7
          HEAD_LENGTH = 2/4/8   ; Depends on address length.
          HOB = 1
          DATA contains:

    Bogdanov                      Experimental                     [Page 70]

    RFC 3018             Unified Memory Space Protocol         December 2000

             4/8/16 octets: The base address.

       The length of address is 3 octets, enters the name in last octets of
       4-octets data field.  The initial octet is set to 0.  The base-
       displacement addressing is not used for nodes with address length 2
       octets.

       The value of memory base for a sequence may change.  The base must be
       established once in any instruction for all transaction instructions.
       The repeated establishment of transaction base is a mistake, which
       results refusal of transaction execution.

    8  Extension Headers

       This section contains the description of the extension headers, which
       are not connected with the definite instruction.  The description of
       the specialized extension headers describes in the appropriate
       sections of this document.

    8.1 _ALIGNMENT

       The extension header "Alignment" (_ALIGNMENT) allows to make any
       extension header or field of operands multiple of 4 - 16 octets with
       the step of two octets.  The protocol does not give any rules of use
       given extension header.  It can be used arbitrarily.  The header has
       the following values of fields:

          HEAD_CODE = 8
          HEAD_LENGTH = 1-7 ; Depends on length of the data field.
          HOB = 0
          DATA contains:
             2 - 14 octets: All octets of the field have the zero-value.

       The format of the protocol instructions provides the alignment of two
       octets field without any additional means.

    8.2 _MSG

       The extension header "The any message" (_MSG) allows sending the
       textual message in symbols ASCII.  The order of this header
       processing at receiving can be anyone.  The message can be written in
       a log-file, be shown on the console or be ignored.  The header has
       the following values of fields:

          HEAD_CODE = 9
          HEAD_LENGTH = 1 - 127 ; Depends on data length of field.
          HOB = 0
          DATA contains:

    Bogdanov                      Experimental                     [Page 71]

    RFC 3018             Unified Memory Space Protocol         December 2000

             2 - 254 octets: The any text of the message.

       The instruction may contain several headings _MSG.

    8.3 _NAME

       The extension header "The Name" (_NAME) allows specifying the job
       name, name of object or name of object procedure.  The header has the
       following values of fields:

          HEAD_CODE = 10
          HEAD_LENGTH = 1 - 127 ; Depends on length of a field of data.
          HOB = 0
          DATA contains:
             2 - 254 octets: The text of the name in symbols ASCII.

    8.4 _DATA

       The extension header "The Data" (_DATA) is used for data transfer in
       the instructions of exchange between VM, if the data cannot be placed
       in operands.  It allows transferring up to 4 Gbytes of data in one
       instruction.  The header has the following values of fields:

          HEAD_CODE = 11
          HEAD_LENGTH = 1 - 2 147 483 647 ; Depends on length of the data
                                            field.
          HOB = 1
          DATA contains:
             2 - 4 294 967 294  octets : Binary data in an any format.

    8.5 _LIFE_TIME

       The extension header "The lifetime" (_LIFE_TIME) contains value of
       time.  It has the following values of fields:

          HEAD_CODE = 12
          HEAD_LENGTH = 1/2; Depending on length of data.
          HOB = 1
          DATA contains:
             2/4 octets: The time in 1,024 milliseconds intervals.

       The header _LIFE_TIME allows to set limiting time of sending of the
       instruction to VM of the addressee.

    Bogdanov                      Experimental                     [Page 72]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The instruction lifetime is calculated as follows:

       o  On the transmitting side the time of waiting in a queue to the
          transport layer is taken into account.  The value of the lifetime
          decreases on the waiting time value now of the transport layer
          package formation.
       o  On the reception side the lifetime is taken into account only for
          the fragmented instructions.  The value of the lifetime decreases
          on time of the instruction assembly value.  This header is ignored
          at receiving for no-fragmented instructions.  Its value must be
          sent to VM.
       o  The time of sending at the transport layer is not taken into
          account.  For the fragmented instructions, only the time of
          sending of the first fragment is not taken into account.

       The end of lifetime at the instruction relating to sequence finishes
       the sequence sending.  The header _LIFE_TIME must not be used at
       transactions sending.

       If the instruction is fragmented, the header _LIFE_TIME is sent only
       in the instruction NOP, containing the first fragment.  This header
       deletes from the initial fragmented instruction.  If the time is
       over, when the fragmented instruction part has not been transmitted
       yet, the stayed part of the instruction is cleared.

       The instruction lifetime is established by the sender VM and must be
       sent together with data to the addressee VM.  If the time of life
       expires, the instruction is rejected and the negative response (if
       ASK = 1) is sent to it.  If ASK = 0, the response is not sent.

       The header _LIFE_TIME may be used in the multimedia systems and in
       the real time systems.  The protocol may raise the priority of
       sending for data with coming to the end lifetime.

    9  Search of resources

       Virtual Machines are the identified resources of the protocol.  The
       VM standardization is not function of UMSP.  The protocol gives
       transparent environment for transportation of the code and data of
       any type.

       For VM, connected to the protocol, the following values are
       established:

       o  The VM type.  The range of values 1 - 65534.
       o  The VM version.  The range of values 1 - 65534.

    Bogdanov                      Experimental                     [Page 73]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The protocol requires obligatory compatibility from bottom-up for VM
       of one type and different numbers of the versions (VM with larger
       number of version must be able to execute the VM code with any
       smaller number of version).

       Numbers of VM types are broken on the following ranges:

         1 - 1023       Assigned for standard VM
         1024 - 49151   Assigned for registered VM of the users
         49152 - 65534  Free (defined for dynamic and/or private VM)

       Numbers of types and versions %x0000 and %xFFFF are reserved by the
       protocol.

       Several VM of different types may be united in a group.  All VM,
       included in a group, must work in the common space of local memory
       and have the common subsystem of the jobs control.  It means, that if
       the same 128-bit address is met in anyone VM code for one task, it
       must specify one physical cell of memory.  The performance of the
       specified conditions allows executing multivendor user code
       (containing procedures for different VM) on one node.  All VM,
       included in a group, must have the different types.  The group can
       include no more than 65534 VM.  One number of group on different
       nodes may identify groups with different structure VM.

       To each group VM on the node the code of group of 2 octets length is
       assigned.  So long as the node has even one session connection, the
       codes of groups must not change.  It is recommended to change the
       code of group only at reconfiguration of the node.  The group VM is
       identified, as well as one VM.  Thus, the type VM is set to 0, and
       the number of group is assigned to VM version.

       The support of association VM in groups is optional requirement of
       the protocol.  The multivendor user code can be executed, even if the
       association in groups is not provided.  For this purpose, the
       procedures containing a different type of a code must be executed on
       different nodes.

       UMSP gives the instructions of search of the VM, which allow
       defining, what VM and the groups VM are connected at the given moment
       to the protocol on the definite node.

       The instructions of search of the VM can be sent upon TCP or UDP.
       The broadcasting dispatch can be used.  The node can independently
       notify about VM, available on it, for example at start, or to respond
       on others VM requests.  The answerback instructions must be sent
       under the same protocol, on which the request was received.

    Bogdanov                      Experimental                     [Page 74]

    RFC 3018             Unified Memory Space Protocol         December 2000

       VM from ranges of numbers 49152 - 65534 or any group VM may be
       identified on names.  VM with numbers 1 - 49151 must not have names
       at a layer of the instructions UMSP.

    9.1 VM_REQ

       The instruction "To request the VM" (VM_REQ) allows finding out VM,
       connected on the remote node.  The instruction has the following
       values of fields:

          OPCODE = 25
          PCK = %b00
          CHN = 0
          ASK = 0/1
          EXT = 0/1
          OPR_LENGTH = 0 - 65534 ; Depending on quantity VM in operands.
          Operands:
             2 octets: The type required VM.  The value 0 is not allowed.
             2 octets: The version required VM.  The value 0 is not allowed.
                       The value %xFFFF requests the most senior version.
             .
             .
             .

             2 octets: The type required VM.
             2 octets: The version required VM.
          The optional extension header:
             _NAME - This header contains the name of required VM or VM
                     group.

       The instruction without operands is used for request of all types VM,
       connected on the node.  The instruction with one VM in operands
       requests the information on one VM.  If it is contained several VM in
       operands, the group VM containing all specified VM is requested.  The
       type and version in list VM must be indexed on increase.

       To request VM, used at work without session connection, the VM type
       and VM version must have the value %xFFFF.

       The header _NAME is not connected with value of operands.  For it,
       the separate answer must be transmitted.

    9.2 VM_NOTIF

       The instruction "To notify about VM" (VM_NOTIF) is used for the
       notification of one VM or one VM group attached on the node.  The
       instruction has the following values of fields:

    Bogdanov                      Experimental                     [Page 75]

    RFC 3018             Unified Memory Space Protocol         December 2000

          OPCODE = 26
          PCK = %b00
          CHN = 0
          ASK = 0/1
          EXT = 0/1
          OPR_LENGTH = 1 - 65534  ; Depending on quantity VM in operands.
          Operands:
             2 octets: The used transport protocol.  The following values of
                       this field are definite:
                x0100 - Single TCP connection through the port 2110.
                x0101 - Multiple TCP connection through the port 2110.
                x0102 - Single TCP connection through ports 2110 and UDP
                        through ports on receiving 2110.
                x0103 - Multiple TCP connection through ports 2110  and UDP
                        through port on receiving 2110.
                The port 2110 must be opened on the one side or both side at
                each TCP connection.
             2 octets: Reserved.  This field must not be analyzed by the
                       protocol during the receiving in the current
                       realization of the protocol.  It must be set to 0 at
                       sending.
             2 octets: The type VM.
             2 octets: The version VM.

             .
             .
             .

             2 octets: The type VM.
             2 octets: The version VM.

          The optional extension header:
             _NAME - This header contains the name by separate VM or group VM
                     from operands of the instruction.

       It is necessary to generate several instructions, if it is required
       to inform about several VM or groups.  It is necessary to form the
       separate instructions for each protocol, if the node provides several
       transport protocols.

       If the instruction is used for the response to VM_REQ request, it can
       contain ASK = 1 and REQ_ID, established in value from the instruction
       of request.  If the VM group was requested, the instruction must
       contain several VM.  First VM must have the type set to 0 and the
       version must contain the number of group.  Others VM must define
       structure of group.  The type and version in VM list must be indexed
       on increase.

    Bogdanov                      Experimental                     [Page 76]

    RFC 3018             Unified Memory Space Protocol         December 2000

       The protocols, contained in the instruction VM_NOTIF, may differ from
       the protocol, through which this instruction is transferred.

    10 Security Considerations

       The present document contains the description of the functions,
       minimally necessary for the realization of the declared task -
       immediate access to memory of the remote node.  To reduce initial
       complexity of the protocol, the decision of safety questions is not
       included in the document.  All reasons of the given unit are the
       recommendations to the further expansion of the protocol.

       For the description three nodes are used - node A and node B are
       exchanges the data.  The node G is JCP.

       Protection against sniffing, spoofing and hijacking:

          (1) The means specifies in TCP/IP can be used.
          (2) There is a possibility to create chains with the special
              processing.  To create such chain, it is necessary to transfer
              the extension header, determining the special processing, in
              the first instruction of the chain.  The instructions of chain
              can be encapsulated in the NOP instructions.  The algorithms
              of the control of instructions sequence integrity or the
              encryption can be realized in such a way.

       Protection against the man-in-the-middle:

          The protection is based on the fact, that the routes between nodes
          A - B, A - G and G - B is not crossed.  Such scheme allows
          organizing the additional managing dataflow, allowing revealing
          such type of attack.  If the specified routes pass through one
          gateway, this protection is less effective.

       Authentication:

          The protocol working is based on a principle of the centralized
          control.  It allows using several schemes of authentication.  The
          parameters of authentication are sent in the extension headers.
          The establishment of session connection can contain up to eight
          handshakes.  It also raises flexibility at a choice of
          authentication algorithm.  The realization of authentication is
          possible between three pairs nodes A - B, A - G and G - B.  All
          pairs can be used in any combination.  The node G can be specially
          allocated for realization of authentication.

    Bogdanov                      Experimental                     [Page 77]

    RFC 3018             Unified Memory Space Protocol         December 2000

       Protection against denial-of-service:

          The instructions of the protocol have definite computing loading.
          It allows projecting the node so, that it can process the
          instructions with such speed, with what they are accepted from the
          network.  A possible reason of an overload is the instructions
          JUMP and CALL.  VM must solve this problem.  It has the complete
          information about the user task and can make a decision on the
          amount of allocated resources.  The decision of a problem is the
          failure in service for low-priority traffic.

       Protection at the applications architecture level:

          The protocol allows creating the applications of any architecture.
          It is possible due to an asymmetric structure of connection.  It
          is possible to allocate three basic groups:

          (1) The client who is carrying out terminal functions and
              client/server technologies.  The security of such systems is
              completely defined by the server.  Such architecture is
              represented most protected.
          (2) The client, loading an active code from the server.  It is the
              least protected architecture, from the client point of view.
              On the server side, there are no special requirements upon
              protection.
          (3) The client, who is executing his code on the server.  This
              architecture is safe for the client.  It is necessary to
              strengthen the protection on the server.  The functionalities
              of such architecture do not differ from architecture of
              loading by the client of an active code.  If ones take into
              account, that the server is the specially allocated computer,
              the given architecture is optimum.

              All given technologies may be used simultaneously in any
              combination.

    11 Used Abbreviations

       API    Application Programming Interface.

       CTID   JCP assigned the Control Task IDentifier to each task of the
              job.  Its length is equal to length of the local address
              memory on the node JCP.

    Bogdanov                      Experimental                     [Page 78]

    RFC 3018             Unified Memory Space Protocol         December 2000

       GJID   Globally Job IDentifier is assigned for the each job. GJID is
              defined on the JCP node.  It has the same format, as the 128 -
              bit address of node JCP memory has.  The address of local
              memory is replaced on CTID of the first (initial) task of the
              job in it.

       GTID   Globally Task IDentifier is assigned to each task.  GTID has
              the same format, as the 128 - bit address of node memory has.
              The address of local memory is replaced on LTID in it.

       JCP    Job Control Point.  This node will control the job.

       LTID   Locally Task IDentifier is assigned to each active task on the
              node.  LTID length is equal to the local memory address length
              defined for the node.

       VM     Virtual Machine.

    12 References

       [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
            9, RFC 2026, October 1996.

       [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
            Levels", RFC 2119, March 1997.

       [3]  Crocker, D., and  P. Overell.  "Augmented BNF for Syntax
            Specifications: ABNF", RFC 2234, November 1997.

       [4]  Postel, J., "Transmission Control Protocol - DARPA Internet
            Program Protocol Specification", STD 7, RFC 793, September 1981.

       [5]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
            1980.

       [6]  Srinivasan, R., "RPC: Remote Procedure Call Protocol
            Specification Version 2", RFC 1831, August 1995.

    Bogdanov                      Experimental                     [Page 79]

    RFC 3018             Unified Memory Space Protocol         December 2000

    13 Author's Address

       Alexander Y. Bogdanov

       NKO "ORS"
       22, Smolnaya St.
       Moscow, Russia 125445
       RU

       Phone: +7 901 732 9760
       EMail: a_bogdanov@iname.ru

    Bogdanov                      Experimental                     [Page 80]

    RFC 3018             Unified Memory Space Protocol         December 2000

    14 Full Copyright Statement

       Copyright (C) The Internet Society (2000).  All Rights Reserved.

       This document and translations of it may be copied and furnished to
       others, and derivative works that comment on or otherwise explain it
       or assist in its implementation may be prepared, copied, published
       and distributed, in whole or in part, without restriction of any
       kind, provided that the above copyright notice and this paragraph are
       included on all such copies and derivative works.  However, this
       document itself may not be modified in any way, such as by removing
       the copyright notice or references to the Internet Society or other
       Internet organizations, except as needed for the purpose of
       developing Internet standards in which case the procedures for
       copyrights defined in the Internet Standards process must be
       followed, or as required to translate it into languages other than
       English.

       The limited permissions granted above are perpetual and will not be
       revoked by the Internet Society or its successors or assigns.

       This document and the information contained herein is provided on an
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Bogdanov                      Experimental                     [Page 81]