GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1698

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

3.1 The concepts of abstract and transfer syntax

 OSI includes the concepts of "abstract syntax" and "transfer syntax".
 These are terms for the content (abstract syntax) and format "on-
 the-line" (transfer syntax) of the protocol elements. The combination
 of an abstract syntax and transfer syntax is called a presentation
 context.
 Application protocols devised explicitly under OSI auspices have used
 ASN.1 for the definition of the abstract syntax, and nearly all use
 the Basic Encoding Rules applied to the ASN.1 to define the transfer
 syntax. However, there is no such requirement in OSI in general or in
 OSI Presentation, and still less is there any requirement to change
 the representation of existing application protocols to ASN.1 (for
 their definition) or BER (for their transmission). It is not
 generally realised (even in OSI circles) that all communicating
 applications, in all environments, are using some form of these,
 although under different names and without the explicit
 identification that the OSI Presentation provides. OSI separates the
 identification of the content and format of the data from the
 addressing.
 Formal specifications of non-OSI application protocols (such as
 TELNET, FTP, X Windows System) generally do not use ASN.1, but will
 invariably be found to define abstract and transfer syntaxes.  For a

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

 less formalised protocol used between similar systems, the abstract
 syntax may be defined simply in programming language structures, and
 the transfer syntax determined by how some compiler represents this
 in memory.
 The OSI Presentation protocol requires that "names" be assigned to
 the abstract and transfer syntaxes of the application data that is
 carried.  The names are always object identifiers ("oid"): globally
 unique names assigned hierarchically. Presentation supports the
 negotiation of a transfer syntax for a particular abstract syntax -
 several can be offered and one selected.
 This transfer syntax negotiation facility may be especially useful
 for non-ASN.1 syntaxes where there is more than one representation
 available (perhaps differing in byte-ordering or character code). In
 such a case, on the connection establishment, all of the transfer
 syntaxes supported by the initiator are offered, and any one of these
 accepted by the responder, at its own choice. If the two systems
 share some "native" format they can negotiate that, avoiding
 transformation into and out of a more general format that is used for
 interworking with unlike systems. The same applies to an ASN.1-
 defined abstract syntax, but in practice non-BER encodings of ASN.1
 are rare.

3.2 Use of presentation context by cookbook applications

 An application protocol not originally specified with OSI
 Presentation in mind (a "migrant" protocol) will not normally need to
 identify the abstract and transfer syntaxes being used - they are
 known by some other means (effectively inferred from the addressing).
 A generic (anonymous, if you like) name for both syntaxes can be used
 and [CULR-3] defines object identifiers for "anonymous" abstract and
 transfer syntax names (currently called "default", but this is
 expected to change).
 In some cases object identifier names will be assigned for the
 syntaxes of a migrant application protocol. If these exist, they
 should be used.  However, since the processing required will be the
 same, it will be legitimate to offer both the generic and specific
 names, with the responder accepting the specific (if it knew it) and
 the generic if the specific were not known - this will provide a
 migration option if names are assigned to the syntaxes after
 implementations are deployed using the generic names.
 For abstract syntaxes defined in ASN.1 object identifier names will
 have been assigned to the abstract syntax with the specification.
 This name MUST be used to identify the abstract syntax. The transfer
 syntax will most often be the Basic Encoding Rules (BER) object id,

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

 but alternatives (e.g., Packed Encoding Rules) are possible.
 For group III and group IV applications, specific object identifier
 names must be used for all the abstract and transfer syntaxes. If
 these names are not assigned with the specification (e.g., if the
 specification not in ASN.1) they can be assigned by whoever needs
 them - ideally the "owner" of the syntax specification.

3.3 Processing Presentation-context-definition-list

 In Presentation context negotiation on connection establishment the
 initiator sends a list (the presentation context definition list) of
 the abstract syntaxes it intends to use, each with a list of transfer
 syntaxes. Each presentation context also has an integer identifier.
 To build the reply, a responder has to examine this list and work out
 which of the offered presentation contexts will be accepted and which
 (single) transfer syntax for each. The responder sends back the reply
 field, the Presentation-context-definition-result-list, in the accept
 message. The result list contains the same number of result items as
 the definition-list proposed presentation-contexts. They are matched
 by position, not by the identifiers (which are not present in the
 result- list). An acceptance also includes the transfer syntax
 accepted (as there can be several offered). This can be copied from
 the definition list.
 For the group I, group II and group III cases,  only the ACSE and one
 application-data P-context will be used and all other contexts
 rejected. For the group IV case, several presentation contexts will
 be accepted.
 However, even for group I applications there may be synonyms for an
 application-data Presentation-context. Unknown synonyms are rejected.
 The reply shown in 6.2 includes a rejection (It can therefore not be
 the reply to the connection request shown in 6.1, since that has only
 two items in the definition list.)
 In all cases, the connection responder must identify and keep the
 presentation context identifiers (called pcid's here) for all the
 accepted presentation contexts. These are integers (odd integers, in
 this case). CULR-1 limits them to no greater than 32767, but they
 will usually be <= 255 (so taking up one octet).
 A presentation context is sometimes used (i.e., data is sent using
 it) before the negotiation is complete. As will be seen in section 6,
 in these cases, the transfer syntax name sometimes appears with the
 integer identifier.

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

3.4 Application context

 The Association Control Service Element also exchanges the name
 (another Object Identifier) of the application context, which
 identifies what the communication is all about, again independently
 of the naming and addressing.  As for the syntaxes, although some
 name must be present in the protocol, a generic name can be used for
 applications that do not have a specific name assigned. (This will
 almost certainly be a group I application - if a specific name is
 assigned, it must be used.) The only negotiation allowed is that the
 reply may be different from that sent by the initiator. CULR-3
 provides a generic application context name (i.e., assigns an object
 identifier).

3.5 APtitles and AEqualifiers

 In addition to the addressing constructs (transport address and
 possibly session and presentation selectors), the communicating
 application entities have names - Application-Entity titles
 (AEtitle).  These are carried by ACSE as two fields -the
 Application-process titles (APtitle) and the Application-entity
 qualifier (AEqualifier). The AEtitle is compound, and the APtitle
 consists of all but the last element, which is the AEqualifier. (This
 explanation can be run backwards). There are two non-equivalent
 forms. AP-titles and AE-titles can be Directory Name or an Object
 Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or
 an integer - the forms must match, since the AE-qualifier is the last
 component of the AP-title. In practice, the Directory form is likely
 to be the only one seen for a while.
 Use of the these names is rather variable. This cookbook proposes
 that implementations should be able to handle any value for the
 partner's names, and set (as initiator) its own names. This is
 primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp),
 allowing the names of the end-system to be carried to the relay,
 where they can be converted into hostnames, and the lower-layer
 address determined. OSI assumes that name-to-address lookup is
 possible (via the Directory or other means), but does not assume
 address-to-name will work. Thus the calling AE-title is needed if the
 responder is to know who the initiator is. However, most protocols
 work perfectly well without these names being included.
 As for their encoding, a RDN will almost always be a single attribute
 value assertion, with the attribute defined either by the Directory
 standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274].
 Using the notation defined below, the encoding of an RDN using a
 Directory-defined standard attribute is:

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

 31  80  {1         - RDN, [SET OF]
 30  80  {2         - AttributeValueAssertion, [SEQUENCE]
 06  03  5504yy     -- OID identifying an attribute named in
                    -- the Directory standard
                    -- which one is determined by yy
 13  La  xxxxxx     -- [Printable string]
                    -- could be T61 string, with tag 14
 00  00  }2         - end of AVA
 00  00  }1         - end of RDN
 The most likely attributes for an RDN have the following hex values
 for yy.
      CommonName               03
      Country                  06
      Locality                 07
      State/Province           08
      Organisation             0A
      OrganisationUnit         0B
 For non-Directory attributes, the object id name must be substituted
 (thus changing the immediately preceding length)
 If there are multiple attribute value assertions in the RDN, the
 group between {2 and 2} is repeated (with different attributes).
 Order is not significant.
 The encoding of a [Directory] Name for the AP-titles is the RDNs
 (high- order first) within
 30  80  {1        - [SEQUENCE] Name
  -- put the RDN encodings here
 00  00  }1
 An Object Identifier AP-title is encoded as a primitive (see below),
 with the "universal" tag for an object identifier, which is 6. The
 integer AE-qualifier uses the universal tag for an integer, which is
 2.

4. What has to be sent and received

4.1 Sequence of OSI protocol data units used

 OSI defines its facilities in terms of services but these are
 abstract constructs (they do not have to correspond to procedure
 calls) - the significant thing is the transmission of the resulting
 protocol data unit (PDU). The PDU at each layer carries (as user
 data) the PDU of the layer above. The different layers follow

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

 different conventions for naming the pdus. This section gives an
 overview of the sequence of PDUs exchanged - the details of these are
 given in section 6.
 The requirements of the application are to create a connection
 (strictly an association for the application-layer in OSI, but called
 a connection here), to send and receive data and to close the
 connection.  The PDUs used are thus:
 To create connection:
      First create transport-level connection
      Initiator sends the message defined in 6.1, which is Session
      CONNECT carrying Presentation CONNECT request [CP] carrying
      ACSE A-ASSOCIATE request [AARQ] optionally carrying application
      data.
      Responder replies with the message defined in 6.2, which is
      Session ACCEPT carrying Presentation CONNECT response [CPA]
      carrying ACSE response [AARE] optionally carrying application
      data.
  1. If the responder rejects the attempt, the reply will be Session

REJECT. This is defined in 6.3, where the REJECT carries no

      user data. A received REJECT may carry Presentation, ACSE and
      application data, although 6.3 shows only how to reject at
      Session level..
 To send/receive data on an connection
      send the message defined in 6.4, which is an empty Session
      GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
      DATA [TD] containing the application data (The GIVE-TOKEN is
      just two octets required by Session for some backwards
      compatibility.)
 To close connection gracefully
      One side sends the message defined in 6.5, which is Session
      FINISH carrying P-RELEASE request carrying A-RELEASE request
      [RLRQ] optionally carrying application data (This side may now
      receive, but not send data.)
      The other side replies with the message defined in 6.6, which
      is Session DISCONNECT carrying P-RELEASE response carrying A-
      RELEASE response [RLRE] optionally carrying application data

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

      First side disconnects transport connection on receiving the
      reply
 To close connection abruptly but also send application data
      Send the message defined in 6.7, which is Session ABORT
      carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
      carrying application data (delivery not guaranteed)
      On receiving Session ABORT, disconnect transport
 To close connection abruptly
  1. Either send the message defined in 6.8, which is Session ABORT

carrying nothing;

      Or, just disconnect at transport level
 A group I application is assumed (by definition) not to send data on
 the establishment and release exchanges, a group II application will.
 It would be possible to use the abort-with-data facility with a group
 I to send a (possibly non-standardised) error message for diagnostic
 purposes.
 A special rule is used if a release collision occurs (i.e., FINISH+P-
 RELEASE+RLRQ received after sending the same): the side that
 initiated the original upper-layer connection waits and the other
 side replies with the DISCONNECT etc.

4.2 Which OSI fields are used

 There are a number of fields (parameters) in the pdus involved. These
 can be categorised by what is needed to support applications (of a
 particular Group) in general - a field may  be "useful", "send-only",
 "fixed", "fixed with default", "internal" or "not important". Even
 those that are not important may be received from another
 implementation, but since the application has no use for them, they
 can be ignored. If an implementation is intended to support only a
 particular application, it may be able to downgrade the "useful" to
 "not important".
 The text below describes the processing that is required for each
 category and which fields are in each category.
 "Useful" - when sending, an implementation of general use should be
 able to set any (legal) value of these fields (via the upper
 interface from the application or via some configuration or lookup

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

 mechanism) and SHOULD pass received values for the Calling values to
 the application (for specific applications, these fields may be
 either required or unnecessary.)
  AARQ:
    Called application-process title
    Called application-entity qualifier
    Calling application-process title
    Calling application-entity qualifier
 "Send-only" - to interwork, the implementation must be able to set
 any value of these, but can ignore any received value. Both are octet
 strings.
    Presentation selector (up to 4 octets, limited by CULR-1)
    Session selector (up to 16 octets, limited by base standard)
 "Fixed" (constant for all applications)
    abstract and transfer syntax identifiers for presentation context
    for ACSE Version numbers - 2 for session, 1 for Presentation
    and ACSE
 "Fixed with default" - the value is specific to the application. For
 non-ASN.1 abstract syntaxes (group I or group II only) applications,
 the anonymous values assigned by the OIW minimal OSI profile [CULR-3]
 can be used. The CULR-3 default application context can be used where
 a proper context name is neither available nor needed.
    Application context
                     CULR-3  default is {1 0 11188 3 3}
    Abstract syntax identifier for application data
                     CULR-3 anonymous name is {1 0 11188 3 1 1}
    Transfer syntax identifier for application data
                     CULR-3 anonymous name is {1 0 11188 3 2 1}
 "Internal" - an arbitrary value can be sent; a received value must be
 stored for use in sending.
    Presentation context identifiers for ACSE and the application
    data (always odd integers)
 "Not important" - for interworking, any legal received value for the
 other fields must be received (i.e., the pdu is parsed successfully),
 but can then be ignored. There is no requirement (in this cookbook)
 to check the existence, value or internal format of these fields.

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

    All other fields (which includes a large number of session
    fields)

4.3 Encoding methods and length fields

 Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
 structure for their encodings, but different ones. Presentation
 protocol and ACSE protocol use the ASN.1/BER encoding and
 consequently a Presentation PDU containing an ACSE PDU can be
 constructed or parsed as if it were a single structure.
 All the protocols contain pdu fields with a compound structure. If
 one of these is being ignored it may be necessary (for BER, not
 session) to determine the lengths of its components to find the
 length of the ignored field.
 Many of the lengths in the specification below will vary, dependent
 on the values of the fields.

4.3.1 Session items

 The type field of a session item is always a single octet.
 For session items, given a particular length, there is no
 flexibility:
    If the length is less than 255, represent as one octet
    If the length is greater, represent as three octets, first is
    0xFF, next two are the length, high-order octet first.
 (Some "real" implementations are known to use the second encoding in
 all cases. This is wrong, but should only concern conformance
 testers.)

4.3.2 ASN.1/BER items (Presentation and ACSE)

 The type field for ASN.1-BER is the tag. Although it is possible for
 large tags (>30) to be multi-octet, there are no large tags in the
 protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1
 if the item is constructed (i.e., the value is itself one or more
 ASN.1 BER items) or 0 if it is primitive.
 There is considerable flexibility, at senders option, in how lengths
 are represented in BER. There are three forms: short, long and
 indefinite.
    Short (usable only if the length is less than 127) : one octet

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

    Long (usable for *any* length) : first octet has the top bit set,
    the rest is a count of how many octets are holding the length
    value; that many subsequent octets hold the length. A long length
    may use more than the minimum number of octets (so 0x8400000001
    is a valid representation of length 1)
    Indefinite (usable only for the length of a compound field) : the
    single octet is 0x80, then one or more items (their tag-length-
    values) and finally two octets of 0x00 (equivalent to tag and
    length of zero).
 To be able to interwork generally, an implementation must be able to
 handle any of these forms when receiving.
 The encodings specified in the octet sequences below use indefinite
 length for all constructed items with a few exceptions. This slightly
 increases the number of octets sent, but means that the length of a
 varying field (e.g., user data, or a varying object identifier)
 affects only the length of the item itself, and not the enclosing
 lengths. It is thus possible to use the octet sequences as templates
 interspersed by the varying fields.
 It is important to note that this choice of indefinite (which is
 equivalent to the "Canonical Encoding Rules" variant of BER) applies
 only to the Presentation and ACSE protocols themselves. It does not
 apply to ASN.1/BER encoded application data. The processing required
 of application data may suggest alternative "best" options.

4.4 BER Encoding of values for primitive datatypes

 The following ASN.1 primitive datatypes are used in the thinosi
 stack.
 Integers are encoded in twos-complement, high-order first. Unlike
 lengths, they must be encoded in the minimum number of octets (no
 leading 00 padding).
 Object Identifiers have a rather peculiar, but compressed encoding:
    Combine the first two integers of the OID into one element by
    multiplying the first (always 0, 1 or 2) by 40, and add the
    second.
    Each element (that one, and each subsequent integer in the OID
    taken on its own), is a taken as a binary number and divided into
    7-bit "bytes". This is apportioned into bits 1-7 of the minimum
    number of octets. Bit 8 is one for all octets of the sequence
    except the last. (This means that elements of less than 127 are

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

    single octet integers.)
 Printable Strings - as if in ISO 646 (ASCII)
 OCTET STRING - just put the octets there

4.5 Unnecessary constructed encodings

 BER allows the sender to break some items (such as OCTET STRINGS,
 character strings) into several pieces (i.e., as constructed
 encoding) or send them as primitive. CULR-1 requires that this is
 only done to one level. The pieces of both OCTET STRING and character
 string are tagged as if they were OCTET STRING - they have the tag
 04. This memo does not include any of these optional constructions,
 but they may be received in interworking.

5. Notation

 The constructs are shown in their tag - length - value form. All
 numbers are in hexadecimal. Comments are preceded by a '-' character.
 Multiple '-' mean the comment is more than just information.
 The tag column contains one of:
    single fixed octets.
  • in the tag field indicates one or more pdu fields (possibly

constructed) that may be received but are not sent. If received

    they can be ignored.
    ! indicates the tag is defined elsewhere.
    .  is a place holder for the column.
    ? preceding the tag value indicates that the field is not always
    present - the comment will explain.
 The length column contains one of
    explicit value
    Ls - a length according to session rules which depends on the
    total size of the value (usually constructed)
    La - a length according to BER rules
    . is a placeholder

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

    yy is exactly one octet (i.e., one hex digit per y) holding part
    of the length
 The value column contains one of
    the hex value
    xxxxxx - value of varying length (sometimes constructed)
    {n - (n = number) the start of a constructed value
    n - (n=number) the end of the constructed value with the
    corresponding number. (The number is sometimes omitted on the
    innermost nest of construction)
    yy - as part of a value - a variable value, each y represents one
    hex digit
    ? a value, possibly constructed that may be received but is not
    sent. It may be ignored if received
 Note that all presentation lengths may be received in one of the
 alternative forms. All constructed lengths are shown in indefinite
 form. If a received length is definite, the corresponding end item
 (which will be shown here as 00 00 }n)  will become  . . }n.
 In the comments, the notation {n} refers to the constructed item
 bracketed by the {n, }n fields.

6. Octet sequences

6.1 Connection request message

  1. CONNECT SPDU

0D Ls {1 - "SI" value for CONNECT = 13

  • Ls ? - Connection Identifier

05 06 {2 - Connect/Accept Item

 13  01  00       - protocol options (probably mandatory)
 *   Ls  ?
 16  01  02       -- version number (bottom bit = v1, next bit =v2.
                  --     may get offers of either or both
 *   Ls  ?
 14  02  0002     - Session User Requirements (functional units)
                  - Id (20), length (always 2), duplex fu only.
                  -- On receipt, other bits may be set
                  -- check that the 2 bit is set
 *   Ls  ?        - we do not send any Calling Session Selector

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

 ?34 Ls  xxxx     -- Called Session Selector (i.e., the other end's)
                  -- up to 16 octets - you must set what the other
                  -- side demands.  - May be anything characters,
                  -- binary etc.
                  -  {3} disappeared in editing
 C1  Ls  {4       -- User Data, Identifier=193. if length is > 512,
                  -- then identifier is 194 (hex C2) instead
 - CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
 31  80  {5       - [SET]
            --- Mode-selector (the {6} group) could possibly
            --- come after everything else {7}
            --- This will probably only be done by
            --- evil-minded conformance testers
 A0  80  {6       - Mode-selector [0] IMPLICIT SET
 80  01  01       - [0] IMPLICIT INTEGER {normalmode(1)}
 00  00  }6
 A2  La  {7       - [2] unnamed IMPLICIT SEQUENCE
 *   La  ?
 ?82 La  xxxx     - [2] Called-presentation-selector
                  - CULR says maximum length is 4
                  -- must be what the other side wants
 A4  80  {8       - [4] Presentation-context-definition-list
              ---  items (the outer SEQUENCEs) within the {8} list may
              ---  be in any order.
 30  80  {9       - [SEQUENCE]
 02  01  01       -- Defines pcid for ACSE; received value will be
                  -- a one or two octet odd integer
 06  04  52010001 - [OID] for ACSE abstract syntax
 30  80  {        - [SEQUENCE]
 06  02  5101     - [OID] Transfer syntax name is BER
 00  00  }        - end t-s list
 00  00  }9       - end acse pctx defn
 30  80  {10      - [SEQUENCE]
 02  01  03       -- [INTEGER] Defines pcid for application data;
                  -- received value will be a one or two octet odd
                  -- integer
 06  La  xxxxxx   - [OID] object identifier name of application
                  - abstract syntax (if CULR-3 default is used, this
                  - line is 06  06  28D734030101)
 30  80  {11
 06  La  xxxxxx   - [OID] t-s name for application data
                  - (if CULR-3 default is used, this line is
                  -  06  06  28D734030201)
              -- will be several of these if multiple t-s offered
              -- (application is Group III)
              -- all will have the same tag 06
 00  00  }11      - end transfer syntax list for application p-ctx
 00  00  }10      - end application pctx definition

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

  1. - if multiple presentation contexts are offered, (Group
  2. - IV), the {10} SEQUENCE will repeat appropriately
  3. - if multiple contexts are to be accepted, all the
  4. - pcid's must be remembered

00 00 }8 - end of p-ctx-def-list

  • La ?

61 80 {12 - [APPLICATION 1] User-data - Fully-encoded

 30  80  {13      - [SEQUENCE] PDV-list
 02  01  01      -- [INTEGER], value is acse pcid
 A0  80  {14      - [0] Single-ASN1
 - ACSE A-ASSOCIATE request APDU - AARQ
 60  80  {15      - [APPLICATION 0] - AARQ
 *   La  ?        -  protocol version defaults to 1 (only one defined)
 A1  80  {        - [1] Application-context
 06  La  xxxxxx   -- object identifier name of application context
                  - (if CULR-3 default is used, this line is
                  -  06  05  28D7340303)
 00  00  }
           -- Called application process title {16} and application
           -- entity qualifier may or may not be needed (see 3.4)
 ?A2 80  {16      - [2] Called Application-Process title
 ?!  La  xxxxxx   -- see 3.5 - either a Directory Name or an oid
 ?00 00  }16      - end Called APtitle
 ?A3 80  {17      - [3] Called Application-Entity Qualifier
 ?!  La  xxxxxx   -- see 3.5
 ?00 00  }17
 *   La  ?
           Calling AP-title and AE-qualifier may or may not be needed.
 ?A6 80  {18      - [6] Calling Application-Process title
 ?!  La  xxxxxx   -- see 3.5
 ?00 00  }18
 ?A7 80  {19      - [7] Calling Application-Entity Qualifier
 ?!  La  xxxxxx   -- see 3.5
 ?00 00  }19
 *   La  ?
          -- the user information field may or may not be required
          -- (not required for Group I)
 ?BE 80  {20      - [30] IMPLICIT SEQUENCE
 ?28 80  {21      - [EXTERNAL]
 ?06 La xxxxxx   -- [OID] This is the oid identifying the transfer
                  -- syntax used for the user data.
                  -- It is (almost certainly) required even if only
                  -- one transfer syntax was proposed.
 ?02 01  03       -  [INTEGER] this is the pcid for the application
                  -  data
 ?A0 La  xxxxxx   -- [0] single-ASN.1-type - the application data
                  --      (see paragraph at end of this section below}
 ?00 00  }21      - end of EXTERNAL

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

  1. - conceivably there may be several EXTERNALS, probably in
  2. - different presentation contexts (different pcids)

?00 00 }20 - end of user information field

 00  00  }15      - end of AARQ
 00  00  }14      - end of single-ASN-type
 00  00  }13      - end of PDV-list
 00  00  }12      - end of Presentation User-data
 00  00  }7       - end of third element of CP-type SET
 00  00  }5       - end of CP-type
 The application data carried in the EXTERNAL is shown (as A0 La xxxx)
 assuming it is a single-ASN.1 type, which it often will be for group
 II (since these tend to be OSI applications). The xxxx will be the
 BER encoding of the application pdu (probably something like Z-BIND
 or Y- INITIALIZE). The length may be indefinite.
 If the application data is not a single ASN.1 type, but is an octet-
 aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx
 is the value. In this case the length must be definite (unless an
 "unnecessary" constructed encoding is used.)
 Identical considerations apply to the other EXTERNALs carried in the
 ACSE pdus.

6.2 Successful reply to connection setup

 If the connection attempt is successful, the following is sent to the
 initiator on a T-DATA.
 0E  Ls  {1         - ACCEPT SPDU
 *   Ls  ?
 05  06  {2         - Connect/Accept Item
 13  01  00         - Protocol Options
 *   Ls  ?
 16  01  02         - version number (this shows version 2 only)
                -- if version 2 was not offered, omit all of {2}
 *   Ls  ?
 14  02  0002       - Session User Requirements (functional units)
                    - duplex fu only (kernel is automatic)
 *   Ls  ?
 C1  Ls  {3         -- User Data.
   - CPA - P-CONNECT response
 31  80  {4         - [SET]
                    -- again, Mode-selector could come at the end
 A0  80  {          -  Mode-selector [0]
 80  01  01         -  normal mode - [0], length=1, value=1
 00  00  }
 A2  80  {5         - [2] SEQUENCE (unnamed)

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

  • La ?

A5 80 {6 - [5] P-context-definition-result-list

  1. - following result items are in the order
  2. - corresponding to the pctx-definition-list in
  3. - the connect
  4. - this example assumes that was ACSE, user, rubbish
  5. - with rubbish rejected

30 80 {7 - [SEQUENCE] result item for acse

 80  01  00         -- [0] result, value 0 is acceptance
 81  02  5101       -  [1] accepted transfer syntax name = BER
                    - note that this has an implicit tag, not 06
 00  00  }7         - end result item for acse p-ctx
 30  80  {8         - [SEQUENCE] result item for application-data pctx
 80  01  00         - [0] value 0 is acceptance
 81  La  xxxxxx     - [1] oid for transfer syntax, as on definition list
                    -- if there were several (groupIII) , the one you
                    -- liked most
 00  00  }8         - end result item for app-data p-ctx
 00  00  }6         - end p-ctx-def-result-list
 *   La  ?
 61  80  {10        - [APPLICATION 1] User-data, Fully-encoded
 30  80  {11        - [SEQUENCE] PDV-list
 02  01  01         -- [INTEGER] value is pcid for ACSE, as stored from
                    -- the pctx-definition-list on the P-CONNECT
                    -- request
 A0  80  {12        - [0] single-ASN1-type
      - A-ASSOCIATE response APDU - AARE
 61  80  {13        - [APPLICATION 1] identifies AARE
 *   La  ?
 A1  80  {14        - [1] Application-context
 06  La  xxxxxx     - [OID] name of application context
                    - usually the same as on AARQ, can differ
 00  00  }14
 A2  03  {15        - [2] result
 02  01  00         - [INTEGER] value 0 means accepted
 00  00  }15
 A3  80  {16        - [3] result-source-diagnostic
                    - (curiously, a non-optional field)
 A1  80  {17        - [1] acse-service-user
 02  01  00         - [INTEGER] value 0 = null ! (why no implicit tag)
 00  00  }17        - end acse-service-user
 00  00  }16        - end result source diagnostic
 *   La  ?
          -- the user information field may or may not be required
          -    (not used for Group I)
 ?BE 80  {20      - [30] IMPLICIT SEQUENCE

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

 ?28 80  {21      - [EXTERNAL]
                 -- the transfer-syntax oid is not present this time
 ?02 01  03       - [INTEGER] this is the pcid for the application
                  - data
 ?A0 La  xxxx     -- [0] single-ASN1-type (see note at end of 6.1)
 ?00 00  }21      - end of EXTERNAL
          -- conceivably there may be several EXTERNALS, probably in
          -- different presentation contexts (different pcids)
 ?00 00  }20      - end of user information field
 00  00  }13        - end AARE
 00  00  }12        - end single-asn1-type
 00  00  }11        - end PDV-list
 00  00  }10        - end Presn user-data
 00  00  }5         - end [2] implicit sequence in cpa
 00  00  }4         - end CPA-type set
 The following sequence are the octets need to reject a presentation
 context that was offered in the presentation-context-definition-list.
 Since the result-list matches the definition list by position, it is
 placed at the corresponding point within {6} (e.g., it would come
 immediately after {8}, if the rejected context was the third one.
  1. - next SEQUENCE is a rejection of a pctx

30 80 {9 - [SEQUENCE] result item for a rejected pctx

 80  01  02         -- [0] result, value 2 is provider rejection
 82  01  00         - [2] reason, value 0 is reason-not-specified
                    -- there are other reasons, but let's keep it
                    -- simple
 00  00  }9         - end result item for rejected pctx

6.3 Connection rejection

 Refusal is at session-level, but by session user, with no reason
 given.  This is a compromise avoiding making unfounded accusations of
 (session) protocol misbehaviour. If the implementation finds it does
 not like the received message, it is not essential to attempt to
 communicate with the partner why, though this may be helpful if the
 reason is correctly identified. (In most cases, a wise implementor
 will make sure an error message goes somewhere or other).
 0C  03  {1          - REFUSE SPDU
 *   Ls  ?
 32  01  00          - rejected by SS-user, no reason
 The far-end may send interesting things explaining why you are not
 getting interworking. If this is a session reason, the reason code
 will one octet between 81 and 86. If the rejection is higher than
 session, this will be carried on S-REFUSE (so first octet is still

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

 0C) and the higher pdu will appear as part of the reason code, which
 will start with 02.  (The only remaining code is 01 = user
 congestion.)

6.4 Data-phase TSDU

 This is the core of the skinny stack. The lengths shown use a
 particular set of choices for indefinite and definite lengths that
 means that the application data length only affects one field. Making
 the two earlier indefinite lengths definite would require more
 calculation - adding 4 octets after the application data is assumed
 to be quicker. This header is also designed to be 20 octets long,
 thus maintaining 4-byte alignment between transport and application
 buffers.  Implementations are recommended to use this encoding. It is
 possible to rapidly match incoming data against it - if there is no
 mismatch until the length field, the location of the beginning of the
 data can be determined without further analysis.
           SPDUs
 01  00  .      - S-GIVE-TOKEN - required by basic concatenation
                - but no parameters
 01  00  .      - S-DATA - no parameters - what follows is User
                - Information, not User Data, so is not included in
                - the SPDU length fields
   - P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
 61  80  {1     - User-data [APPLICATION 1]
 30  80  {2     - [SEQUENCE] PDV-list
 02  01  03     - [INTEGER] pcid for application data, P-CONNECT PPDU
                - remembered by both sides
 81  83yyyyyy   xxxxxx  -- [1] octet-aligned presentation data value(s)
               -- length of length (3 octets) then three octets yyyyyy
               -- for the length of the user data xxxxxx
 00  00  }2      - End-of-contents for end of PDV-list
 00  00  }1      - End-of-contents for end of Presentation User-data
 If the application data is in ASN.1, and a single ASN.1 value is
 being sent on the TSDU, the same header can be used except for the
 tag on the presentation data values, which becomes A0 (= [0],
 constructed).
 If there are multiple data values to be sent, this header can be
 expanded in several ways:
    a) if there are several ASN.1 values from the same
       presentation context, they can be concatenated and
       treated as an octet-aligned value (using the header
       as shown above, with tag 81 (or A1 - I think its
       primitive) or each ASN.1 value can be an item

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

       (tagged A0), one after the other
    b) if the data values are from different presentation
       contexts (group IV), each is in its own {2} group
       within the {1}.
 On receipt, for the simple octet-aligned case, the data value may
 itself have a constructed encoding - this will make the tag A1, and
 it will contain elements each tagged 04 (OCTET STRING). According to
 CULR- 1, these elements are primitive (otherwise they would be 24 of
 course).

6.5 Closedown - release request

 When all is done, and you want to close down gracefully, send this on
 T-DATA.
  1. FINISH SPDU

09 10 {1 - 9 identifies FINISH

  • Ls ? - No Transport Disconnect item
    1. default is release Transport-connection

C1 0E {2 - User data (code 193)

  1. P-RELEASE req/ind PPDU (has no name)

61 80 {3 - [APPLICATION 1], user data, fully-encoded

 30  80  {4         - [SEQUENCE] PDV-list
 02  01  01         -- pcid for ACSE, remembered from setup
 A0  80  {5         - [0] single asn.1-type
     - A-RELEASE request APDU - RLRQ
 62  80  {6         - [APPLICATION 2] identifies RLRQ
 80  01  00         - [0] reason, value 0 means normal
 *   La  ?
          -- the user information field may or may not be required
          - ( not required for Group I)
 ?BE 80  {7       - [30] IMPLICIT SEQUENCE
 ?28 80  {8       - [EXTERNAL]
                  -- the transfer-syntax oid is not present this time
 ?02 01  03       - [INTEGER] this is the pcid for the application
                  - data
 ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                  -- (see note at end of 6.1)
 ?00 00  }8       - end of EXTERNAL
          -- conceivably there may be several EXTERNALS, probably in
          -- different presentation contexts (different pcids)
 ?00 00  }7       - end of user information field
 00  00  }6         - end of RLRQ
 00  00  }5         - end of single asn.1-type
 00  00  }4         - end of PDV-list
 00  00  }3         - end of Presentation User-data

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

6.6 Closedown - release response

 On receiving a FINISH, you send this to tell the other end it is all
 over
  1. Session DISCONNECT SPDU

0A Ls {1 - SI=10, DISCONNECT

 C1  Ls  {2         - User data
     - P-RELEASE rsp PPDU
 61  80  {3         - [APPLICATION 1], user data, fully-encoded
 30  80  {4         - [SEQUENCE] PDV-list
 02  01  01         -- [INTEGER] pcid for ACSE, remembered from setup
 A0  80  {5         - [0] single asn.1-type
     - A-RELEASE response APDU - RLRE
 63  80  {6         - [APPLICATION 3] identifies RLRE
 80  01  00         - [0] reason, value 0 means normal
 *   La  ?
          -- the user information field may or may not be required
          - (not required for Group I)
 ?BE 80  {7       - [30] IMPLICIT SEQUENCE
 ?28 80  {8       - [EXTERNAL]
                 -- the transfer-syntax oid is not present this time
 ?02 01  03       - [INTEGER] this is the pcid for the application
                  - data
 ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                  -- (see note at end of 6.1)
 ?00 00  }8       - end of EXTERNAL
          -- conceivably there may be several EXTERNALS, probably in
          -- different presentation contexts (different pcids)
 ?00 00  }7       - end of user information field
 00  00  }6         - end of RLRE
 00  00  }5         - end of single asn.1-type
 00  00  }4         - end of PDV-list
 00  00  }3         - end of Presentation userdata

6.7 Deliberate abort

 It is not clear whether this is any use - just clearing the Transport
 connection will be more effective. It goes on T-DATA, but asks for
 the far-side to close the T-connection.
  1. Session ABORT SPDU

19 Ls {1 - SI of 25 is ABORT

 11  01  03      - Transport Disconnect PV, code 17
                 --  value = '...00011'b means please
                 -- release T-conn, user abort
 *   Ls  ?
 C1  11  {2      - Session User Data

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

  1. P-U-ABORT PPDU - ARU

A0 80 {3 - [0] implicit sequence for normal mode

 A0  80  {4      - [0] presentation-context-identifier-list
 30  80  {5      - [SEQUENCE]
 02  01  01      - [INTEGER]pcid for ACSE
 06  02  5101    - [OID] for acse transfer syntax = BER
 00  00  }5
          -- there will be one {6} group for each application
          -- presentation context that is used in this message
          -- if there is no user data, the {6} group can be
          -- omitted
 30  80  {6
 02  01  03      - [INTEGER] pcid for application data
 06  La  xxxxxx  - [OID] transfer syntax for application data
 00  00  }6
 00  00  }4      - end of presentation-context-identifier-list
 61  80  {7      - [APPLICATION 1], user data, fully-encoded
 30  80  {8      - [SEQUENCE] PDV-list
 02  01  01      - [INTEGER] pcid for ACSE as on CP PPDU
 A0  05  {9      - [0] single asn.1-type
     - A-ABORT APDU - ABRT
 64  80  {10     - [APPLICATION 4] identifies ABRT
 80  01  01      -  [0] value 1 is acse-service-provider
          -- the user information field may or may not be required
 ?BE 80  {11      - [30] IMPLICIT SEQUENCE
 ?28 80  {12      - [EXTERNAL]
                 -- the transfer-syntax oid is not present this time
                 -- (according to CULR-1)
 ?02 01  03       - [INTEGER] this is the pcid for the application
                  - data
 ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                  -- (see note at end of 6.1)
 ?00 00  }12      - end of EXTERNAL
          -- conceivably there may be several EXTERNALS, probably in
          -- different presentation contexts (different pcids)
 ?00 00  }11      - end of user information field
 00  00  }10     - end of ABRT
 00  00  }9      - end of single asn.1-type
 00  00  }8      - end of PDV-list
 00  00  }7      - end of Presentation user-data
 00  00  }3      - end of ARU-PPDU

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

6.8 Provider abort

 Generated when an internal error occurs (i.e., something has gone
 mildly (?) wrong in the cookbook implementation). Rather than accuse
 anyone of protocol errors, we just abort at session.
           ABORT SPDU
 19  03  {1         - SI=25 = ABORT SPDU
 11  01  09         - Transport Disconnect PV, code 17
                  -- value = '...01001'b  release T-conn
                  --  no reason
 *   Ls  ?

6.9 Abort accept

 If a Session abort (of any kind) is sent, it is possible that the
 far-end will send back an abort accept. If this happens, disconnect
 the transport. (The abort messages above do not propose that the
 transport connection be reused, and in this case, an abort accept is
 just the far-end passing the transport-disconnect initiative back.)
 This session message need never be sent - just disconnect transport
 on receiving an abort.
           ABORT ACCEPT SPDU
 1A  00  .         - SI=26 = ABORT ACCEPT SPDU, no parameters

7. References

 [CULR-1] ISO/IEC DISP 11188-1 - Information Technology -
 International Standardised Profile - Common Upper Layer Requirements
 - Part 1: Basic Connection oriented requirements (DISP ballot ends
 June 1994).
 [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal
 OSI upper layers facilities (A later draft will be proposed as ISP
 11188/3).
 [ISO8072] Information processing systems - Open Systems
 Interconnection - Transport service definition; ISO, 1986.
 [ISO8073] Information processing systems - Open Systems
 Interconnection - Transport protocol specification; ISO, 1986.
 [ISO8326] Information processing systems - Open Systems
 Interconnection - Basic connection oriented session service
 definition; ISO, 1987 (or review copy of revised text = ISO/IEC
 JTC1/SC21 N4657, April 1990).

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

 [ISO8327] Information processing systems - Open Systems
 Interconnection - Basic connection oriented session protocol
 specification; ISO, 1987 (or review copy of revised text = ISO/IEC
 JTC1/SC21 N4656, April 1990).
 [ISO8649] Information processing systems - Open Systems
 Interconnection - Service definition for the Association Control
 Service Element; ISO, 1989.
 [ISO8650] Information processing systems - Open Systems
 Interconnection - Protocol specification for the Association Control
 Service Element; ISO, 1989.
 [ISO8822] Information processing systems - Open Systems
 Interconnection - Connection-oriented presentation service
 definition; ISO, 1989.
 [ISO8823] Information processing systems - Open Systems
 Interconnection - Connection-oriented presentation protocol
 specification; ISO, 1989.
 [ISO8824] Information technology - Open Systems Interconnection -
 Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990.
 [ISO8825] Information technology - Open Systems Interconnection -
 Specification of Basic Encoding Rules for Abstract Syntax Notation
 One, ISO/IEC 1990.
 [RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
 the TCP", STD 35, RFC 1006, Northrop Research and Technology Center,
 May 1987.
 [ISO9594] Information technology - Open Systems Interconnection - The
 Directory; ISO/IEC, 1990.
 [RFC 1274] Barker, P., and S. Kille, "The COSINE and Internet X.500
 Schema", RFC 1274, University College London, November 1991.

8. Other Notes

 The Session, Presentation and ACSE standards have been the subject of
 considerable amendment since their first publication. The only one
 that is significant to this cookbook is Session addendum 2, which
 specifies session version 2 and unlimited user data. New editions of
 these standards, incorporating all the amendments, will be published
 during 1994.

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

 The coding choices made in the cookbook are (nearly) those made by
 the "Canonical Encoding Rules", which are a form of Basic Encoding
 Rules with no optionality, specified in the new edition of ISO/IEC
 8825. A defect report has been proposed against Presentation and
 ACSE, suggesting that a note to the protocol specifications recommend
 use of the canonical encoding options when sending, and then
 optimising for this on receipt.

9. Security Considerations

 Security issues are not discussed in this memo.

10. Author's Address

 Peter Furniss
 Peter Furniss Consultants
 58 Alexandra Crescent
 Bromley, Kent BR1 4EX
 UK
 Phone & Fax +44 81 313 1833
 EMail: P.Furniss@ulcc.ac.uk

Furniss [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1698.txt · Last modified: 1994/10/21 22:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki