DISTRIBUTED APPLICATIONS

DISTRIBUTED APPLICATIONS

 In the OSI model, such

applications occupy the application layer and are directly supported by the presentation

layer. In the TCPIIP protocol suite, such applications typically rely on TCP

or UDP for support.

We begin this lesson with an introduction to Abstract Syntax Notation One

(ASN.l), which has become an important universal language for defining representations

of data structures and protocol formats, and which has gained wide use for

defining application-level protocols.

Next, we examine a number of quite different applications that give the reader

a feel for the range and diversity of applications supported by a communications

architecture. The first, network management, is itself a support-type application,

designed to assure the effective monitoring and control of a distributed system. The

specific protocol that is examined is the Simple Network Management Protocol,

version 2 (SNMPv2),which is designed to operate in both the TCPIIP and OSI environments.

Next, electronic mail applications are considered, with the SMTP and

MIME standards as examples; SMTP provides a basic email service, while MIME

adds multimedia capability to SMTP. Finally, we look at HTTP, which is the support

application on which the World Wide Web (WWW) operates; in discussing

H TT P , we need to first look at the concept of Uniform Resource Locators and Universal

Resource Identifiers. Figure 19.1 highlights the position of these protocols

within the TCP/IP protocol suite.

 

ABTRACT SYNTAX NOTATION (ASN.1)

One of the most significant developments in computer communications in recent

years is the development of ASN.l. which is now widely used in the development of

both OSI-related standards and TCPIIP-related standards. It is used to define the

format of protocol data units (PDUs), the representation of distributed information,

and operations performed on transmitted data. A basic understanding of

ASN.l is essential for those who wish to study and work in this field.

Before examining the details of ASN.l, we need to introduce the concept of

an abstract syntax. Then, we will look at the fundamentals of ASN.l. Next, a special

and important facility, the ASN.1 macro facility, is examined.

Abstract Syntax

Table 19.1 defines some key terms that are relevant to a discussion of ASN.1, and

Figure 19.2 illustrates the underlying concepts.

For purposes of this discussion, a communications architecture in an end system

can be considered to have two major components. The data transfer component

is concerned with the mechanisms for the transfer of data between end systems.

In the case of the TCPIIP protocol suite, this component would consist of TCP

or UDP on down. In the case of the OSI architecture, this component would consist

of the session layer on down. The application component is the user of the data

transfer component and is concerned with the end user's application. In the case of

the TCPIIP protocol suite, this component would consist of an application, such as

SNMP, FTP, SMTP, or TELNET. In the case of OS1, this component actually consists

of the application layer, which is composed of a number of application service

elements, and the presentation layer.

As we cross the boundary from the application to the data transfer component,

there is a significant change in the way that data are viewed. For the data

transfer component, the data received from an application are specified as the

binary value of a sequence of octets. This binary value can be directly assembled

into service data units (SDUs) for passing between layers, and into protocol data

units (PDUs) for passing between protocol entities within a layer. The application

component, however, is concerned with a user's view of data. In general, that view

is one of a structured set of information, such as text in a document, a personnel file,

an integrated data base, or a visual display of image information. The user is primarily

concerned with the semantics of data. The application component must provide

a representation of this data that can be converted to binary values; that is, it

must be concerned with the syntax of the data.

The approach illustrated in Figure 19.2 to support application data is as follows.

For the application component, information is represented in an abstract syntax

that deals with data types and data values. The abstract syntax formally specifies

data independently from any specific representation. Thus, an abstract syntax

has many similarities to the data-type definition aspects of conventional programming

languages such as Pascal, C, and Ada, and to grammars such as Backus-Naur

Form (BNF). Application protocols describe their PDUs in terms of an abstract

syntax.

This abstract syntax is used for the exchange of information between application

components in different systems. The exchange consists of application-level

PDUs, which contain protocol control information and user data. Within a system,

the information represented using an abstract syntax must be mapped into some

form for presentation to the human user. Similarly, this abstract syntax must be

mapped into some local format for storage. For example, such a mapping is used in

the case of network management information. In addition, it is becoming common

to use an abstract syntax to define the data elements in local storage. Thus, the

abstract syntax notation is employed by a user to define network management

information; the application must then convert this definition to a form suitable for

local storage.

The component must also translate between the abstract syntax of the application

and a transfer syntax that describes the data values in a binary form, suitable

for interaction with the data transfer component. For example, an abstract syntax

may include a data type of character; the transfer syntax could specify ASCII or

EBCDIC encoding.

The transfer syntax thus defines the representation of the data to be

exchanged between data-transfer components. The translation from abstract syntax

to the transfer syntax is accomplished by means of encoding rules that specify the

representation of each data value of each data type.

This approach for the exchange of application data solves the two problems

that relate to data representation in a distributed, heterogeneous environment:

There is a common representation for the exchange of data between differing

systems.

Internal to a system, an application uses some particular representation of

data. The abstractltransfer syntax scheme automatically resolves differences

in representation between cooperating application entities.

The fundamental requirement for selection of a transfer syntax is that it support

the corresponding abstract syntax. In addition, the transfer syntax may have

other attributes that are not related to the abstract syntaxes that it can support. For

example, an abstract syntax could be supported by any one of four transfer syntaxes,

which are the same in all respects except that one provides data compression,

one provides encryption, one provides both, and one provides neither. The choice

of which transfer syntax to use would depend on cost and security considerations.

ASN.1 Concepts

The basic building block of an ASN.l specification is the module. We begin this section

by looking at the top-level structure of the module. Then, we introduce some

lexical conventions used in ASN.l definitions. Next, the data types defined in

ASN.l are described. Finally, examples of the use of ASN.l are given.

Module Definition

ASN.l is a language that can be used to define data structures. A structure definition

is in the form of a named module. The name of the module can then be used to

reference the structure. For example, the module name can be used as an abstract

syntax name; an application can pass this name to the presentation service to specify

the abstract syntax of the application PDUs that the application wishes to

exchange with a peer application entity.

Modules have the basic form,

<modulereference> DEFINITIONS ::=

BEGIN

EXPORTS

IMPORTS

AssignmentList

End

The modulereference is a module name followed optionally by an object identifier

to identify the module. The EXPORTS construct indicates which definitions

in this module may be imported by other modules. The IMPORTS construct indicates

which type and value definitions from other modules are to be imported into

this module. Neither the IMPORTS or EXPORTS constructs may be included

unless the object identifier for the module is included. Finally, the assignment list

consists of type assignments, value assignments, and macro definitions. Macro definitions

are discussed later in this section. Type and value assignments have the

form,

The easiest way to describe the syntax is by example. First, we need to specify

some lexical conventions.

Lexical Conventions

ASN.l structures, types, and values are expressed in a notation similar to that of a

programming language. The following lexical conventions are followed:

1. Layout is not significant; multiple spaces and blank lines can be considered as

a single space.

2. Comments are delimited by pairs of hyphens (--) at the beginning and end of

the comment, or by a pair of hyphens at the beginning of the comment and the

end of the line as the end of the comment.

3. Identifiers (names of values and fields), type references (names of types), and

module names consist of upper- and lowercase letters, digits, and hyphens.

4. An identifier begins with a lowercase letter.

5. A type reference or a module name begins with an uppercase letter.

6. A built-in type consists of all capital letters and is a commonly used type for

which a standard notation is provided.

Abstract Data Types

ASN.l is a notation for abstract data types and their values. A type can be viewed

as a collection of values. The number of values that a type may take on may be infinite.

For example, the type INTEGER has an infinite number of values.

We can classify types into four categories:

Simple. These are atomic types, with no components.

Structured. A structured type has components.

Tagged. These are types derived from other types.

Other. This category includes the CHOICE and ANY types, defined later in

this section.

Every ASN.l data type, with the exception of CHOICE and ANY, has an

associated tag. The tag consists of a class name and a nonnegative integer tag number.

There are four classes of data types, or four classes of tag:

Universal. Generally useful, application-independent types and construction

mechanisms; these are defined in the standard and are listed in Table 19.2.

Application-wide. Relevant to a particular application; these are defined in

other standards.

Context-specific. Also relevant to a particular application, but applicable in a

limited context.

Private. Types defined by users and not covered by any standard.

A data type is uniquely identified by its tag. ASN.l types are the same if and

only if their tag numbers are the same. For example, UNIVERSAL 4 refers to

OctetString, which is of class UNIVERSAL and has tag number 4 within the class.

A simple type is one defined by directly specifying the set of its values. We

may think of these as the atomic types; all other types are built up from the simple

types. The simple data types in the UNIVERSAL class can be grouped into several

categories, as indicated in Table 19.2; these are not "official" categories in the standard

but are used here for convenience.

The first group of simple types can be referred to, for want of a better word,

as basic types. The Boolean type is straightforward. The Integer type is the set of

positive and negative integers and zero. In addition, individual integer values can be

assigned names to indicate a specific meaning. The Bitstring is an ordered set of

zero or more bits; individual bits can be assigned names. The actual value of a Bit-

String can be specified as a string of either binary or hexadecimal digits. Similarly,

an OctetString can be specified as a string of either binary or hexadecimal digits.

The Real data type consists of numbers expressed in scientific notation (mantissa,

base, exponent); that is,

The mantissa (M) and the exponent (E) may take on any integer values, positive or

negative; a base (B) of 2 or 10 may be used.

Finally, the Enumerated type consists of an explicitly enumerated list of integers,

together with an associated name for each integer. The same functionality can

be achieved with the Integer type by naming some of the integer values; but,

because of the utility of this feature, a separate type has been defined. Note, however,

that although the values of the enumerated type are integers, they do not have

integer semantics. That is, arithmetic operations should not be performed on enumerated

values.

Object types are used to name and describe information objects. Examples of

information objects are standards documents, abstract and transfer syntaxes, data

structures, and managed objects. In general, an information object is a class of information

(e.g., a file format) rather than an instance of such a class (e.g., an individual

file). The Object identifier is a unique identifier for a particular object. Its value

consists of a sequence of integers. The set of defined objects has a tree structure,

with the root of the tree being the object referring to the ASN.l standard. Starting

with the root of the object identifier tree, each object-identifier component value

identifies an arc in the tree. The Object descriptor is a human-readable description

of an information object.

ASN.l defines a number of character-string types. The values of each of these

types consists of a sequence of zero or more characters from a standardized character

set.

There are some miscellaneous types that have also been defined in the UNIVERSAL

class. The Null type is used in places in a structure where a value may

or may not be present. The Null type is simply the alternative of no value being

present at that position in the structure. An External type is one whose values are

unspecified in the ASN.l standard; it is defined in some other document or standard

and can be defined using any well-specified notation. UTCTime and Generalized-

Time are two different formats for expressing time. In both cases, either a universal

or local time may be specified.

Structured types are those consisting of components. ASN.l provides four

structured types for building complex data types from simple data types:

* SEQUENCE

SEQUENCE-OF

* SET

* SET-OF

The Sequence and Sequence-of types are used to define an ordered list of values

of one or more other data types; this is analogous to the record structure found

in many programming languages, such as COBOL. A Sequence consists of an

ordered list of elements, each specifying a type and, optionally, a name. The notation

for defining the sequence type is as follows:

SequenceType ::= SEQUENCE {ElementTypeList] I SEQUENCE ( }

ElementTypeList ::= ElementType I ElementTypeList, ElementType

ElementType ::=

NamedType I

NamedType OPTIONAL I

NamedType DEFAULT Value I

COMPONENTS OF Type

A NamedType is a type reference with or without a name. Each element definition

may be followed by the keyword OPTIONAL or DEFAULT. The

OPTIONAL keyword indicates that the component element need not be present in

a sequence value. The DEFAULT keyword indicates that, if the component element

is not present, then the value specified by the DEFAULT clause will be

assigned. The COMPONENTS OF clause is used to define the inclusion, at this

point in the ElementTypeList, of all the ElementType sequences appearing in the

referenced type.

A Sequence-of consists of an ordered, variable number of elements, all of one

type. A Sequence-of definition has the following form:

SequenceOffype ::= SEQUENCE OF Type I SEQUENCE

The notation SEQUENCE is to be interpreted as SEQUENCE-OF ANY; the

type ANY is explained in a later subsection.

A Set is similar to a Sequence, except that the order of the elements is not significant;

the elements may be arranged in any order when they are encoded into a

specific representation. A Set definition has the following form:

SetType :: = SET (ElementTypeList) I SET { )

Thus, a set may include optional, default, and component-of clauses.

A Set-of is an unordered, variable number of elements, all of one type. A Setof

definition has the following form:

SetOffype ::= SET OF Type I SET

The notation SET is to be interpreted as SET OF ANY; the type ANY is

explained in a later subsection.

The term tagged type is somewhat of a misnomer, as all data types in ASN.l

have an associated tag. The ASN.l standard defines a tagged type as follows:

A type defined by referencing a single existing type and a tag; the new type is isamorphic

to the existing type, but is distinct from it. In all encoding schemes, a

value of the new type can be distinguished from a value of the old type.

Tagging is useful to distinguish types within an application. It may be desired

to have several different type names, such as Employee-name and Customer-

name, which are essentially the same type. For some structures, tagging is

needed to distinguish component types within the structured type. For example,

optional components of a SET or SEQUENCE type are typically given distinct context-

specific tags to avoid ambiguity.

There are two categories of tagged types: implicitly tagged types and explicitly

tagged types. An implicitly tagged type is derived from another type by replacing

the tag (old class name, old tag number) of the old type with a new tag (new class

name, new tag number). For purposes of encoding, only the new tag is used.

An explicitly tagged type is derived from another type by adding a new tag to

the underlying type. In effect, an explicitly tagged type is a structured type with one

component: the underlying type. For purposes of encoding, both the new and old

tags must be reflected in the encoding.

An implicit tag results in shorter encodings, but an explicit tag may be necessary

to avoid ambiguity if the tag of the underlying type is indeterminate (e.g., if the

underlying type is CHOICE or ANY).

The CHOICE and ANY types are data types without tags; the reason for this

is that when a particular value is assigned to the type, then a particular type must be

assigned at the same time. Thus, the type is assigned at "run time."

The CHOICE type is a list of alternative known types. Only one of these types

will actually be used to create a value. It was stated earlier that a type can be viewed

as a collection of values. The CHOICE type is the union of the sets of values of all

of the component types listed in the CHOICE type. This type is useful when the values

to be described can be of different types depending on circumstance, and all the

possible types are known in advance.

The notation for defining the CHOICE type is as follows:

ChoiceType :: = CHOICE {AlternativeTypeList]

AlternativeTypeList ::= NamedType I AlternativeTypeList, NamedType

The ANY type describes an arbitrary value of an arbitrary type. The notation

is simply

AnyType :: = ANY

This type is useful when the values to be described can be of different types

but the possible types are not known in advance.

Subtypes

A subtype is derived from a parent type by restricting the set of values defined for

a parent type. That is, the set of values for the subtype are a subset of the set of values

for the parent type. The process of subtyping can extend to more than one level:

that is, a subtype may itself be a parent of an even more restricted subtype.

Six different forms of notation for designating the values of a subtype are provided

in the standard. Table 19.3 indicates which of these forms can be applied to

particular parent types. The remainder of this subsection provides an overview of

each form.

A single-value subtype is an explicit listing of all of the values that the subtype

may take on. For example,

SmallPrime ::= INTEGER ( 2 | 3 | 5 |7 | 11 | 13 | 17 | 19 | 23 |29 )

In this case, SmallPrime is a subtype of the built-in type INTEGER. As

another example,

Months ::= ENUMERATED { january (I),

february (2),

march (3),

april (4),

may ( 5) ,

june (6),

JULY (7),

august (8),

september (9),

october (l0),

november (11),

december (12) ]

First-quarter ::= Months ( january I february I march )

Second-quarter ::= Months ( april I may I june )

d

First-quarter and Second-quarter are both subtypes of the enumerated type

Months.

A contained sUbtype is used to form new subtypes from existing subtypes. The

contained subtype includes all of the values of the subtypes that it contains. For

example,

First-half ::= Months ( INCLUDES First-quarter | INCLUDES Secondquarter

)

A contained subtype may also include listing explicit values:

First-third ::= Months ( INCLUDES First-quarter I april )

A value-range subtype applies only to INTEGER and REAL types; it is specified

by giving the numerical values of the endpoints of the range. The special values

PLUS-INFINITY and MINUS-INFINITY may be used. Also, the special values

MIN and MAX may be used to indicate the minimum and maximum allowable

values in the parent. Each endpoint of the range is either closed or open. When

open, the specification of the endpoint includes the less-than symbol (<). The following

are equivalent definitions:

PositiveInleger ::= INTEGER (O<..PLUS-INFINITY)

PositiveInteger ::= INTEGER (l..PLUS-INFINITY)

PositiveInteger ::= INTEGER (O<..MAX)

PositiveInteger ::= INTEGER (l..MAX)

The following are equivalent:

NegativeInteger :: = INTEGER (MINUS-INFINITY..<O)

NegativeInteger :: = INTEGER (MINUS-INFINITY..-1)

NegativeInteger ::= INTEGER (MIN..<O)

NegativeInteger ::= INTEGER (MIN..-1)

The permitted-alphabet constraint may only be applied to character string

types. A permitted-alphabet type consists of all values (strings) that can be constructed

using a subalphabet of the parent type. Examples are

A size constraint limits the number of items in a type. It can only be applied

to the string types (bit string, octet string, character string) and to Sequence-of and

Set-of types. The item that is constrained depends on the parent type, as follows:

Type Unit of Measure

bit string bit

octet string octet

character string character

sequence-of component value

set-of component value

As an example of a string type, Recommendation X.121 specifies that international

data numbers, which are used for addressing end systems on public data

networks, including X.25 networks, should consist of at least 5 digits but not more

than 14 digits; this could be specified as follows:

ItlDataNumber :: = DigitString ( SIZE ( 5..14 ) )

Now consider a parameter list for a message that may include up to 12

parameters:

ParameterList :: = SET SIZE ( 0..12 ) OF Parameter

An inner-type constraint can be applied to the sequence, sequence-of, set, setof,

and choice types. An inner subtype includes in its value set only those values

from the parent type that satisfy one or more constraints on the presence and/or values

of the components of the parent type. This is a rather complex subtype, and only

a few examples are given here.

Consider a protocol data unit (PDU) that may have four different fields, in no

particular order:

PDU ::= SET { alpha [0] INTEGER,

beta [I] IA5String OPTIONAL,

gamma [2] SEQUENCE OF Parameter,

delta [3] BOOLEAN ]

To specify a test that requires the Boolean to be false and the integer to be

negative,

TestPDU ::= PDU ( WITH COMPONENTS { ..., delta (FALSE), alpha

(MIN ... <O)))

To further specify that the beta parameter is to be present and either 5 or 12

characters in length,

FurtherTestPDU ::= TestPDU (WITH COMPONENTS [..., beta (SIZE

(5 1 12) PRESENT))

As another example, consider the use of inner subtyping on a sequence-of

construct

Text-block ::= SEQUENCE OF VisibleString

Address ::= Text-block ( SIZE (1..6) 1 WITH COMPONENT (SIZE (1..32)))

The above indicates that the address consists of from 1 to 6 text blocks, and

that each text block is from 1 to 32 characters in length.

PDU Example

As an example, consider the ASN.l specification of the format of the protocol data

units for the SNMPv2 protocol (described later in this lesson). The specification

from the standard is reproduced in Figure 19.3.

The top-level construct uses the CHOICE type to describe a variable selected

from a collection. Thus, any instance of the type PDUs will be one of eight alternative

types. Note that each of the choices is labeled with a name. All of the PDUs

defined in this fashion have the same format but different labels, with the exception

of GetBulkRequest-PDU. The format consists of a sequence of four elements. The

second element, error-status, enumerates 18 possible integer values, each with a

label. The last element, variable-binding, is defined as having syntax VarBindList,

which is defined later in the same set of definitions.

The BulkPDU definition is also a sequence of four elements, but differs from

the other PDUs.

VarBindList is defined as a Sequence-of construct consisting of some number

of elements of syntax VarBind, with a size constraint of up to 2147483647, or 2^31-1,

elements. Each element, in turn, is a sequence of two values; the first is a name, and

the second is a choice among five elements.

ASN.l Macro Definitions

Included in the ASN.l specification is the ASN.l macro notation. This notation

allows the user to extent the syntax of ASN.l to define new types and their values.

The subject of ASN.l macros is a complex one, and this section serves only to introduce

the subject.

Let us begin with several observations:

1. There are three levels that must be carefully distinguished:

* The macro notation, used for defining macros.

* A macro definition, expressed in the macro notation and used to define a

set of macro instances.

* A macro instance, generated from a macro definition by substituting values

for variables.

2. A macro definition functions as a Super Type, generating a class of macro

instances that function exactly like a basic ASN.l type.'

3. A macro definition may be viewed as a template that is used to generate a set

of related types and values.

4. The macro is used to extend the ASN.l syntax but does not extend the encoding.

Any type defined by means of a macro instance is simply an ASN.1 type,

and is encoded in the usual manner.

5. In addition to the convenience of defining a set of related types, the macro

definition enables the user to include semantic information with the type.

Macro Definition Format

A macro definition has the following general form:

<macroname> MACRO :: =

BEGIN

TYPE NOTATION :: = <new-typesyntax>

VALUE NOTATION :: = <new-value-syntax>

<supporting-productions>

END

The macroname is written in all uppercase letters. A new ASN.1 type is

defined by writing the name of the type, which begins with a capital letter, followed

by the macroname, followed by a definition of the type dictated by the form of the

macro body.

The type and value notations, as well as the supporting productions, are all

specified using Backus-Naur Form (BNF). The new-type-syntax describes the new

type. The new-value-syntax describes the values of the new type. The supporting-

productions provide any additional grammar rules for either the type or value syntax;

that is, any nonterminals within the new-type-syntax and/or new-value-syntax

are expanded in the supporting-productions.

When specific values are substituted for the variables or arguments of a macro

definition, a macro instance is formed. This macro instance has two results. First, it

generates a representation of a basic ASN.l type, called the returned type. Second,

it generates a representation of a generic ASN.l value-that is, a representation of

the set of values that the type may take. This generic value is called the returned

value.

Macros Versus Defined Types

The ASN.l macro facility provides tools for

1. Defining new types

2. Representing those types

3. Representing values of those types

4. Encoding specific values of those types

A similar capability already exists within ASN.l, which allows for the construction

of defined types, either from built-in types or, recursively, from built-in

types and defined types. The macro facility differs from the ASN.l defined type

capability in the following respects:

1. The macro facility allows the definition of a family of types. Each new type

generated by a macro definition (a macro instance) is closely related to other

types generated from the same macro. In contrast, there is no particular relationship

between one basic ASN.l defined type and other defined types.

2. A defined type is represented in a set way from the strings symbolizing the

types from which it is constructed. A macro instance is represented in whatever

way the writer of the macro chooses. Thus, the syntax of a type defined

via macro instance can be chosen to correspond closely to the notation used

within the particular application for which the macro was written. Furthermore,

the macro instance may include commentary or semantic narrative. In

this way, types defined by a macro may be more readable and more writeable.

3. In basic ASN.l, the representation of a value of a type is derived from the representation

of the type in a relatively straightforward manner. The two representations

are isomorphic; that is, they have similar or identical structure. This

isomorphism is not required with a macro definition. The returned type and

the returned generic value may have quite different syntaxes. Again, this

allows for more readable and writable values.

SNMPv2 OBJECT-TYPE Macro

An example of a macro is illustrated in Figure 19.4. This macro is defined in the

SNMPv2 standard, and is used to define management objects. A management

object is an individual variable or item of management information stored in a man

agement information base. Thus, this is an example of the use of ASN.l to specify

the syntax of locally maintained data that is used by a distributed application.

The type notation portion of this macro consists of eight parts:

The SYNTAX clause specifies the ASN.l syntax type of this object. Object-

Syntax defines a subset of ASN.l types that may be used to define managed

objects; its definition is not shown.

The UNITS clause can be used to specify what units a numerical value has.

The MAX-ACCESS clause is used to specify the access privileges for this

object. Some objects are not accessible by remote users, but are used by the

local system for data-structuring purposes. Other objects may be read-only,

read-write, or read-create.

The STATUS clause indicates the current status of this object with respect to

whether it is part of the most recent standard.

The DESCRIPTION clause is used to provide a textual description of the

object.

The REFERENCE clause is used to provide a cross-reference to another portion

of the management information base.

The INDEX clause is used if this object refers to a tabular structure. The

clause lists the object or objects that serve as indexes into the table.

The AUGMENTS clause is used to specify that this object refers to a tabular

structure that is to be appended to another tabular structure.

The DEFVAL clause is used to provide a default value for this object, to be

supplied upon creation of the object by the local system.

The value of an object is an identifier, ObjectName, that provides a unique

reference for the object.

An example of the use of this macro is the following SNMPv2 object

definition:

if TestResult OBJECT-TYPE

SYNTAX INTEGER {

none(l), -- no test yet requested

success(2),

inProgress(3),

notSupported(4),

unAbleToRun(5), -- due to state of system

aborted(6),

failed(7)

}

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This object contains the result of the most recently

requested test, or the value none(1) if no tests have

been requested since the last reset. Note that this

facility provides no provision for saving the results

of one test when starting another, as could be

required if used by multiple managers concurrently."

.... -- { if TestEntry 4 )

 NETWORK MANAGEMENT-SNMPv2

Networks and distributed processing systems are of critical and growing importance

in business, government, and other organizations. Within a given organization, the

trend is toward larger, more complex networks supporting more applications and

more users. As these networks grow in scale, two facts become painfully evident:

The network and its associated resources and distributed applications become

indispensable to the organization.

More things can go wrong, disabling the network or a portion of the network,

or degrading performance to an unacceptable level.

A large network cannot be put together and managed by human effort alone.

The complexity of such a system dictates the use of automated network management

tools. The urgency of the need for such tools is increased, and the difficulty of

supplying such tools is also increased, if the network includes equipment from multiple

vendors. In response, standards that deal with network management have

been developed, covering services, protocols, and management information base.

This section begins with an introduction to the overall concepts of standardized

network management; the remainder is devoted to a discussion of SNMPv2,

which is an extension of SNMP, the most widely used network management

standard.

Network Management Systems

A network management system is a collection of tools for network monitoring and

control that is integrated in the following senses:

A single operator interface with a powerful but user-friendly set of commands

for performing most or all network management tasks.

A minimal amount of separate equipment. That is, most of the hardware and

software required for network management are incorporated into the existing

user equipment.

A network management system consists of incremental hardware and software

additions implemented among existing network components. The software

used in accomplishing the network management tasks resides in the host computers

and communications processors (e.g., front-end processors, terminal cluster controllers).

A network management system is designed to view the entire network as

a unified architecture, with addresses and labels assigned to each point and the specific

attributes of each element and link known to the system. The active elements

of the network provide regular feedback of status information to the network control

center.

A network management system incorporates the following key elements:

Management station, or manager

Agent

Management information base

Network management protocol

The management station is typically a stand-alone device, but may be a capability

implemented on a shared system. In either case, the management station

serves as the interface for the human network manager into the network management

system. The management station will have, at minimum,

* A set of management applications for data analysis, fault recovery, and so on.

An interface by which the network manager may monitor and control the

network.

The capability of translating the network manager's requirements into the

actual monitoring and control of remote elements in the network.

A database of network management information extracted from the databases

of all the managed entities in the network.

The other active element in the network management system is the agent. Key

platforms, such as hosts, bridges, routers, and hubs, may be equipped with agent

software so that they may be managed from a management station. The agent

responds to requests for information from a management station, responds to

requests for actions from the management station, and may asynchronously provide

the management station with important but unsolicited information.

The means by which resources in the network may be managed entails representing

these resources as objects. Each object is, essentially, a data variable that

represents one aspect of the managed agent. The collection of objects is referred to

as a management information base (MIB). The MIB functions as a collection of

access points at the agent for the management station. These objects are standardized

across systems of a particular class (e.g., bridges all support the same management

objects). A management station performs the monitoring function by retrieving

the value of MIB objects. Also, a management station can cause an action to

take place at an agent, or it can change the configuration settings of an agent by

modifying the value of specific variables.

The management station and agents are linked by a network managementprorocol.

The protocol used for the management of TCPIIP networks is the simple network

management protocol (SNMP). For OSI-based networks, the common management

information protocol (CMIP) is being developed. An enhanced version of

SNMP, known as SNMPv2, is intended for both TCPIIP- and OSI-based networks.

Each of these protocols includes the following key capabilities:

Get: Enables the management station to retrieve the value of objects at the

agent.

Set: Enables the management station to set the value of objects at the agent.

Notify: Enables an agent to notify the management station of significant

events.

In a traditional centralized network management scheme, one host in the configuration

has the role of a network management station; there may be possibly one

or two other management stations in a backup role. The remainder of the devices

on the network contain agent software and a MIB, to allow monitoring and control

from the management station. As networks grow in size and traffic load, such a centralized

system is unworkable. Too much burden is placed on the management station,

and there is too much traffic, with reports from every single agent having to

wend their way across the entire network to headquarters. In such circumstances, a

decentralized, distributed approach works best (e.g., Figure 19.5). In a decentralized

network management scheme, there may be multiple top-level management

stations. which might be referred to as management servers. Each such server might

directly manage a portion of the total pool of agents. However, for many of the

agents, the management server delegates responsibility to an intermediate manager,

which plays the role of manager to monitor and control the agents under its

responsibility; it also plays an agent role to provide information and accept control

from a higher-level management server. This type of architecture spreads the processing

burden and reduces total network traffic.

Simple Network Management Protocol Version 2 (SNMPv2)

In August of 1988, the specification for SNMP was issued and rapidly became the

dominant network management standard. A number of vendors offer stand-alone

network management workstations based on SNMP, and most vendors of bridges,

routers, workstations, and PCs offer SNMP agent packages that allow their products

to be managed by an SNMP management station.

As the name suggests, SNMP is a simple tool for network management. It

defines a limited, easily implemented management information base (MIB) of

scalar variables and two-dimensional tables, and it defines a streamlined protocol to

enable a manager to get and set MIB variables and to enable an agent to issue unsolicited

notifications, called traps. This simplicity is the strength of SNMP; it is easily

implemented and consumes modest processor and network resources. Also, the

structure of the protocol and the MIB are sufficiently straightforward that it is not

difficult to achieve interoperability among management stations and agent software

from a mix of vendors.

With its widespread use, the deficiencies of SNMP became increasingly apparent:

functional deficiencies and lack of a security facility. As a result, an enhanced

version, known as SNMPv2, was issued in 1993, with a revised version issued in 1996

(RFCs). SNMPv2 has quickly gained support, and a number of vendors announced

products within months of the issuance of the standard.

The Elements of SNMPv2

Surprisingly, SNMPv2 does not provide network management at all! SNMPv2

instead provides a framework on which network management applications can be

built. Those applications, such as fault management, performance monitoring,

accounting, and so on, are outside the scope of the standard.

What SNMPv2 does provide is, to use a contemporary term, the infrastructure

for network management. Figure 19.6 is an example of a configuration that illustrates

that infrastructure.

The essence of SNMPv2 is a protocol that is used to exchange management

information. Each "player" in the network management system maintains a local

database of information relevant to network management, known as the management

information base. The SNMPv2 standard defines the structure of this information

and the allowable data types; this definition is known as the structure of

management information (SMI); we can think of this as the language for defining

management information. The standard also supplies a number of MIBs that are

generally useful for network management.2 In addition, new MIBs may be defined

by vendors and user groups.

 

At least one system in the configuration must be responsible for network management.

It is here that any network management applications are housed. There

may be more than one of these management stations, to provide redundancy or

simply to split up the duties in a large network. Most other systems act in the

role of agent. An agent collects information locally and stores it for later access

by a manager. The information includes data about the system itself and

may also include traffic information for the network or networks to which the agent

attaches.

SNMPv2 will support either a highly centralized network management strategy

or a distributed one. In the latter case, some systems operate both in the role of

manager and of agent. In its agent role, such a system will accept commands from a

superior management system. Some of those commands relate to the local MIB at

the agent. Other commands require the agent to act as a proxy for remote devices.

In this case, the proxy agent assumes the role of manager to access information at a

remote agent, and then assumes the role of an agent to pass that information on to

a superior manager.

All of these exchanges take place using the SNMPv2 protocol, which is of the

simple requestlresponse type. Typically, SNMPv2 is implemented on top of the user

datagram protocol (UDP), which is part of the TCPIIP protocol suite; it can also be

implemented on top of the IS0 transport protocol.

Structure of Management Information

The SMI defines the general framework within which an MIB can be defined and

constructed. The SMI identifies the data types that can be used in the MIB, and

how resources within the MIB are represented and named. The philosophy behind

SMI is to encourage simplicity and extensibility within the MIB. Thus, the MIB can

store only simple data types: scalars and two-dimensional arrays of scalars, called

tables. The SMI does not support the creation or retrieval of complex data structures.

This philosophy is in contrast to that used with OSI-systems management,

which provides for complex data structures and retrieval modes to support greater

functionality. SMI avoids complex data types and structures to simplify the task of

implementation and to enhance interoperability. MIBs will inevitably contain vendor-

created data types and, unless tight restrictions are placed on the definition of

such data types, interoperability will suffer.

There are actually three key elements in the SMI specification. At the lowest

level, the SMI specifies the data types that may be stored. Then, the SMI specifies

a formal technique for defining objects and tables of objects. Finally, the SMI provides

a scheme for associating a unique identifier with each actual object in a system,

so that data at an agent can be referenced by a manager.

Table 19.4 shows the data types that are allowed by the SMI. This is a fairly

restricted set of types. For example, real numbers are not supported; however, it is

rich enough to support most network management requirements.

The SNMPv2 specification includes a template, known as an ASN.l (Abstract

Syntax Notation One) macro, which provides the formal model for defining objects.

That template was illustrated in Figure 19.4. Figure 19.7 is an example of how this

template is used to define objects and tables of objects.

The first three productions serve to define a table, grokTable, stored at an

agent. As with all SNMPv2 tables, grokTable is organized as a sequence of rows, or

entries, each of which has the same sequence of objects; in this case, each row consists

of four objects. The INDEX clause specifies that the object grokhdex serves

as an index into the table; each row of the table will have a unique value of

grokhdex.

The access type of grokIPAddress is read-create, which means that the object

is read-write and that the object may be assigned a value by a manager at the time

that the row containing this object is created by a manager. Each row of the table

maintains a counter for the number of grok packets sent to the grokIPAddress specified

for that row. The grokcount object is read-only; its value cannot be altered by

a manager but is maintained by the agent within which this table resides. The

grokstatus object is used in the process of row creation and deletion; for which the

algorithm is rather complex. In essence, a Rowstatus type of object is used to keep

track of the state of a row during the process of creation and deletion.

Each object definition includes a value, which is a unique identifier for that

object; for example, the value for grokEntry is {grokTable 1); which means that the

identifier for grokEntry is the concatenation of the identifier for grokTable and 1.

The objects in a MIB are organized in a tree structure, and the identifier of an

object is found by walking the tree from its root to the position of the object in that

tree structure. For scalar objects, this scheme provides a unique identifier for any

given object instance. For objects in tables, there is one instance of each object for

each row of the table, so a further qualification is needed; what is done is to concatenate

the value of the INDEX object to the identifier of each object in the table.

Protocol Operation

The heart of the SNMPv2 framework is the protocol itself. The protocol provides a

straightforward, basic mechanism for the exchange of management information

between manager and agent.

The basic unit of exchange is the message, which consists of an outer message

wrapper and an inner protocol data unit (PDU). The outer message header deals

with security and is discussed later in this section.

Eight types of PDUs may be carried in an SNMP message. The general formats

for these are illustrated informally in Figure 19.8; the formal ASN.l definition

was provided in Figure 19.3. Several fields are common to a number of PDUs. The

request-id field is an integer assigned such that each outstanding request can be

uniquely identified. This process enables a manager to correlate incoming responses

with outstanding requests; it also enables an agent to cope with duplicate PDUs

generated by an unreliable transport service. The variable-bindings field contains a

list of object identifiers; depending on the PDU, the list may also include a value for

each object.

The GetRequest-PDU, issued by a manager, includes a list of one or more

object names for which values are requested. If the get operation is successful, then

the responding agent will send a Response-PDU. The variable-bindings list will

contain the identifier and value of all retrieved objects. For any variables that are

not in the relevant MIB view, its identifier and an error code are returned in the

variable-bindings list. Thus, SNMPv2 permits partial responses to a GetRequest,

which is a significant improvement over SNMP. In SNMP, if one or more of the

variables in a GetRequest is not supported, the agent returns an error message with

a status of noSuchName. In order to cope with such an error, the SNMP manager

must either return no values to the requesting application, or it must include an

algorithm that responds to an error by removing the missing variables, resending

the request, and then sending a partial result to the application.

The GetNextRequest-PDU also is issued by a manager and includes a list of

one or more objects. In this case, for each object named in the variable-bindings

field, a value is to be returned for the object that is next in lexicographic order,

which is equivalent to saying next in the MIB in terms of its position in the tree

structure of object identifiers. As with the GetRequest-PDU, the agent will return

values for as many variables as possible. One of the strengths of the GetNextRequest-

PDU is that it enables a manager entity to discover the structure of an MIB

view dynamically-a useful ability if the manager does not know a priori the set of

objects that are supported by an agent or that are in a particular MIB view.

One of the major enhancements provided in SNMPv2 is the GetBulkRequest

PDU. The purpose of this PDU is to minimize the number of protocol exchanges

required to retrieve a large amount of management information. The GetBulkRequest

PDU allows an SNMPv2 manager to request that the response be as large as

possible given the constraints on message size.

The GetBulkRequest operation uses the same selection principle as the Get-

NextRequest operation; that is, selection is always of the next-object instance in lexicographic

order. The difference is that, with GetBulkRequest, it is possible to specify

that multiple lexicographic successors be selected.

In essence, the GetBulkRequest operation works in the following way. The

GetBulkRequest includes a list of (N + R) variable names in the variable-bindings

list. For each of the first N names, retrieval is done in the same fashion as for Get-

NextRequest. That is, for each variable in the list, the next variable in lexicographic

order, plus its value, is returned; if there is no lexicographic successor, then the

named variable and a value of endOfMibView are returned. For each of the last R

names, multiple lexicographic successors are returned.

The GetBulkRequest PDU has two fields not found in the other PDUs: nonrepeaters

and max-repetitions. The non-repeaters field specifies the number of

variables in the variable-binding list for which a single lexicographic successor is to

be returned. The max-repetitions field specifies the number of lexicographic successors

to be returned for the remaining variables in the variable binding list. To

explain the algorithm, let us define the following:

L = number of variable names in the variable-bindings field of the Get-

BulkRequest PDU

N = the number of variables, starting with the first variable in the variablebindings

field, for which a single lexicographic successor is requested

R = the number of variables, following the first N variables, for which multiple

lexicographic successors are requested

M = the number of lexicographic successors requested for each of the last R

variables

The following relationships hold:

N = MAX [ MIN (non-repeaters, L), 0]

M = MAX [ max-repetitions, 0 ]

R = L-N

The effect of the MAX operator is that if the value of either non-repeaters or

max-repetitions is less than zero, a value of 0 is substituted.

If N is greater than 0, then the first N variables are processed as for GetNext-

Request. If R is greater than O and M is greater than 0, then for each of the last R

variables in the variable bindings list, the M lexicographic successors are retrieved.

That is, for each variable,

9 Obtain the value of the lexicographic successor of the named variable.

Obtain the value of the lexicographic successor to the object instance

retrieved in the previous step.

Obtain the value of the lexicographic successor to the object instance

retrieved in the previous step.

And so on, until M object instances have been retrieved.

If, at any point in this process, there is no lexicographic successor, then the

endOfMibView value is returned, paired with the name of the last lexicographic

successor or, if there were no successors, with the name of the variable in the

request.

Using these rules, the total number of variable-binding pairs that can be produced

is N + (M X R). The order in which the last (M X R) of these variable-binding

pairs are placed in the Response PDU can be expressed as follows:

The effect of this definition is that the successors to the last R variables are

retrieved row by row, rather than retrieving all of the successors to the first variable,

followed by all of the successors to the second variable, and so on; this matches with

the way in which conceptual tables are lexicographically ordered, so that if the last

R values in the GetBulkRequest are columnar objects of the same table, then the

Response will return conceptual rows of the table.

The GetBulkRequest operation removes one of the major limitations of

SNMP, which is its inability to efficiently retrieve large blocks of data. Moreover,

this use of this operator can actually enable reducing the size of management applications

that are supported by the management protocol, realizing further efficiencies.

There is no need for the management application to concern itself with some

of the details of packaging requests. It need not perform a trial-and-error procedure

to determine the optimal number of variable bindings to put in a request-PDU.

Also, if a request is too big, even for GetBulkRequest, the agent will send back as

much data as it can, rather than simply sending a tooBig error message. Thus, the

manager simply has to retransmit the request for the missing data; it does not have

to figure out how to repackage the original request into a series of smaller requests.

The SetRequest-PDU is issued by a manager to request that the values of

one or more objects be altered. The receiving SNMPv2 entity responds with a

Response-PDU containing the same request-id. The SetRequest operation is

atomic: either all of the variables are updated or none are. If the responding entity

is able to set values for all of the variables listed in the incoming variable-bindings

list, then the Response-PDU includes the variable-binding field, with a value supplied

for each variable. If at least one of the variable values cannot be supplied, then

no values are returned, and no values are updated. In the latter case, the errorstatus

code indicates the reason for the failure, and the error-index field indicates

the variable in the variable-bindings list that caused the failure.

The SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity

acting in an agent role when an unusual event occurs. It is used to provide the management

station with an asynchronous notification of some significant event. The

variable-bindings list is used to contain the information associated with the trap

message. Unlike the GetRequest, GetNextRequest, GetBulkRequest, SetRequest

and InformRequest PDUs, the SNMPv2-Trap-PDU does not elicit a response from

the receiving entity; it is an unconfirmed message.

The InformRequest-PDU is sent by an SNMPv2 entity acting in a manager

role. on behalf of an application, to another SNMPv2 entity acting in a manager

role, to provide management information to an application using the latter entity.

As with the SNMPv2-Trap-PDU, the variable-binding field is used to convey the

associated information. The manager receiving an InformRequest acknowledges

receipt with a Response-PDU.

For both the SNMPv2-Trap and the InformRequest, various conditions can be

defined that indicate when the notification is generated; and the information to be

sent is also specified.