pysnmp.sourceforge.net
HOME QUICK START DOCUMENTATION EXAMPLES DOWNLOAD
DEVELOPMENT | CONTACT |

MIB services

MIB builder
MIB View Controller
Management Instrumentation
Miscellaneous

See also

MIB variable

WARNING: you are reading historical documentation! Please, refer here.

ASN.1 standard

SNMP relies on Abstract Syntax Notation One (ASN.1) ITU-T standard . It is actually a family of standards targeting network systems interoperability and protocols development automation.

In theory, ASN.1 technology provides a complete solution for protocol development: new protocol could be expressed in terms of data structures described in a specialized formal language.

The ASN.1 notation is designed purely for data description. All data structures there are based on a small set of elementary data types, such as INTEGER or SEQUENCE OF some other types.

Whenever protocol designer wants to define a more precise, narrow set of valid values for a field, a subtype can be created from a base ASN.1 type or another subtype by tearing up a constraint on various data properties to parent ASN.1 type. For example, a subtype of in INTEGER may allow only arbitrary values of an integer.

Another way to create a subtype from existing type is to add or replace ASN.1 tag, which serves like an ID for a type. In this new type has all the same properties of its parent type but is now known under a different name.

Once something gets expressed in ASN.1 notation, it could then be automatically translated into a variety of platform-specific implementations. They are often take shape of a program written in some common programming language like C or Python.

This is where the major feature of ASN.1 emerges. ASN.1 text could be automatically compiled into a high-quality code, that handles all the nightmares of platform-specifics, virtually for free. This code would handle byte-ordering and value ranges, data structures validations and consistency issues.

But the most useful feature is its ability to represent data in a way suitable for transmission over a communication medium. This is called encoding in ASN.1, and also known as concrete or transfer syntax in computer science.

SNMP uses these features of ASN.1 for handling Managed Objects and guiding protocol operations.

Object Identifier

This technique is a simple, unambiguous, decentralized and extensible method of naming anything. It was developed within ASN.1 standard as one of its build-in data types.

An Object Identifier consists of a sequence of integers. Each integer in this sequence maps to a node in a tree, so iterating an OID traverses this tree from root to leaf, forming a branch. Nodes in OID tree hold a group of conceptually related objects. Nodes become more specific from root to leaves. Sub-trees, or parts of OID space, often become a courtesy of various organizations and individuals.

OIDs are conventionally written as a dot-separated sequence of integers, from left to right as from root to leaves. For example, .1.3.6.1 is an arbitrary OID.

For the purpose of making OIDs human-readable, integers in OIDs (AKA sub-OIDs) can be replaced with a textual labels. Consider .org.iso.dod.internet as a labeled version of the previous example. The numeric and labeled OID representations are invariant and may mix within a single OID.

ASN.1 data encoding

For several entities to exchange ASN.1 data items some common transmission protocol is needed. This protocol would have to be able to represent ASN.1 values in a platform-native way. This might require handling hardware and/or software specific issues such as varying integer sizes, byte ordering, character encoding and so on.

Besides data representation issues, this communication protocol would have to break up data being transmitted into small chunks. The reason is that most data transmission technologies handle only a few bits in a channel at any moment of time. After buffering and packing up few bits into larger chunks, most link-level protocols still handle information in small grains. Typical measurement is eight bit or octet.

For all the reasons mentioned above, ASN.1 family of standards suggests several methods of two-way ASN.1 data conversion protocols. They are sometimes referred to as data encoding or serialization.

SNMP uses somewhat restricted flavor of Basic Encoding Rules (BER) for its ASN.1 data serialization purposes. The SNMP-specific restrictions make BER encoding deterministic -- with these restrictions applied, there is a one-to-one mapping between ASN.1 value and octet-stream produced by BER encoder. Determinism in encoding makes it possible for trivial SNMP entities to reduce their SNMP engine implementation to opaque octet-streams manipulations.


Need help? Try PySNMP mailing lists or report to library maintainers.
SourceForge Logo