As per Relevance of the word following, we have this rfc below:
Network Working Group A.
Request for Comments: 3018 NKO "ORS
Category: Experimental December 2000
Unified Memory Space Protocol
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (2000). All Rights Reserved
This document specifies Unified Memory Space Protocol (UMSP),
gives a capability of immediate access to memory of the remote nodes
Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [2].
The following syntax specification uses the augmented Backus-
Form (ABNF) as described in RFC-2234 [3].
Table of
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
UMSP is the network connection-oriented protocol. It corresponds
session and presentation layers of model OSI. The protocol
designed for implementation in a wide class of systems, from
devices based on the dedicated processors, up to universal
and clusters
For the data exchange, the protocol uses transport layer service
reliable delivery. It is possible to use not providing
delivery protocol for the transmission of not
acknowledgement data. This document describes use TCP and UDP
The creation of network environment for the organization 128-
address space of memory distributed between Internet nodes is
basic purpose of the protocol UMSP. The protocol defines
of the connections management and format of network primitives.
doesn't control local memory on the node
As against the traditional network protocols, the user
on different nodes interact not by the network primitives
or working with the dataflows, but by immediate data reading/write
control transfers to the code in virtual memory of the remote node
The user's application can know nothing about existence of
protocol and network, and simply use the instructions with 128-
addresses
Firstly, it is supposed to use UMSP in systems based on the
machines (VM), executing the pseudo-code. However, the protocol
be used in systems executing a processor code, for example,
clusters or in universal operational systems, for the organization
the distributed virtual address space. Besides, the minimal
of the protocol may be used in simple devices, which do not have
operational system
The protocol gives various means for set the connection
and allows building systems with a high protection level
restriction applications functionalities
UMSP can essentially simplify the distributed systems
process. It gives an opportunity to unite not only information,
also calculating resources of the large number of polytypic
without significant expenses for the programs standardization
development
Bogdanov Experimental [Page 4]
RFC 3018 Unified Memory Space Protocol December 2000
2 The UMSP
2.1 128-bit Address
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
format
0 1 16
+------+--------------+--------------------+----------------+
|Header| FREE | NODE_ADDR | MEM_ADDR |
+------+--------------+--------------------+----------------+
Complete address length is fixed and is equal to 16 octets
1 octet. Address header field completely defines the
format. The header has the following format
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| ADDR_LENGTH | NET_TYPE | ADDR_CODE |
+-----+-----+-----+-----+-----+-----+-----+-----+
ADDR_
4 bits. The length of the network address. This
contains the number of octets in the NODE_ADDR field.
value 0 is not allowed
NET_
2 bits. The network type. This field specifies a type
network, in which the node is
ADDR_
2 bits. The length code of the local memory address.
value of this field specifies the length of the local
address. The following values of the field and appropriated
them length of the field MEM_ADDR are defined
Bogdanov Experimental [Page 5]
RFC 3018 Unified Memory Space Protocol December 2000
%b00 - 16
%b01 - 24
%b10 - 32
%b11 - 64
The values combination of the three fields of heading is
address format number. These fields unequivocally define
network, in which the node is located. Format number writes
follows
N - -
For example, N 4-0-2 defines the address with length of the
network address 4 octets and memory address with the length 32
bits. The network type 0 for such address format is defined
the network IPv4 in the presented document. If the network
is equal to zero, it may be missed during the writing of
address format number. For example, format N 4-0-2 and 4-2
equivalent. If both fields NET_TYPE and ADDR_CODE are set
zero, they may be omitted. Thus, a format number writes as
figure
One or several address format numbers must be assigned for
global network, included in unified system
0 - 12 octets. This field is unused by the protocol. It
contain any additional information, which is necessary for
control system of the node memory. If this field is not used,
zero value must be set in all octets. Using of this field
that the network instructions must contain only complete 16 -
octet address and the short address of local memory cannot
used
NODE_
1 - 13 octets. The node address. The format of this field
defined separately for each address format number. The field
the node address should not necessary precisely correspond to
real network address. If the real network address is longer
this field, it is necessary to organize in the network a subset
supporting the protocol UMSP addresses
Bogdanov Experimental [Page 6]
RFC 3018 Unified Memory Space Protocol December 2000
MEM_
16/24/32/64 bits. The address of local memory. This field is
memory address in system, which is set by a field NODE_ADDR.
node completely responds for its memory control. The
does not define the order of using and format of this field
128-bit address for the user applications is one field. The
code cannot know about a physical arrangement of addressed memory
The 128-bit memory address may be transmits between nodes, as
data, for example, in the buffer of function parameters, or in
instruction of copying the data. Therefore, it must identify
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
networks. The nodes can have internal local networks or
addressable devices connected with the node by the not-
communications. Any node by address format number must have
opportunity to define the gateway respond for routing of
address
2.2 Computing
Computing model is three-layer
(1)
(2)
(3) Thread of
The job corresponds to the user application. The job is
and can simultaneously be executed on many nodes. The job control
carried out centralize, from the node named as Job Control
(JCP). One JCP can control the some jobs. JCP can be located on
same node, on which the job is created, or on any other addressed
point
The task is the job presentation on the separate node. The
includes one or several computing threads of control. The job
only one task on each node
The job is finished, when the appropriate user application
finished. At the end of the job all tasks of this job on all
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
segmented. A segment is the local memory of one node. Besides,
protocol allows working with objects. The objects are
associative memory of the node
The task thread represents the concrete control thread, which
executed by VM in the certain node. The thread can read and write
any address of 128-bit address space of the job. The
transfer to the address from other (remote) node, results to
creation of the new thread on the remote node. The continuous
segment cannot be distributed on several nodes. In addition, it
impossible to receive continuous memory area distributed on
nodes
The protocol does not demand to support the different tasks of not
crossed memory space from the separate VM node. The supporting
multi-thread is not also the obligatory requirement
The 128-bit Global Job Identifier (GJID) is defined by protocol.
is assigned on JCP, which will control the job. All active GJID
the unique values in the unified system at each moment of time
The job can contain VM code of different types. Different types
can be situated on one or different nodes. The mechanism
association of different VM types in groups on one node
stipulated, so to the non-uniform code can be executed on one node
a context of one job. The groups are described in details in
9. VM, incorporated in groups, must work in common memory space (
have a common subsystem of memory control).
Bogdanov Experimental [Page 8]
RFC 3018 Unified Memory Space Protocol December 2000
2.3 System
System structure, based on using Virtual Machines, is given in
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
is not network level. Last network level is UMSP. Therefore,
layer has no its own network primitives and uses together with
the same field of operation code
The end services user of the protocol is the user code, which
executed by the virtual machine. It has the instructions with
128-bit address. VM translates these instructions to
commands, which are transmitted through the UMSP protocol for
executing by the remote machine. Internal organization VM,
system and API can be anyone. The protocol defines only format
primitives, which the virtual machines exchange through a network
The protocol does not control the jobs memory. Control of
should realize VM. If a few VM works on one node, they may have
common memory space or may be completely isolated
UMSP uses the transport layer with reliable delivery for the
exchange. This document defines of using TCP. For the transfer
not requiring acknowledgement data may be used UDP. Thus,
connection through TCP is obligatory. Use of multiple
TCP with multiplexing is supposed. The control of
connections is not the part of the UMSP protocol
The UMSP instructions do not contain network addresses of
receiver and sender. The protocol requires that one address
must correspond to the one transport layer address. Accordingly,
is necessary to define unequivocal the node address on
layer by the 128-bit address of memory
Except the TCP, it is possible to use other transport protocols
not network communications. The following requirements are showed
them
o Reliable delivery. The transport layer must inform
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
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
is necessary for it only when it executes the instructions with
128-bit address, concerning to other node. VM can execute
Bogdanov Experimental [Page 10]
RFC 3018 Unified Memory Space Protocol December 2000
user tasks. Each task can contain several threads of control.
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
session connections for the different jobs simultaneously between
nodes. Besides, the protocol provides the connectionless
exchange
The exchange between UMSP nodes can include the instructions of
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
objects and execution of objects procedures
UMSP does not trace the user control threads. VM must provide
the necessary order of performance of the instructions
The length of UMSP instructions does not depend on segment length
the transport layer. The segmentation is provided for transfer
the long instructions. The packing of the short instructions in
segment with a possibility of compression of headings is used for
transfer. The minimal size of necessary for work segment is 6
octets. For realization of all functions, it is necessary 54 octets
3 Instruction
The UMSP instruction includes the basic header, extension headers
operands. All fields have variable length
+----------------+----------------------+------------------------+
| Header | Extension headers | Operands |
+----------------+----------------------+------------------------+
The header contains operation code and the information necessary
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
for maintenance of the effective protocol work in wide range
network speeds. Besides, there is a simple algorithm of the
compression
The all instructions and extension headers the identifiers are
which enter the name by upper case symbols. The identifiers of
instructions begin with the letter. The identifiers of the
headers begin with underlining symbol
3.1 Instruction
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 +
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1 octet. The operation code. Value of this field is identified
the instruction. Values of operation codes are divided into
following intervals
1 - 112 management
113 - 127
128 - 223 instructions of exchange between
0, 224, 255
Bogdanov Experimental [Page 12]
RFC 3018 Unified Memory Space Protocol December 2000
1 bit. The flag of response necessity. This flag
presence of field REQ_ID in header. If ASK = 1, there is
REQ_ID in the instruction. If EXT = 0, the field REQ_ID in
instruction are absent
2 bits. The Header compression attribute. These bits are
for packing instructions headers transmitted on one connection
or for sending of the several instructions in one package UDP
Use of these bits is based on the assumption that two following
succession instructions concern to one session connection, or
chain, with a high probability. The PCK bits have one of
following values
%b00 - The instruction does not belong to the definite session
The fields CHAIN_NUMBER, INSTR_NUMBER and SESSION_ID
absent in header of such instruction
%b01 - The given instruction concerns to the same
connection, as previous. The field SESSION_ID in
instruction header is absent
%b10 - The given instruction belongs to the same connection
same chain, as previous. The fields CHAIN_NUMBER
INSTR_NUMBER and SESSION_ID in header of such
are absent. The INSTR_NUMBER value of the
instruction calculates by addition of one to INSTR_
value of the previous instruction
%b11 - The given instruction may does not concern to the
session, as previous. The field SESSION_ID is present
it. The presence of fields CHAIN_NUMBER and INSTR_
is defined by CHN flag
1 bit. The flag of chain. Transmitted on one session
and concerning one job instructions, may be unified in a chain
Chains are considered in details by section 7. If SEQ = 1,
instruction is connected with chain and there are
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
there are no fields CHAIN_NUMBER and INSTR_NUMBER in it
Bogdanov Experimental [Page 13]
RFC 3018 Unified Memory Space Protocol December 2000
1 bit. The flag of extension headers presence in the instruction
If EXT = 1, there is one or more extension headers in
instruction. If EXT = 0, the extension headers in the
are absent
OPR_
3 bits. The number of 32 bit words in the operands field.
value 0 defines absence of operands field. The value %b111
specifies use of the extended header format. In the
format, the length of operands is defined by the
OPR_LENGTH_EXT, and the field OPR_LENGTH is not used
OPR_LENGTH_
2 octets. The number of 32 bit words in the operands field.
field OPR_LENGTH_EXT is present in header, only if OPR_LENGTH =
%b111. If OPR_LENGTH < > %b111, the field OPR_LENGTH_EXT
absent. If OPR_LENGTH_EXT = 0, the field of operands is absent
There are following reasons, on which it is necessary to use
OPR_LENGTH_EXT instead of OPR_LENGTH
(1) If operands length must be more than 24
(2) If making the fields alignment of 4 octets is
effective, than compression of header of 2 octets
CHAIN_
2 octets. The number of chain. This field contains number
chain, to which the given instruction concerns. The values %x0000
and %xFFFF are reserved
INSTR_
2 octets. The instruction number. This field contains the
number of instruction in a chain. The numbering begins with zero
Value %xFFFF is reserved
SESSION_
4 octets. It is the identifier of the session connection
by the instruction receiver. During the session
opening, each side sets its own identifier to connection
informs it to other side. The zero value of this field
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_
4 octets. The request identifier. It is uses for
of correspondence between requests and responds to it
Further, the identifier OPR_LENGTH is used at the description of
instructions format. It means using of OPR_LENGTH_EXT field,
OPR_LENGTH = %b111. The instruction with length of operands,
are not exceeding 24 octets, may be transmitted with header in
short format (OPR_LENGTH < > %b111) or in the extended
(OPR_LENGTH = %b111). Both forms are equivalent
Minimal header length in the short format is 2 octets, in
extended format - 4 octets. Maximal header length is 16 octets
3.2 Extension
If the EXT flag in the instruction header set to 1, the
contains from one up to thirty extension headers. The
headers are used for the following purposes
o For sending of the service information which were not provided
the basic header
o For sending of the data of length more than 262240 octets in
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
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_
and HEAD_LENGTH_EXT
HEAD_
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
complete length field
HEAD_LENGTH_
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
complete length field
1 bit. The flag of last header. It is set to 1 for
extension header in the instruction. In other extension headers
this flag is set to 0.
1 bit. The flag of obligatory processing. It defines the
of the instruction processing, if the receiving node does not
purpose of the extension header or cannot process it by
reason. If HOB = 1, instruction must not be carried out. If
= 0, it does not influence on the instruction processing.
protocol must process all extension headers, irrespective
errors presence
1 bit. The field is reserved for the future expansions.
field must not be analyzed by the protocol on receiving. It
be set to 0 at sending
HEAD_
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
senior bits of the header code
Bogdanov Experimental [Page 16]
RFC 3018 Unified Memory Space Protocol December 2000
HEAD_CODE_
1 octet. If HXT = 0, this field is absent. If HXT = 1, it is
younger bits of the header code
2 octets. If HXT = 0, this field is absent. If HXT = 1,
field is reserved for further use. The field RESERVED must not
analyzed by the protocol during the receiving in the
realization of the protocol. It must be set to 0 at sending
The data field of the extension header. If HXT = 0, the length
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
value of the header code
On the receiving side, the extension headers must be processed
that order, in what they follow in the instruction. If
instruction contains more than 30 extension headers, it is
erroneous. It is necessary to break off the session connection,
which it was transmitted, after the reception of such instruction
The identifiers HEAD_LENGTH and HEAD_CODE are used further in
text at the description of the extended headers format. It
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
sent in short (HXT = 0) and in extended (HXT = 1) format
3.3 Instruction
The operands field contains the instruction data. The length
operands field is showed in OPR_LENGTH or OPR_LENGTH_EXT and it
multiple to four octets. If necessary, 1 - 3 zero-value octets
padded in the end of a field. Maximal length of operands is 262140
octets. The extension headers are used, if the instruction
contain longer data
The format of the operands field is defined separately for
instruction
3.4 Address
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is not used by the protocol
IP
It sets the node address in the global IPv4 network
Bogdanov Experimental [Page 18]
RFC 3018 Unified Memory Space Protocol December 2000
Local memory
It is described in section 2.1.
IP-address defines the nodes of the given type unequivocally.
TCP is used for the interaction with such nodes. For sending of
requiring response instructions, using UDP is allowed. IANA
assigned ports TCP and UDP 2110. This port must be open for
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
The protocol instructions are divided into two types
(1) The management instructions transmitted on UMSP layer (
= 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
protocol in the instructions of the first type, and it is
by VM for the instructions of the second type
o The protocol must analyze the field REQ_ID and compare it with
instructions, transmitted earlier, after receiving of the
instruction of the first type
o The protocol must not analyze the field REQ_ID after receiving
the response instruction of the second type. This instruction
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
confirmed instruction is written into the field REQ_ID. The
instruction does not require response
A few VM can be connected to the protocol on the node. Everyone
can work in its own address space. The identifiers of requests
different VM can coincide. Therefore, instruction is identified
two fields
o The session identifier SESSION_ID, which is connected
definite VM
o The request identifier REQ_ID
Bogdanov Experimental [Page 19]
RFC 3018 Unified Memory Space Protocol December 2000
4.1 RSP, RSP_
"Response" (RSP) and "Response of the protocol" (RSP_P)
have the identical format. The difference is only in the
code
OPCODE = 129/1 ; correspondingly to RSP/RSP_
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
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
additional return codes
The zero basic return code is used for positive response.
additional return code may have non-zero value
The instruction with non-zero basic return code is used for
response. The basic return code defines the error category.
additional return code identifies an error
The instruction RSP is formed upon the VM request. The return
must be received from VM. If the protocol cannot deliver
requiring response instruction to VM, it forms negative response
independently
The instruction RSP_P is always formed at the UMSP layer. If
protocol cannot define on what instruction the RSP_P is transmitted
nothing actions is executed
4.2 SND_
There can be a necessity to cancel sending after the part of the
have been already transmitted and have occupied the buffer on
reception side, by sending of the long fragmented instructions
transactions. The protocol provides the instruction "The sending
canceled" (SND_CANCEL) for this purpose. This instruction has
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
transmitted transaction or fragmented instruction. At the
the SND_CANCEL instruction, all the earlier received data in
chain are rejected
5 Jobs
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
the decentralized system. Any task can be finished at any moment
the node can be reloaded. There is no way guaranteeing
notification about in the decentralized system all other nodes,
which the job works. As the job continues to exist - the
concerning the job can be initiated on the same node again.
task can allocate new dynamic resources. The addresses for the
allocated resources can be crossed with addresses of resources,
existed on the node before the task restart. The old pointers can
kept on other nodes. It may be the formally correct pointers,
they will actually specify other objects. The uncontrollable work
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,
nodes, on which the job is executed, are notified of it
o The repeated task initialization on the node is allowed, while
nodes will receive the message about the first task end
The protocol does not control the pointers. VM supervises
pointers correctness. VM must have architecture, in which 128 -
pointers are stored in special memory areas, for this purpose.
protocol informs VM about the nodes, on which task have finished
work. VM must make all pointers concerning such tasks, invalid.
results in exclusive situations at the access under these pointers
If the application provides processing exceptions, it keeps
capacity for work, or it is finished emergency. Such decision
excluding unguided applications working
For the decision of the specified questions at UMSP level,
control job node is defined for each job. It names Job Control
(JCP). It may be the same node, on which the job is initiated, or
can be another dedicated node. The basic JCP function is to
the initialization and the end of the job tasks. Besides,
dedicated JCP node may be used for the centralized
identification and the attack protection
The following identifiers are definite for the jobs and
control
o Locally Task Identifier (LTID) is assigned to each active task
the node. LTID length is equal to the length of local
address defined for the node. All LTID on the node must
unique values at each moment of time. It is allowed to
LTID, used earlier in the already completed tasks, for the
initiated tasks
o JCP assigned the Control Task Identifier (CTID) to each task
the job. Its length is equal to length of the local
memory on the node JCP. All CTID on the JCP must give
values at each moment of time. As against LTID, the CTID value
chosen with some restrictions
o Globally Task Identifier (GTID) is assigned to each task.
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.
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
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
the definition JCP, which controls the job
LTID and CTID are written at the instructions in the field of
2/4/8 octets. If the allocated for identifier field in
instruction is longer than identifier, LTID (CTID) writes in the
octets. In the initial octets, the value 0 must be written.
received LTID (CTID) is shorter than the local memory address, it
necessary to pad it with the zero octets in the beginning
GTID and GJID are written at the instructions in the field of
4-16 octets. The field FREE is not present at these identifiers (
section 2.1). It is considered, that it contains the zero-
octets. Length of the identifier is defined in header of
address
By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN
the protocol uses timeout. The value of timeout is assigned by
and must be more than three intervals of the maximal time of
at the transport layer. The timeout is not influenced the
period in queue to the transport layer
5.1 Job
The job concerns to the user application executed on VM. The
job initialization can be made simultaneously with the
user start or during its working
The task, appropriated to its job, is initialized on the
together with the job. LTID is binding to this task
If the node, on which the user application was loaded, is chosen
JCP, the question of the job initialization lays beyond the scope
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-
or overloaded channel. It is undesirable to send the
traffic
o The node has no computing possibilities for conducting
managing tables
o The authentication on the detailed node is necessary
If the other node is chosen for JCP, the node, that initiates
job, must register the job at JCP
Bogdanov Experimental [Page 23]
RFC 3018 Unified Memory Space Protocol December 2000
5.1.1 CONTROL_
The instruction "To request a control" (CONTROL_REQ) is sending
the node, initial the job, to JCP of other node. The instruction
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
then will be sent in the response
Operands
4 octets: The control parameters profile. This field has
following format
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ JOB_LIFE_TIME +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| CMT | Reserved | VERSION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
JOB_LIFE_
2 octets. The job lifetime in seconds. The zero-
signifies that the restriction of the job lifetime
unused
1 bit. The flag of several JCP using. This field
reserved for the future expansion of the protocol
1 octet. The number of the UMSP version. It
contain the value 1.
Bogdanov Experimental [Page 24]
RFC 3018 Unified Memory Space Protocol December 2000
3 + 8 bits. All bits must be set to 0.
4/8 octet: LTID of task of the job, assigned on the node,
initiate the job (by the sender of
instruction).
The optional extension headers
_JOB_NAME - This header contains the name of the Job.
assigned once and must not change further
_INACT_TIME - This header contains the inaction time (
section 5.7).
At reception of the CONTROL_REQ instruction JCP checks the LTID
from the received instruction and makes the following
(1) If the node, which has sent CONTROL_REQ, already has
on JCP the active job with such LTID, the notification
abnormality end of the registered job is sent, as is described
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
the new job initiation at once
If JCP confirms the control, it will send the
CONTROL_CONFIRM, or else CONTROL_REJECT
5.1.2 CONTROL_
The instruction "To confirm the control" (CONTROL_CONFIRM) is
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
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_
Operands
4-16 octets: The GJID assigned to the job on the JCP
The sending of the instruction CONTROL_REQ means request of
and request of task initiation. Assigned to the task CTID is
GJID (field of the local memory address).
Bogdanov Experimental [Page 25]
RFC 3018 Unified Memory Space Protocol December 2000
5.1.3 CONTROL_
The instruction "To reject the control" (CONTROL_REJECT) is sent
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
specifies presence of the REQ_ID field
EXT = 0/1
OPR_LENGTH = 1/2 ; Depends on presence of the control
profile field
REQ_ID - The value is taken from the instruction CONTROL_
Operands
2 octets: The basic error code. The zero-value is
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 (
section 5.7).
_MSG - contains the arbitrary error description
5.2 Task
The job is executed on several nodes simultaneously. The task
appropriate to it, must be initialized on each node. There
corresponding only one task to one job on the node. Each task
be connected only with one job
The task is initiated together with the job on the node, which
created the job. On the other nodes, the task is initiated
the receiving of the first request on the opening of the
connection, which is appropriate to the job. The request
openings of session connection contains GJID. GJID contains the
address. It is necessary to receive the sanction from JCP for
task start. If the request about the opening of session has
received from JCP node, it is not necessary to request the sanction
5.2.1 TASK_
The instruction "To register a task" (TASK_REG) is sent from
node, which initials the task, to JCP of the remote node.
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
then will be sent in the response
Operands
2/4/8 octets: CTID of the task initiated the job. It CTID is
part GJID from the instruction SESSION_OPEN
4-16 octets: GTID, assigned on the node, initialed
connection. GTID is formed of sender addresses (
transport layer) and field LTID of the
SESSION_OPEN
2/4/8 octets: LTID, assigned on the node, initialed the
(by the sender of this instruction).
The optional extension headers
_INACT_TIME - This header contains the inaction time (
section 5.7).
The instruction TASK_REG must be sent only if the task with
GJID was not initiated on the node
JCP confirms initiation of a task at observance of the
conditions
(1) Task with received GTID already has registered on JCP
(2) Task with LTID for the node requesting for initiation has
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_
The instruction "To confirm the task" (TASK_CONFIRM) is sent from
as the positive response to TASK_REG. TASK_CONFIRM has the
values of fields
OPCODE = 9
PCK = %b00
CHN = 0
ASK = 1. The instruction does not need to be responded. This
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_
The instruction "To reject the task" (TASK_REJECT) is sent from
as the negative response to TASK_REG instruction. TASK_REJECT
the following values of fields
OPCODE = 10
PCK = %b00
CHN = 0
ASK = 1. The instruction does not need to be responded. This
specifies presence of the REQ_ID field
EXT = 0/1
OPR_LENGTH = 1
REQ_ID - The value is taken from the instruction CONTROL_
Operands
2 octets: The basic error code. The zero-value is
available
2 octets: The additional error code
The optional extension headers
_INACT_TIME - This header contains the inaction time (
section 5.7).
_MSG - contains the arbitrary error description
5.2.4 TASK_
With the purposes of a safety the node, which have received
about the opening of session connection, may check up at JCP
node, which has initialed connection, even if the task was
initiated
The instruction "To check up the task" (TASK_CHK) is sent from
node, which has received the instruction of the establishment
session connection SESSION_OPEN, to JCP. The task with given GJID
must have existed on the node already. The instruction TASK_
format coincides with TASK_REG. OPCODE = 11. The response to
instruction TASK_CHK JCP forms instructions TASK_REG similarly
JCP confirms the instruction TASK_CHK if a task with received
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
The session connection is established between two tasks of one job
The connection is established under the VM initiative and it is
for the exchange of the instructions between VM
One session connection must be connected only with one task on
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
the global identifier of the job GJID. If the node receives
request about the establishment of connection with GJID, which is
presented on the given node, VM must create a new task. If the
has been already initialized, the new task is not created
The session connection needs to be established over TCP. After
connection is established, the sending of the instructions, which
not require of execution response, is possible through UDP. One
connection may be used by several session connections. One
connection may use several TCP connections
The protocol allows working without the establishment of
connection. The node must have VM by default, which must execute
instructions without the establishment of connection
At the establishment of session connection, the sides agree about
used VM type and the subset of the protocol functions. The
connection UMSP may be asymmetrical. It means, that two sides of
connection can be connected with VM of the different type and
the different subset of the protocol functions
If at an establishment of session connection the zero-type VM
used, it specifies group VM (see section 9). The zero-value
realization VM is not allowed
The procedure of the establishment of session connection may
from 2-way up to 8-way handshakes
5.3.1 SESSION_
The instruction "To open a session" (SESSION_OPEN) is used for
initiation of session connection and for the specification
connection parameters during handshake. It has the following
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
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
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
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
sender
2 octets: The number of 256 octet blocks in the buffer
allocated for session ("window"), on the side of
sender of this instruction (see section 7.4).
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
instruction TASK_REG (as a part of the field GTID).
If the VM type and version, required from the addressee, have
value 0, the receiving node independently chooses the VM type
reports it in the response. The establishment of connection
binding to VM or VM group is not allowed
Totally, it can be transmitted up to 7 instructions SESSION_OPEN
the establishment of connection. The instruction SESSION_ACCEPT
used for the response of the establishment of connection. For
refusal of connection the instruction, SESSION_REJECT is used
It is possible to refuse connection on any step. It is
either to confirm connections, or to refuse it on the eighth step
During the establishment of connection the following parameters
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
received from the definite node, while one connection with
GJID have been already established, the following variants
possible
(1) If the request has arrived from the node JCP, it is necessary
o To finish the existing task emergency and to deallocate
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
refuse the establishment of new session connection. The
task does not need to be changed
5.3.2 SESSION_
The instruction "To accept the session" (SESSION_ACCEPT) is used
positive response to the establishment of session connection. It
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
of assigned by the node of the addressee of
instruction
REQ_ID - This field 