New Document
Computer Science
Computer Catlog
Comm Network Catlog

Network Components
Network Types
The OSI Model
Protocol Notations
Physical Layer
Modulation
Transmission Media
Multiplexing
Digitization and Synchronization
Physical Layer Standards
DataLink Layer
Error Checking
Retrans - Flow Control
Sliding Window Protocol
Data Link Layer Standards
Network Layer
Switching Methods
Routing
Congestion Control
Internetworking
Network Sub layers
Transport Layer
Transport Protocol
Transport Layer Standards
Session Layer
Session Layer Role
Session Protocol
Presentation Layer
Abstract Syntax Notation
Application Layer
Common Application
Specific Application
Message Handling
LAN
IEEE 802 Standards
ANSI FDDI Standard
ISDN
Frame Relay
Broadband ISDN & ATM

Abstract Syntax Notation One


    Abstract Syntax Notation One (ASN.1) is a formal language which has been designed to enable applications share a common data definition. It supports the programming language-independent and machine-independent definition of data. ASN.1 is used by the application layer for defining application data, and by the presentation layer for defining the protocol data units used for exchanging the data. A separate notation, BER, is used for specifying concrete syntaxes. These two are discussed in the next two sections.


Definitions in ASN.1


    A set of ASN.1 data type definitions is embodied by a module. The general (but simplified) structure of a module definition is as follows:

Module-name DEFINITIONS ::= BEGIN
Type-assignment1
...
Type-assignmentn
END

where items appearing in italics are place holders, and items appearing in upper case throughout are literals. This definition simply states that a module definition consists of one or more type assignments. Each type assignment is of the form:

Type-name ::= Type-definition

A type definition may be just a reference to a simple type or consist of a structured type. An example of a simple type would be:

PacketLifetime ::= INTEGER.

    A structured type is always defined in terms of other (predefined or userdefined) types. An example of a structured type would be:

Message ::= SEQUENCE {
protocol INTEGER,
ack-needed BOOLEAN,
source Address,
destination Address,
data BIT STRING
}

which defines a Message as an ordered sequence of five other components. Addressdenotes a user-defined type which we assume has already been defined.

    Tagged types are used to resolve potential ambiguity in type definitions. For example, had Message been defined as a SET instead of a SEQUENCE, an ambiguity would arise between source and destination components, because both these are of the same type. This presents no problems at the abstract syntax level, 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. 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.


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, tag number, and a flag which indicates the form of the element as being primitive or structured.

* 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.

    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.

    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.

* 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. 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.

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.