blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
4.2. Object Types and Instances Connected: An Internet Encyclopedia
4.2. Object Types and Instances

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1155
Up: 4. Managed Objects
Prev: 4.1. Guidelines for Object Names
Next: 4.3. Macros for Managed Objects

4.2. Object Types and Instances

4.2. Object Types and Instances

An object type is a definition of a kind of managed object; it is declarative in nature. In contrast, an object instance is an instantiation of an object type which has been bound to a value. For example, the notion of an entry in a routing table might be defined in the MIB. Such a notion corresponds to an object type; individual entries in a particular routing table which exist at some time are object instances of that object type.

A collection of object types is defined in the MIB. Each such subject type is uniquely named by its OBJECT IDENTIFIER and also has a textual name, which is its OBJECT DESCRIPTOR. The means whereby object instances are referenced is not defined in the MIB. Reference to object instances is achieved by a protocol-specific mechanism: it is the responsibility of each management protocol adhering to the SMI to define this mechanism.

An object type may be defined in the MIB such that an instance of that object type represents an aggregation of information also represented by instances of some number of "subordinate" object types. For example, suppose the following object types are defined in the MIB:

OBJECT:

atIndex { atEntry 1 }

Syntax:

INTEGER

Definition:

The interface number for the physical address.

Access:

read-write.

Status:

mandatory.

OBJECT:

atPhysAddress { atEntry 2 }

Syntax:

OCTET STRING

Definition:

The media-dependent physical address.

Access:

read-write.

Status:

mandatory.

OBJECT:

atNetAddress { atEntry 3 }

Syntax:

NetworkAddress

Definition:

The network address corresponding to the media-dependent physical address.

Access:

read-write.

Status:

mandatory.

Then, a fourth object type might also be defined in the MIB:

OBJECT:

atEntry { atTable 1 }

Syntax:

      AtEntry ::= SEQUENCE {
            atIndex
            INTEGER,
            atPhysAddress
            OCTET STRING,
            atNetAddress
            NetworkAddress
            }

Definition:

An entry in the address translation table.

Access:

read-write.

Status:

mandatory.

Each instance of this object type comprises information represented by instances of the former three object types. An object type defined in this way is called a list.

Similarly, tables can be formed by aggregations of a list type. For example, a fifth object type might also be defined in the MIB:

OBJECT:

atTable { at 1 }

Syntax:

SEQUENCE OF AtEntry

Definition:

The address translation table.

Access:

read-write.

Status:

mandatory.

such that each instance of the atTable object comprises information represented by the set of atEntry object types that collectively constitute a given atTable object instance, that is, a given address translation table.

Consider how one might refer to a simple object within a table. Continuing with the previous example, one might name the object type

      { atPhysAddress }

and specify, using a protocol-specific mechanism, the object instance

      { atNetAddress } = { internet "10.0.0.52" }

This pairing of object type and object instance would refer to all instances of atPhysAddress which are part of any entry in some address translation table for which the associated atNetAddress value is { internet "10.0.0.52" }.

To continue with this example, consider how one might refer to an aggregate object (list) within a table. Naming the object type

      { atEntry }

and specifying, using a protocol-specific mechanism, the object instance

      { atNetAddress } = { internet "10.0.0.52" }

refers to all instances of entries in the table for which the associated atNetAddress value is { internet "10.0.0.52" }.

Each management protocol must provide a mechanism for accessing simple (non-aggregate) object types. Each management protocol specifies whether or not it supports access to aggregate object types. Further, the protocol must specify which instances are "returned" when an object type/instance pairing refers to more than one instance of a type.

To afford support for a variety of management protocols, all information by which instances of a given object type may be usefully distinguished, one from another, is represented by instances of object types defined in the MIB.


Next: 4.3. Macros for Managed Objects

Connected: An Internet Encyclopedia
4.2. Object Types and Instances

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609