View page as slide show

Communications Software, Protocols and architecture

Background

  • Communication system often contains heterogeneous hardware.
    • Web is browsed with huge variety devices. Web servers are running on variety of platforms
  • Different hardware have different ways to represent data
    • little endian vs big endian
  • Data types have different internal representation
    • one's complement vs two's complement in integer , ASCII vs unicode for characters.
  • Programming languages have their own ways to describe data
    • use of NULL, string ending character etc.
  • Data structures exchanged between applications are more and more complicated
    • Data structures are represented in variety of ways.
  • There is a need for agreement on communication, how to represent the transmitted data.

Transmission of data

  • Data to be transmitted is first encoded to a message.
    • Data is combined with meta-data.
    • Local format is encoded to transmission format.
  • Sender sends message to receiver
  • Receiver decodes the message and uses the data.

Messages

  • Message is series of bits logically divided into various fields
    • At minimum there is a field describing the message type
  • In order for receiver to understand the message, there has to be set of rules to define the message structure
    • Putting variables in application in correct format to create message is called message encoding

Message Content

  • Header
    • Gives information about the packet and its handling
      • Message identification or type
      • Size of the message, if not specified otherwise
      • routing information (addressing, connection id…)
  • Payload
    • The data that is carried by the protocol
  • Trailer (used sometimes)
    • contains information dependent on the content of the message e.g. checksum

Message Format

  • Describes
    • The structure of message e.g. how different fields are separated from each other
    • the data type of each field (binary, integer, character…)
    • Message boundaries, how messages are separated from each other
  • Fields can be separated by
    1. Predetermined set structure
      • Bit/Byte count
    2. Notation that states the beginning and end of different fields
      • Bit oriented
      • Character oriented

Bit/Byte count

Simple TCP header

  • The message size and structure is set
    • Each field has a set location in the message
    • In principle the size of each field is predetermined
    • For fields that can have variable size (e.g. payload), a separate field is required where the current size is stated.
  • Messages are hard to interpret by human
  • No overhead
    • except the possible size fields
  • used in e.g. TCP/IP

Bit oriented

bit-oriented.jpg

  • Fields are separated with a small set of unique bit patterns i.e. flags
    • At minimum the start and end message flags
  • Fields are usually on predetermined order
    • only field separation flag is required along with start and end message flags.
  • Bit stuffing required if data in fields can consist of bit patterns used as identifiers
  • Used in lower communication layers e.g. HDLC

Character oriented

  • Message size is multiplier of character size (usually n* 8 bits)
    • Depends on the used character type (ASCII, ISO 10646, UTF …)
    • Character type has to be defined in specification or in message
  • Character stuffing may be required.
    • Binary data can contain any set of characters
  • Is easier to understand for human than bit oriented
  • More overhead than in bit oriented formats
  • On higher layers the notation expresses the meaning of the field
  • high level notations e.g. XML

Message envelopes

  • Communication in layered architecture
    • PDU for horizontal communication
    • Primitive for vertical communication
  • The upper layer data is enveloped by the lower layer
  • Layer n-PDU is encoded in n-1-primitive and transmitted to lower layer
    • layer n-1 uses primitive headers as help to generate layer n-1 PDU
  • layer n-1 PDU may contain whole layer n PDU or just part of it
    • n-1 layer may divide the layer n data to smaller packets
    • At the receiving side the data is reassembled by layer n-1 before given to layer n inside primitive.

Message size

  • The more data there is the better is header/data ratio.
  • The longer the message the more likely it is that there will be error during it's transmission
    • lot of retransmissions in
    • Issue in transport layer and below
  • Message have to arrive completely before it can be handled.
    • Big messages can fill buffers

Abstract notation

  • Abstract notation describes the message content in abstract format
    • Is independent from implementation environment
    • Is independent from implementation language
    • Is independent from the encoding (bitcount, Byte oriented, xml…)
      • Can be used to derive different encodings
  • Abstract notation is needed because
    • The message in the format in which it is transmitted (encoded format) can be sometimes hard to understand
      • Helps to understand the content of message
    • Ease the implementation of communication protocol in different environments
      • And different languages

What is ASN.1

  • Defined by ISO, as generic means of allowing differing computer systems, with different internal data representations to interchange data.
    • Vendor, platform & language independent notation for specifying data structures at a high level of abstraction
    • Supported by encoding rules that determine the precise bit patterns to represent values of these data-structures that will be transferred over computer network.
    • Supported by tools which map ASN.1 notation into data structure definition in a computer language of choice.
  • International standard
    • defined in several ITU-T standards
      • X.680,X.681,X.682,X.683
      • X.690,X.691 for encoding rules
  • Used extensively by ISO and ITU-T to define protocol messages
    • From the approximately 1000 ITU standards roughly 10% make use of ASN.1
    • Extensively used in areas like ISDN supplementary services, IN protocols and GSM.
  • There is tendency to use ASN.1 in specification of conformance tests even when the protocol specification is not defined in ASN.1

ASN.1 notation

  • Naming rules
    • Names of fields, elements & items can be arbitrarily long. Quite long names are common
    • Names of Types must start with uppercase
    • Names of Identifiers must start with lowercase
  • Basic datatypes
    • Builtin: INTEGER, REAL, BOOLEAN, BITSTRING, NULL,VisibleString, UTF8String, UTCTime…
    • ANY type is used when the type is out of asn.1 scope
  • Production Mechanisms for constructing more complex data types
    • SEQUENCE, SEQUENCE OF, SET, SET OF, CHOICE …
  • parameter options
    • DEFAULT is used to set default value
    • OPTIONAL is used to denote optional fields in complex datatypes

Additional features

  • Sub typing
    • possibility to take subset of existing type e.g. INTEGER (1..56)
    • complex sub typing allows using complex constructions
  • Soft typing
    • For defining constrains to any type.
  • Macros
    • Way to define new notation that can construct and refer ASN.1 types e.g. create shorthand notation

Structuring an ASN.1 Specification

  • ASN.1 definitions are defined in modules.
  • Modules contain a complete set of type definitions that are self contained.
  • Modules can import definitions from other modules, and export definitions to other modules.
  • IMPORTS - specifies list of types defined in other modules
  • EXPORTS - specifies list of types defined in this module that are available for use in other modules
    • if EXPORTS statements is omitted all types are available
    • EXPORTS ; (empty list of types) means that nothing is available

Encoding ASN.1

  • An abstract syntax is converted into a transfer syntax using an encoding rule.
  • ASN.1 has several encoding rules that can be used to provide different ways to represent data during transmission
    • Octet stream (BER), XML …
  • ASN.1 ASN.1 compilers can be used to create C structures or C++ classes from ASN.1 specifications.
    • Public domain compilers do not support all features of ASN.1

Basic Encoding rules

  • Basic encoding rules defined in ISO 8825/ X.690.
    • X.690 is very inefficient, so Packed Encoding Rules (X.691) are defined which are more compact
  • Each data item is encoded to contain:
    • an identifier (tag or type)
    • a length indicating the size of the data field
    • a data, which contains the actual contents of the object.
    • an optional end-of-content flag if data length is unknown
  • Aligned on octet boundaries

ASN.1 compiler

  • Environment and language specific compiler of ASN.1 document
    • Creates for example c structures or c++ classes from ASN.1 specification
  • Used to create conversion routines from local syntax to transfer syntax
    • Provides functions for encoding and decoding the data folloqing used encoding rules e.g. BER

ASN.1 uses

Summary of ASN.1

  • Provides notation for specification of complex data types base on simple types and production rules
  • Specifies also how data values shall be specified
  • Defines Encoding rules which define how data will be represented between two systems (on the “line”)
  • ASN.1 Tools (e.g. casn) are available which provide support for ASN.1 data manipulation and encoding/decoding for various OSs and programming languages
Last modified: 2013/07/01 14:42