rfc1698.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,543 行 · 第 1/5 页

Network Working Group                                         P. Furniss
Request for Comments: 1698                                    Consultant
Category: Informational                                     October 1994


                  Octet Sequences for Upper-Layer OSI
              to Support Basic Communications Applications

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document states particular octet sequences that comprise the OSI
   upper-layer protocols (Session, Presentation and ACSE) when used to
   support applications with "basic communications requirements". These
   include OSI application protocols such as X.400 P7 and Directory
   Access Protocol, and "migrant" protocols, originally defined for use
   over other transports.

   As well as the octet sequences which are the supporting layer headers
   (and trailers) around the application data, this document includes
   some tutorial material on the OSI upper layers.

   An implementation that sends the octet sequences given here, and
   interprets the equivalent protocol received, will be able to
   interwork with an implementation based on the base standard, when
   both are being used to support an appropriate application protocol.

Table of Contents

   1. Introduction ...................................................2
   2. General ........................................................3
    2.1 Subdivisions of "basic communication applications" ...........3
    2.2 Conformance and interworking .................................5
    2.3 Relationship to other documents ..............................5
   3. Contexts and titles ............................................6
    3.1 The concepts of abstract and transfer syntax .................6
    3.2 Use of presentation context by cookbook applications..........7
    3.3 Processing Presentation-context-definition-list ..............8
    3.4 Application context ..........................................9
    3.5 APtitles and AEqualifiers ....................................9
   4. What has to be sent and received ..............................10
    4.1 Sequence of OSI protocol data units used ....................10
    4.2 Which OSI fields are used ...................................12



Furniss                                                         [Page 1]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


    4.3 Encoding methods and length fields ..........................14
    4.3.1 Session items .............................................14
    4.3.2 ASN.1/BER items (Presentation and ACSE) ...................14
    4.4 BER Encoding of values for primitive datatypes ..............15
    4.5 Unnecessary constructed encodings ...........................16
   5. Notation ......................................................16
   6. Octet sequences ...............................................17
    6.1 Connection request message ..................................17
    6.2 Successful reply to connection setup ........................20
    6.3 Connection rejection ........................................22
    6.4 Data-phase TSDU .............................................23
    6.5 Closedown  - release request ................................24
    6.6 Closedown - release response ................................25
    6.7 Deliberate abort ............................................25
    6.8 Provider abort ..............................................27
    6.9 Abort accept ................................................27
   7. References ....................................................27
   8. Other notes ...................................................28
   9. Security Considerations .......................................29
   10. Author's Address .............................................29

1.  Introduction

   The upper-layer protocols of the OSI model are large and complex,
   mostly because the protocols they describe are rich in function and
   options. However, for support of most applications, only a limited
   portion of the function is needed. An implementation that is not
   intended to be a completely general platform does not need to
   implement all the features. Further, it need not reflect the
   structuring of the OSI specifications - the layer of the OSI model
   are purely abstract.

   This document presents the protocol elements required by the OSI
   upper layers when supporting a connection-oriented application with
   only basic communication requirements - that is to create a
   connection, optionally negotiate the data representation,
   send/receive data, close a connection and abort a connection.
   Optionally, data may be sent on the connection establishment, closing
   and abort messages.

   In this document, the protocol elements needed are given in terms of
   the octet sequences that comprise the 'envelope' around the
   application data. The envelope and its enclosing data form a
   Transport Service Data Unit (TSDU) that can be passed via the OSI
   Transport Service [ISO8072] (which in turn may be supported as
   specified in [RFC1006] or any class of the OSI Transport Protocol
   [ISO8073]).




Furniss                                                         [Page 2]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   The octet sequences to be sent and the description of the alternative
   forms that may be received are equivalent to an informal re-
   specification of the relevant parts of the upper-layer protocols.
   The "relevant parts" are determined by the requirements of the
   supported applications (this is a reflexive definition! - if
   application Z needs something that is not here, it is not supported).
   The formal specifications remain the base standards, the appropriate
   profiles and the requirements of the application. However, an
   implementation based on this document will be able to interwork with
   an implementation based directly on the full standards when both are
   supporting a basic communication application. The "full"
   implementation will exhibit only part of its potential behaviour,
   since the application will only invoke part.

   In addition to the octet sequences, the document includes some
   tutorial material.

2.  General

2.1 Subdivisions of "basic communication applications"

   Distinctions can be made within the "basic communication
   applications", as defined above, based on how much use they make of
   the OSI upper-layer services, and thus how much of the protocol
   described in this memo will be used to support a particular
   application. One distinction is:

      a) whether application data is sent on the connection
         establishment, close and abort, or only during "date phase"
         on an established connection; OR

      b) whether the application data is of only one kind (abstract
         syntax) and one format (transfer syntax) or more than one
         (i.e., how much use is made of the Presentation layer syntax
         negotiation and identification features)

   Further distinctions are possible, but in this memo, elements of
   protocol needed (or not needed) by four groups of "basic
   communications application" are identified. All groups have "basic
   communications requirements" in requiring only connection, data
   transfer and (perhaps) orderly release of connection. The four groups
   are:

      Group I: applications which send data only on an established
      connection, and use a single abstract and transfer syntax.






Furniss                                                         [Page 3]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      Group II: applications which send data on connection
      establishment and release and use a single abstract and transfer
      syntax.

      Group III: applications that send data of only one kind (one
      abstract syntax) on the connection, but which have more than one
      format (transfer syntax) specified (they use the Presentation
      context negotiation facility).

      Group IV: applications that will send data of several kinds on the
      connection (and which much therefore distinguish on each write
      which kind is being sent).

   Group III applications are equivalent to Group I (or possibly Group
   II) after the establishment exchange has negotiated the particular
   transfer syntax that will be used on the connection.

   Possible examples of the Groups are:

      Group I: Application protocols designed for use over transport-
      level protocols. Typically these are non-OSI protocols "migrated"
      to an OSI environment. X Window System protocol is an example.

      Group II: OSI-originated protocols with simple requirements,
      including many of the ROSE-based ones, such as Directory Access
      Protocol.

      Group III: Protocols that can be treated as Group I, but for
      which more than one encoding of the data is known, such as a
      standardised one and a system-specific one - all implementations
      understand the standard encoding, but Presentation layer
      negotiation allows like-implementations to use their internal
      encoding for transfer, without loss of general interworking. The
      same could apply to OSI protocols.

      Group IV: OSI protocols with multiple abstract syntaxes (but with
      each individual message from a single abstract syntax) that do
      not use any of the special Session functional units - X.400 P7 is
      an example.

   Some of the OSI protocols that are not included are those that use
   more than one abstract syntax in a single message (such as FTAM or
   Transaction Processing) or use Session functional units (RTSE-based
   protocols, Virtual Terminal).







Furniss                                                         [Page 4]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


2.2 Conformance and interworking

   The protocol elements specified in this memo correspond to the kernel
   functional units of Session, Presentation and ACSE, and the duplex
   functional unit of Session.

   The octet sequences given below are derived from the specifications
   in the International Standards for the protocols Session [ISO8327],
   Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo
   is to summarise those specifications, as applicable to the supported
   application groups, so that an implementation could be developed
   without direct reference to the original standards, but capable of
   interworking with implementations that had made direct reference. The
   OSI standards (especially Presentation) allow considerable
   flexibility in the encoding of the protocol data units. Accordingly,
   this memo defines particular octet sequences to be sent, and
   describes the variations that can be expected in data received from
   an implementation based directly on the OSI standards, rather than on
   this cookbook. It is intended that an implementation that sends these
   sequences and that is capable of interpreting the variations
   described will be fully able to interwork with an implementation
   based directly on the OSI standards. An implementation that is only
   capable of interpreting the octet sequences specified in this memo
   for transmission may not be able to interwork with standards-based
   implementations.

   The intent is to be able to interwork with conformant implementations
   in support of the relevant application (or group of applications).
   Some of the OSI standards have conformance requirements that go
   beyond that necessary for successful interworking, including
   detection of invalid protocol. Tests for conformance sometimes go
   beyond the strict conformance requirements of the standard.
   Consequently an implementation based on this memo may or may not be
   able to formally claim conformance to the International Standard. It
   may be able to legitimately claim conformance, but fail a conformance
   test, if the test is over-specified. (Efforts are being made to
   correct this, but in the meantime, the target is interworking with
   conformant implementations.)

2.3 Relationship to other documents

   The flexibility allowed in the Session, Presentation and ACSE
   standards is restricted in the Common Upper-Layer Requirements Part 1
   [CULR-1]).  This is a proposed International Standardised Profile
   (pdISP 11188-1) that can be assumed to be obeyed by most
   implementations. This memo applies the restrictions of CULR-1,
   especially where these concern maximum sizes of fields and the
   like.Points where advantage is taken of a CULR-1 limitation are



Furniss                                                         [Page 5]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   noted.

   Additional parts of CULR are under development. Part 3 [CULR-3]
   covers the protocol elements needed for "basic communications
   applications", and is being developed in (informal) liaison with this
   memo. CULR-3 is presented as a normal profile, largely consisting of
   prescribed answers to the questions in the PICS (Protocol
   Implementation Conformance Statement) of the three protocols.  CULR-3
   does not make the distinction between the four Groups.  An
   implementation of this memo (at least if it supported Group IV) would
   be able to claim conformance to CULR-3, with the possible exception
   of any more-than-interworking conformance requirements inherited by
   CULR-3 from the base standards.

   An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is
   shortly to be published as a preliminary specification. This defines
   an API to the OSI upper-layers, again as appropriate to a basic
   communications application. XTI/mOSI would be usable as an interface
   to support applications in groups I, II and III, and possibly group
   IV.

3.  Contexts and titles