rfc1045.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,491 行 · 第 1/5 页

In overview, VMTP provides transport communication between network-
visible entities via message transactions.  A message transaction
consists of a request message sent by the client, or requestor, to a
group of server entities followed by zero or more response messages to
the client, at most one from each server entity.  A message is
structured as a message control portion and a segment data portion.  A
message is transmitted as one or more packet groups.  A packet group  is
one or more packets (up to a maximum of 32 packets) grouped by the
protocol for acknowledgment, sequencing, selective retransmission and
rate control.

Entities and VMTP operations are managed using a VMTP management
mechanism that is accessed through a procedural interface (RPC)
implemented on top of VMTP.  In particular, information about a remote
entity is obtained and maintained using the Probe VMTP management
operation.  Also, acknowledgment information and requests for
retransmission are sent as notify requests to the management module.
(In the following description, reference to an "acknowledgment" of a
request or a response refers to a management-level notify operation that
is acknowledging the request or response.)


2.1. Entities, Processes and Principals

VMTP defines and uses three main types of identifiers:  entity
identifiers, process identifiers and principal identifiers, each 64-bits
in length.  Communication takes place between network-visible entities,
typically mapping to, or representing, a message port or procedure
invocation.  Thus, entities are the VMTP communication endpoints.  The
process associated with each entity designates the agent behind the
communication activity for purposes of resource allocation and
management.  For example, when a lock is requested on a file, the lock
is associated with the process, not the requesting entity, allowing a
process to use multiple entity identifiers to perform operations without
lock conflict between these entities.  The principal associated with an
entity specifies the permissions, security and accounting designation
associated with the entity.  The process and principal identifiers are
included in VMTP solely to make these values available to VMTP users
with the security and efficiency provided by VMTP.  Only the entity
identifiers are actively used by the protocol.

Entity identifiers are required to have three properties;

Uniqueness      Each entity identifier is uniquely defined at any given
                time.  (An entity identifier may be reused over time.)

Stability       An entity identifier does not change between valid


Cheriton                                                        [page 7]



RFC 1045                       VMTP                        February 1988 


                meanings without suitable provision for removing
                references to the entity identifier.  Certain entity
                identifiers are strictly stable, (i.e. never changing
                meaning), typically being administratively assigned
                (although they need not be bound to a valid entity at
                all times), often called well-known identifiers.  All
                other entity identifiers are required to be T-stable,
                not change meaning without having remained invalid for
                at least a time interval T.

Host address independent
                An entity identifier is unique independent of the host
                address of its current host.  Moreover, an entity
                identifier is not tied to a single Internet host
                address.  An entity can migrate between hosts, reside on
                a mobile host that changes Internet addresses or reside
                on a multi-homed host.  It is up to the VMTP
                implementation to determine and maintain up to date the
                host addresses of entities with which it is
                communicating.

The stability of entity identifiers guarantees that an entity identifier
represents the same logical communication entity and principal (in the
security sense) over the time that it is valid.  For example, if an
entity identifier is authenticated as having the privileges of a given
user account, it continues to have those privileges as long as it is
continuously valid (unless some explicit notice is provided otherwise).
Thus, a file server need not fully authenticate the entity on every file
access request.  With T-stable identifiers, periodically checking the
validity of an entity identifier with period less than T seconds detects
a change in entity identifier validity.

A group of entities can form an entity group, which is a set of zero or
more entities identified by a single entity identifier.  For example,
one can have a single entity identifier that identifies the group of
name servers.  An entity identifier representing an entity group is
drawn from the same name space as entity identifiers.  However, single
entity identifiers are flagged as such by a bit in the entity
identifier, indicating that the identifier is known to identify at most
one entity.  In addition to the group bit, each entity identifier
includes other standard type flags.  One flag indicates whether the
identifier is an alias for an entity in another domain (See Section 2.2
below.).  Another flag indicates, for an entity group identifier,
whether the identifier is a restricted group or not.  A restricted group
is one in which an entity can be added only by another entity with group
management authorization.  With an unrestricted group, an entity is
allowed to add itself.  If an entity identifier does not represent a


Cheriton                                                        [page 8]



RFC 1045                       VMTP                        February 1988 


group, a type bit indicates whether the entity uses big-endian or
little-endian data representation (corresponding to Motorola 680X0 and
VAX byte orders, respectively).  Further specification of the format of
entity identifiers is contained in Section 3.1 and Appendix IV.

An entity identifier identifies a Client, a Server or a group of
Servers <1>.  A Client is always identified by a T-stable identifier.  A
server or group of servers may be identified by a a T-stable identifier
(group or single entity) or by strictly stable (statically assigned)
entity group identifier.  The same T-stable identifier can be used to
identify a Client and Server simultaneously as long as both are
logically associated with the same entity.  The state required for
reliable, secure communication between entities is maintained in client
state records (CSRs), which include the entity identifier of the Client,
its principal, its current or next transaction identifier and so on.


2.2. Entity Domains

An entity domain is an administration or an administration mechanism
that guarantees the three required entity identifier properties of
uniqueness, stability and host address independence for the entities it
administers.  That is, entity identifiers are only guaranteed to be
unique and stable within one entity domain.  For example, the set of all
Internet hosts may function as one domain.  Independently, the set of
hosts local to one autonomous network may function as a separate domain.
Each entity domain is identified by an entity domain identifier, Domain.
Only entities within the same domain may communicate directly via VMTP.
However, hosts and entities may participate in multiple entity domains
simultaneously, possibly with different entity identifiers.  For
example, a file server may participate in multiple entity domains in
order to provide file service to each domain.  Each entity domain
specifies the algorithms for allocation, interpretation and mapping of
entity identifiers.

Domains are necessary because it does not appear feasible to specify one
universal VMTP entity identification administration that covers all
entities for all time.  Domains limit the number of entities that need
to be managed to maintain the uniqueness and stability of the entity

_______________

<1>   Terms such as Client, Server, Request, Response, etc.  are
capitalized in this document when they refer to their specific meaning
in VMTP.


Cheriton                                                        [page 9]



RFC 1045                       VMTP                        February 1988 


name space.  Domains can also serve to separate entities of different
security levels.  For instance, allocation of a unclassified entity
identifier cannot conflict with secret level entity identifiers because
the former is interpreted only in the unclassified domain, which is
disjoint from the secret domain.

It is intended that there be a small number of domains.  In particular,
there should be one (or a few) domains per installation "type", rather
than per installation.  For example, the Internet is expected to use one
domain per security level, resulting in at most 8 different domains.
Cluster-based internetwork architectures, those with a local cluster
protocol distinct from the wide-area protocol, may use one domain for
local use and one for wide-area use.

Additional details on the specification of specific domains is provided
in Appendix IV.


2.3. Message Transactions

The message transaction is the unit of interaction between a Client that
initiates the transaction and one or more Servers.  A message
transaction starts with a request message  generated by a client.  At
the service interface, a server becomes involved with a transaction by
receiving and accepting the request.  A server terminates its
involvement with a transaction by sending a response message.  In a
group message transaction, the server entity designated by the client
corresponds to a group of entities.  In this case, each server in the
group receives a copy of the request.  In the client's view, the
transaction is terminated when it receives the response message or, in
the case of a group message transaction, when it receives the last
response message.  Because it is normally impractical to determine when
the last response message has been received.  the current transaction is
terminated by VMTP when the next transaction is initiated.

Within an entity domain, a transaction is uniquely identified by the
tuple (Client, Transaction, ForwardCount).  where Transaction is a
32-bit number and ForwardCount is a 4-bit value.  A Client uses
monotonically increasing Transaction identifiers for new message
transactions.  Normally, the next higher transaction number, modulo
2**32, is used for the next message transaction, although there are
cases in which it skips a small range of Transaction identifiers.  (See
the description of the STI control flag.)  The ForwardCount is used when
a message transaction is forwarded and is zero otherwise.

A Client generates a stream of message transactions with increasing
transaction identifiers, directed at a diversity of Servers.  We say a


Cheriton                                                       [page 10]



RFC 1045                       VMTP                        February 1988 


Client has a transaction outstanding if it has invoked a message
transaction, but has not received the last Response (or possibly any
Response).  Normally, a Client has only one transaction outstanding at a
time.  However, VMTP allows a Client to have multiple message
transactions outstanding simultaneously, supporting streamed,
asynchronous remote procedure call invocations.  In addition, VMTP
supports nested calls where, for example, procedure A calls procedure B
which calls procedure C, each on a separate host with different client
entity identifiers for each call but identified with the same process
and principal.


2.4. Request and Response Messages

A message transaction consists of a request message and one or more
Response messages.  A message is structured as message control block
(MCB) and segment data, passed as parameters, as suggested below.

  +-----------------------+
  | Message Control Block |
  +-----------------------+
  +-----------------------------------+
  |       segment data                |
  +-----------------------------------+

In the request message, the MCB specifies control information about the
request plus an optional data segment.  The MCB has the following
format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +                         ServerEntityId  (8 octets)            +
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Flags       |         RequestCode                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +                         CoresidentEntity (8 octets)           +
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >                         User Data (12 octets)                 <
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         MsgDelivery                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SegmentSize                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The ServerEntityId is the entity to which the Request MCB is to be sent
(or was sent, in the case of reception).  The Flags indicate various
options in the request and response handling as well as whether the


Cheriton                                                       [page 11]


RFC 1045                       VMTP                        February 1988 


CoresidentEntity, MsgDelivery and SegmentSize fields are in use.  The
RequestCode field specifies the type of Request.  It is analogous to a
packet type field of the Ethernet, acting as a switch for higher-level
protocols.  The CoresidentEntity field, if used, designates a subgroup
of the ServerEntityId group to which the Request should be routed,
namely those members that are co-resident with the specified entity (or
entity group).  The primary intended use is to specify the manager for a
particular service that is co-resident with a particular entity, using
the well-known entity group identifier for the service manager in the
ServerEntityId field and the identifier for the entity in the
CoresidentEntity field.  The next 12 octets are user- or
application-specified.

The MsgDelivery field is optionally used by the RPC or user level to
specify the portions of the segment data to transmit and on reception,
the portions received.  It provides the client and server with
(optional) access to, and responsibility for, a simple selective
transmission and reception facility.  For example, a client may request
retransmission of just those portions of the segment that it failed to
receive as part of the original Response.  The primary intended use is
to support highly efficient multi-packet reading from a file server.
Exploiting user-level selective retransmission using the MsgDelivery