rfc1045.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,452 行 · 第 1/5 页

The protocol is designed to provide a range of behaviors within the
transaction model, including:

   - Minimal two packet exchanges for short, simple transactions.

   - Streaming of multi-packet requests and responses for efficient
     data transfer.

   - Datagram and multicast communication as an extension of the
     transaction model.

Example Uses:

   - Page-level file access - VMTP is intended as the transport
     level for file access, allowing simple, efficient operation on
     a local network.  In particular, VMTP is appropriate for use
     by diskless workstations accessing shared network file


Cheriton                                                        [page 1]



RFC 1045                       VMTP                        February 1988 


     servers.

   - Distributed programming - VMTP is intended to provide an
     efficient transport level protocol for remote procedure call
     implementations, distributed object-oriented systems plus
     message-based systems that conform to the request-response
     model.

   - Multicast communication with groups of servers to:  locate a
     specific object within the group, update a replicated object,
     synchronize the commitment of a distributed transaction, etc.

   - Distributed real-time control with prioritized message
     handling, including datagrams, multicast and asynchronous
     calls.

The protocol is designed to operate on top of a simple unreliable
datagram service, such as is provided by IP.


1.1. Motivation

VMTP was designed to address three categories of deficiencies with
existing transport protocols in the Internet architecture.  We use TCP
as the key current transport protocol for comparison.


1.1.1. Poor RPC Performance

First, current protocols provide poor performance for remote procedure
call (RPC) and network file access.  This is attributable to three key
causes:

   - TCP requires excessive packets for RPC, especially for
     isolated calls.  In particular, connection setup and clear
     generates extra packets over that needed for VMTP to support
     RPC.

   - TCP is difficult to implement, speaking purely from the
     empirical experience over the last 10 years.  VMTP was
     designed concurrently with its implementation, with focus on
     making it easy to implement and providing sensible subsets of
     its functionality.

   - TCP handles packet loss due to overruns poorly.  We claim that
     overruns are the key source of packet loss in a
     high-performance RPC environment and, with the increasing


Cheriton                                                        [page 2]



RFC 1045                       VMTP                        February 1988 


     performance of networks, will continue to be the key source.
     (Older machines and network interfaces cannot keep up with new
     machines and network interfaces.  Also, low-end network
     interfaces for high-speed networks have limited receive
     buffering.)

VMTP is designed for ease of implementation and efficient RPC.  In
addition, it provides selective retransmission with rate-based flow
control, thus addressing all of the above issues.


1.1.2. Weak Naming

Second, current protocols provide inadequate naming of transport-level
endpoints because the names are based on IP addresses.  For example, a
TCP endpoint is named by an Internet address and port identifier.
Unfortunately, this makes the endpoint tied to a particular host
interface, not specifically the process-level state associated with the
transport-level endpoint.  In particular, this form of naming causes
problems for process migration, mobile hosts and multi-homed hosts.
VMTP provides host-address independent names, thereby solving the above
mentioned problems.

In addition, TCP provides no security and reliability guarantees on the
dynamically allocated names.  In particular, other than well-known
ports, (host-addr, port-id)-tuples can change meaning on reboot
following a crash.  VMTP provides large identifiers with guarantee of
stability, meaning that either the identifier never changes in meaning
or else remains invalid for a significant time before becoming valid
again.


1.1.3. Function Poor

TCP does not support multicast, real-time datagrams or security.  In
fact, it only supports pair-wise, long-term, streamed reliable
interchanges.  Yet, multicast is of growing importance and is being
developed for the Internet (see RFC 966 and 988).  Also, a datagram
facility with the same naming, transmission and reception facilities as
the normal transport level is a powerful asset for real-time and
parallel applications.  Finally, security is a basic requirement in an
increasing number of environments.  We note that security is natural to
implement at the transport level to provide end-to-end security (as
opposed to (inter)network level security).  Without security at the
transport level, a transport level protocol cannot guarantee the
standard transport level service definition in the presence of an
intruder.  In particular, the intruder can interject packets or modify


Cheriton                                                        [page 3]



RFC 1045                       VMTP                        February 1988 


packets while updating the checksum, making mockery out of the
transport-level claim of "reliable delivery".

In contrast, VMTP provides multicast, real-time datagrams and security,
addressing precisely these weaknesses.

In general, VMTP is designed with the next generation of communication
systems in mind.  These communication systems are characterized as
follows.  RPC, page-level file access and other request-response
behavior dominates.  In addition, the communication substrate, both
local and wide-area, provides high data rates, low error rates and
relatively low delay.  Finally, intelligent, high-performance network
interfaces are common and in fact required to achieve performance that
approximates the network capability.  However, VMTP is also designed to
function acceptably with existing networks and network interfaces.


1.2. Relation to Other Protocols

VMTP is a transport protocol that fits into the layered Internet
protocol environment.  Figure 1-1 illustrates the place of VMTP in the
protocol hierarchy.


 +-----------+ +----+ +-----------------+ +------+
 |File Access| |Time| |Program Execution| |Naming|... Application
 +-----------+ +----+ +-----------------+ +------+      Layer
       |           |           |             |      |
       +-----------+-----------+-------------+------+
                               |
                        +------------------+
                        | RPC Presentation |          Presentation
                        +------------------+          Layer
                                  |
            +------+          +--------+
            |  TCP |          | VMTP   |              Transport
            +------+          +--------+              Layer
                |                  |
           +-----------------------------------+
           |       Internet Protocol & ICMP    |      Internetwork
           +-----------------------------------+      Layer

               Figure 1-1:   Relation to Other Protocols

The RPC presentation level is not currently defined in the Internet
suite of protocols.  Appendix II defines a proposed RPC presentation
level for use with VMTP and assumed for the definition of the VMTP
management procedures.  There is also a need for the definition of the


Cheriton                                                        [page 4]



RFC 1045                       VMTP                        February 1988 


Application layer protocols listed above.

If internetwork services are not required, VMTP can be used without the
IP layer, layered directly on top of the network or data link layers.


1.3. Document Overview

The next chapter gives an overview of the protocol, covering naming,
message structure, reliability, flow control, streaming, real-time,
security, byte-ordering and management.  Chapter 3 describes the VMTP
packet formats.  Chapter 4 describes the client VMTP protocol operation
in terms of pseudo-code for event handling.  Chapter 5 describes the
server VMTP protocol operation in terms of pseudo-code for event
handling.  Chapter 6 summarizes the state of the protocol, some
remaining issues and expected directions for the future.  Appendix I
lists some standard Response codes.  Appendix II describes the RPC
presentation protocol proposed for VMTP and used with the VMTP
management procedures.  Appendix III lists the VMTP management
procedures.  Appendix IV proposes initial approaches for handling entity
identification for VMTP.  Appendix V proposes initial authentication
domains for VMTP.  Appendix VI provides some details for implementing
VMTP on top of IP.  Appendix VII provides some suggestions on host
implementation of VMTP, focusing on data structures and support
functions.  Appendix VIII describes a proposed program interface for
UNIX 4.3 BSD and its descendants and related systems.























Cheriton                                                        [page 5]



RFC 1045                       VMTP                        February 1988 


2. Protocol Overview

VMTP provides an efficient, reliable, optionally secure transport
service in the message transaction or request-response model with the
following features:

   - Host address-independent naming with provision for multiple
     forms of names for endpoints as well as associated (security)
     principals.  (See Sections 2.1, 2.2, 3.1 and Appendix IV.)

   - Multi-packet request and response messages, with a maximum
     size of 4 megaoctets per message.  (Sections 2.3 and 2.14.)

   - Selective retransmission. (Section 2.13.)  and rate-based flow
     control to reduce overrun and the cost of overruns.  (Section
     2.5.6.)

   - Secure message transactions with provision for a variety of
     encryption schemes.  (Section 2.6.)

   - Multicast message transactions with multiple response messages
     per request message.  (Section 2.7.)

   - Support for real-time communication with idempotent message
     transactions with minimal server overhead and state (Section
     2.5.3), datagram request message transactions with no
     response, optional header-only checksum, priority processing
     of transactions, conditional delivery and preemptive handling
     of requests (Section 2.8)

   - Forwarded message transactions as an optimization for certain
     forms of nested remote procedure calls or message
     transactions.  (Section 2.9.)

   - Multiple outstanding (asynchronous) message transactions per
     client.  (Section 2.11.)

   - An integrated management module, defined with a remote
     procedure call interface on top of VMTP providing a variety of
     communication services (Section 2.10.)