A to Z Archives - Page 175 of 176 - Network Encyclopedia

ASN.1, or Abstract Syntax Notation One, is an International Organization for Standardization (ISO) standard that provides a mechanism for encoding human-readable symbols into condensed binary form. Abstract Syntax Notation One (ASN.1), which is part of the X.400 and X.500 specifications, provides a standard way of formatting and encoding X.400-based e-mail messages for transmission over a network. More generally, ASN.1 is a method of specifying abstract objects that are intended for any form of serial transmission. ASN.1 is also used for defining objects in Management Information Base (MIB) files for Simple Network Management Protocol (SNMP). ASN.1 How it Works ASN.1 is similar in syntax to a programming language, and it allows the definition of different data types, data structures, arrays, classes, and other structures similar to those found in the C++ programming language. The presentation layer (layer 6) of the Open Systems Interconnection (OSI) reference model uses ASN.1 as the standard for specifying the syntax of information exchanged between applications at this layer. ASN.1 data types can be either simple or structured. ASN.1 data structures are encoded as octets in hexadecimal notation. These structures are then transmitted over the network as binary information. The Octet Encoding Rules (OER) were designed to be easy to implement and to produce encodings more compact than those produced by the Basic Encoding Rules (BER). In addition to reducing the effort of developing encoder/decoders, the use of OER can decrease bandwidth utilization (though not as much as the Packed Encoding Rules), save CPU cycles, and lower encoding/decoding latency. Subtypes Frequently the designer intends only some subset of the values of an ASN.1 type to be valid in some situation. For instance, in conveying a measure of humidity as a percentage, only numbers in the range 0 to 100 are valid, or when conveying a postal code only strings with certain characters and whose length falls within a certain range are to be permitted. Perhaps when some protocol message is used in a certain context, the optional checksum field is to be absent. These are all examples of constraints which can be expressed by defining a subtype of a suitable parent type. This is done by appending to the notation for the parent a suitable subtype specification. The result is itself a type and can be used anywhere a type is allowed. (Thus a subtype specification can also be applied to a subtype, in which case it may serve to further reduce the set of values). A subtype specification consists of one or more subtype value sets, separated by "|" (pronounced "or"). The whole list is in round brackets(()). For example in: Weekend ::= DaysOfTheWeek (saturday | sunday) The type Weekend is defined by appending a subtype specification to a parent type DaysOfThe Week. The subtype specification (the expression in round brackets) defines which of the values of DaysOfTheWeek are also to be values of Weekend. There are six different value set notations. Two of these are applicable to all parent types, others to only certain parent types. The value set notations that are applicable to all parent types are single value and contained subtype. The former notation is simply some value of the a parent type, the resulting value set consisting of that value alone. Examples of this are "saturday" and "sunday" above, each of which is a single value of DaysOfTheWeek. The contained subtype notation comprises the keyword INCLUDES, followed by some other subtype of the same parent type, and denotes the value set consisting of all the values in that subtype. For example, given: LongWeekend ::= DaysOfTheWeek (INCLUDES Weekend | monday) The type LongWeekend includes the three values saturday, sunday, and monday, the union of the value sets used in its definition. Each value set defines some subset of the values of the parent type. The resulting subtype has the values in the union of these subsets, which must be non-empty.. The value range notation can be used to subtype any type whose values are ordered (for example, the integer type). It involves specifying the lower and upper bounds of the range. A size range can be included for any type whose values have a defined size (for example, the bit string type). Here the value set includes all of the values whose size, measured in the appropriate units, is within the designated range. An alphabet limitation can be applied only to character string types and allows only the values formed from some subset of the characters. Finally, inner subtyping can be employed to define value sets of structured types (for example, set and set-of-types). Here the value set includes all those values whose component values meet certain constraints. Names Several categories of object in ASN.1 have names by which they can be referenced.We have actually met examples of each of these kinds of name above, as follows: type reference: WeatherReportvalue reference: sampleReportidentifier: humidity It is very important that names are chosen, as in these examples, to have significance to the human reader. Indeed, if names are chosen correctly (and appropriate layout conventions followed), then the essence of some piece of ASN.1 can often be grasped, even by someone unskilled in the language. All names in ASN.1 are character strings drawn from the same set of characters, namely: upper-case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ lower-case letters: abcdefghijklmnopqrstuvwxyz decimal digits: 0123456789 hyphen: - The first character in a name must be a letter. The case of the letters in a name is significant so that "borders" and "Borders" are different names. In fact, the case of the initial letter is of special significance, as type references (and also module references, see below) must start with an upper-case letter, while value references and identifiers must start with a lower-case letter. It is not a good idea, however, to use two or more names which differ only by the case of some of their letters. The names chosen by users must be chosen so as to avoid clashing with the reserved words of ASN.1 (which include most of the keywords of the language). Since the keywords are generally in upper-case, the use of lower-case letters in names makes it easy to adhere to this, and also generally makes the names more readable. There is no upper limit on the length of names, and this allows the use of an appropriate phrase as the name of an object. Examples of legal (and probably appropriate) names are: UnformattedPostalAddressAccess-control-listACLTemperatureMverifyPDUrecordLowib-g3facsimile-non-basic-parameters The first few of these examples are valid for use as type references, the others as identifiers or value references. Notice that two different conventions are used in these examples for forming multi-word names since spaces are not valid in names and thus can not be used to separate the individual works. SEE ALSO: Abstract Syntax Notation One (ASN.1) - The Tutorial and Reference