www.pragsoft.com Chapter 7: The Presentation Layer
91
but as far as the transfer syntax is concerned, source and destination can occur in any order and are therefore indistinguishable. The ambiguity is resolved by simply
tagging the clashing components:
Message ::= SET { protocol
INTEGER, ack-needed
BOOLEAN, source
[0] Address, destination
[1] Address, data
BIT STRING }
Tags represent the general mechanism for encoding type information for use in the transfer syntax. Overall, there are four classes of tags. These are summarized in
Figure 7.77. Explicit use of universal tags is redundant because each of these has a corresponding built-in type. So, for example, instead of [UNIVERSAL 1] which
represents the built-in boolean type, the keyword BOOLEAN is used.
Figure 7.77 The four tag classes of ASN.1. Tag Class
Usage Description
Universal Type-name ::=
[UNIVERSAL n] Type-name Application-independent types of
general use. It represents the simple and structured built-in types described
earlier.
Application-wide Type-name ::=
[APPLICATION n] Type-name Application-specific types which have
been devised to serve the needs of application layer standards.
Context-specific [k] Type-name
... [n] Type-name
Used for distinguishing between the clashing types of the components of a
group. Private-use
Type-name ::= [PRIVATE n] Type-name
Reserved for the private use of applications, outside the scope of the
standards.
7.2.2. Basic Encoding Rules
The Basic Encoding Rules BER of ASN.1 provide a mechanism for mapping an abstract syntax definition of data in ASN.1 to a representative transfer syntax.
The transfer syntax is defined as a set of transfer types, which are specified as
data elements. A data element consists of three fields:
•
Identifier . This uniquely identifies the data type. It is an encoding of a tag class,
a tag number, and a flag which indicates the form of the element as being primitive or structured see Figure 7.78.
92 Communication Networks
Copyright © 2005 PragSoft
•
Length
. This is an encoding of the length of the contents field in octets.
•
Contents . This is an encoding of the actual value of the data based on the type
information provided by the identifier field.
Figure 7.78 Data element forms.
Primitive Element:
Structured Element:
Identifer Length
Contents
Identifer Length
...
Identifer Length Contents
Identifer Length Contents
May be a primitive or another structured element
The data element always consists of an integral number of octets, where the bits in each octet are ordered left to right i.e., the most significant bit appearing on the
left. The identifier field of a data element is encoded in one or more octets as follows. Bits 7 and 8 encode the tag class. Bit 6 encodes the data element form. The
remaining five bits encode the different types within the same tag class; additional octets are used if the five bits are insufficient see Figure 7.79.
Figure 7.79 Encoding of the identifier field of a data element. Bit
Identifier Encoding
8 Tag Class:
00 = Universal 01 = Application-wide
7 10 = Context-specific
11 = Private-use 6
Form: 0 = Primitive
1 = Structured 5
Tag Type: 4
• If no more than 32 types, use 00000-11110 3
• If more than 32 types, use 11111, followed by an arbitrary number of 2
intermediate octets of the form: 1bbbbbbb
1 and terminated by an octet of the form:
0bbbbbbb
The length field of a data element is encoded as one or more octets in one of three forms:
•
Short Form . This is one octet long, with bit 8 of the octet permanently set to 0
i.e., 0bbbbbbb and therefore can represent content fields of up to 127 octets long.
•
Long Form
. This can be up to 128 octets long, where the first octet is of the form 1bbbbbbb, whose least significant 7 bits denote the number of octets to
follow.
www.pragsoft.com Chapter 7: The Presentation Layer
93
•
Indefinite Form
. This is one octet long and the octet has the fixed value 10000000. End of the contents field which may have an arbitrary length is
denoted by two consecutive zero octets i.e., 00000000 00000000. This length form is only available to structured elements.
The contents field of a data element is encoded according to the data type. Figure 7.80 summarizes the encoding used for the built-in simple types. Contents
encoding for values of structured types uses structured elements. For a sequence, for example, each sequence element is encoded as a data element within a structured
element.
Figure 7.80 Encoding of the contents field of a data element. Built-in Type
Contents Encoding
BOOLEAN FALSE = all bit zero, TRUE = at least one bit non-zero.
INTEGER 2’s complement binary number.
REAL Encoded as a sign bit and three separate integer quantities: base,
mantissa, and exponent i.e., scientific notation. BIT STRING
Zero or more bits. The left-most octet denotes the number of unused bits in the last octet.
OCTET STRING zero or more octets.
ENUMERATED Individual items encoded as sequenced INTEGER values.
NULL Has no contents.
7.3. Presentation Protocol
The presentation protocol is very similar to the session protocol and the Presentation Protocol Data Units
PPDUs differ from their corresponding SPDUs only in a few minor details. The only real major protocol addition at the
presentation layer is the ability to negotiate the defined context set, both at connection time and during data transfer.
Defined context set negotiation involves a presentation service user proposing a set of abstract syntaxes, for each of which one or more transfer syntaxes is also
proposed. Each ‘abstract syntax + transfer syntaxes’ pair is identified by a context identifier
. The peer service user individually accepts or rejects each of the pairs. For each accepted pair, it also selects one of the proposed transfer syntaxes. This
identifies a set of presentation contexts and establishes the defined context set. Because there may be more than one presentation context in the defined context
set, each data transfer is tagged with the context identifier of the presentation context to which it conforms. The receiving end uses this tag to determine how to decode the
data.
