tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3018


Unified Memory Space Protocol Specification

Part 4 of 4, p. 62 to 81
Prev RFC Part


prevText      Top      Up      ToC       Page 62 
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

Top      Up      ToC       Page 63 
   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

Top      Up      ToC       Page 64 
   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

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             |


         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

Top      Up      ToC       Page 65 
         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.


         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.


         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.


         Must be set to 0.


         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:

Top      Up      ToC       Page 66 
      OPCODE = 158
      ASK = 1
      PCK = %b01/10/11
      CHN = 1
      EXT = 0/1
      CHAIN_NUMBER - Contains the number of chain, which is necessary to
      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
      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

Top      Up      ToC       Page 67 
   (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
         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.

Top      Up      ToC       Page 68 
   For chains, the protocol provides two schemes of buffering during the

   (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

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

Top      Up      ToC       Page 69 
   The subordinated chain on reception uses the buffer of the parental

   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

   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

Top      Up      ToC       Page 70 
   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
   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
   o  After execution, VM informs about it to the reception side
   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

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

Top      Up      ToC       Page 71 
         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

   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.


   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:

Top      Up      ToC       Page 72 
         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
      HOB = 1
      DATA contains:
         2 - 4 294 967 294  octets : Binary data in an any format.


   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.

Top      Up      ToC       Page 73 
   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

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

Top      Up      ToC       Page 74 
   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

   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.

Top      Up      ToC       Page 75 
   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.
         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

   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.


   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:

Top      Up      ToC       Page 76 
      OPCODE = 26
      PCK = %b00
      CHN = 0
      ASK = 0/1
      EXT = 0/1
      OPR_LENGTH = 1 - 65534  ; Depending on quantity VM in 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
         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.

Top      Up      ToC       Page 77 
   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.


      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.

Top      Up      ToC       Page 78 
   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
      (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

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.

Top      Up      ToC       Page 79 
   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

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

Top      Up      ToC       Page 80 
13 Author's Address

   Alexander Y. Bogdanov

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

   Phone: +7 901 732 9760

Top      Up      ToC       Page 81 
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

   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


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