rfc3018.txt

最新的RFC

    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