The importance of unique naming

Anywhere in the world, international calls beginning with +1 are going to the US and those with +33 are going to France.

US calls with the 408 area code land in the San Jose metro area and those with 650 are up the road in Mountain View.

Phones numbers work, because there is a global agreement on number policy.

The same holds true for IP addresses and DNS names.  There is a global agreement on what these identifiers mean, which makes phones and internet hosts easily accessable.

Add the URL construct and we get a way to extend DNS addresses to uniquely identify a particular resource on the network along with the protocol to access it by, like ftp://ftpserver.foobar.com/subdir1/readme.txt.

The importance of hierarchical naming

All the schemes above use a hierarchical naming convention.  A key benefit of such a scheme is the delegation of naming authority.  All countries must agree to use +1 as US and +33 as France, but the addition of the 650 area code did not require international consensus.

IP addresses and DNS names follow the same construct.  An authority assigns a block of addresses or a domain name prefix to another entity and that entity can then delegate within that range or block as it sees fit.

Unique names to talk about the same thing

The examples above illustrate the ability to give every item a unique name.  But what about an item which may be the same on every system?  It would be convenient to have a name which always identified a system's CPU type, or its administrator, or many other things.

Object Identifiers provide a way to delegate the naming of any attribute of interest to any interested party.

Object Identifiers

An object identifier is simply a sequence of integers.  The sequence represents a hiearchy of names and naming authorities, the top level naming authorities are ISO, CCITT and joint ISO-CCITT.

For independent entities, such as IPDR.org, number assignment is typically petitoned from the Internet Assigned Number Authority (IANA) (www.iana.org).

Your typical IANA object identifier begins with the sequence 1.3.6.1.4.1, followed by an "Enterprise Identifier"  Each element in the hierarchy represents an assigning authority.  In the case of 1.3.6.1.4.1, the authority hierarchy is, iso.org.dod.internet.private.enterprise.  This means that the International Standards Organization created a sub hierarchy for interested organizations, of which the US Department of Defense (DOD) received the number 6.  It assigned identifier 1 to the internet developers which created the private.enterprise subhierarchy which is controlled by IANA.  Other assigning entities are available, but for internet related activities this prefix is preferred.

Because it is a hierarchy, you can further assign numbers below you to different interested organizations.  For example a company might assign the next level of numbers to its different product families.  As new products are introduced, simply assign another top level number.

Are Object Identifiers being adopted?

IANA creates enterprise ids sequentially.  Today there are about 10,000 assigned identifiers.  Examples include IBM with 2, Cisco with 9, HP with 11, Sun with 42, Microsoft with 311, Netscape with 1450.

All SNMP MIBs and LDAP schemas utilize the object id mechanism to uniquely identify managed attributes and class names.  Becuase many of these elements are defined as part of Internet standards, their basic set of identifiers come for the mgmt(2) and directory(1) hierarchies versus the private.enterprise (4.1) branch.

SNMP has been very successful in soliciting definitions of attributes, view the approximately 200 different MIB definitions indexed at http://www.simpleweb.org/ietf/rfcs/rfcbymodule.html.

Once assigned an object identifier, an entity then has the authority to adminster the remainder of the space as it sees fit.  For instance the IPDR.org could acquire a number (probably ~9300) and then create a subhierarchy for the currently defined services:

  ndmU  = 1  // allow for other areas of IPDR specification
     vod  =  1
         movieId = 1
         subscriber = 2
         ...
    voip  =  2
     wap =  3
       ...

In this example the unique object identifier for movieId would be:

1.3.6.1.4.1.9300.1.1.1.

A human readable and binary format

Object ids are expressed in human readable form by identifying each element with a text name.  As new object elements are defined (for example in a MIB) they are given both a numeric and text identifier.  So the full name for movieId from the example above would be:
iso.org.dod.internet.private.enterprise.ipdr.ndmU.vod.movieId
A partial map of some of the well defined branches in the objectid space are provided by IANA.

The ASN.1 encoding of object identifiers is quite compact, requiring about one byte per position.  This is semantically equivalent, but several times smaller than the text based name.

The ASN.1 BER encoding of this would be:

06 0a 2b 06 01 04 01 a4 54 01 01 01
which is twelve bytes in length.

An alternate human readable format

An equivalent naming scheme for objects is used in Java, where specific classes are fully qualified by names such as java.io.File, or com.foobar.productA.GreatObject.

Because of the delegation, each naming authority can safely assume that its name will never conflict with any other.

This namespace could also be easily mapped to object Ids by convention if the initial prefix is mapped to an object path (for instance map com.foo to the object path iso.org.dod.internet.private.enterprise.foo) and then assign identifiers to each sub element.

Diameter's Mechanism for unique names

Diameter follows a delegation model as well.  It relies on the same Enterprise Id numbers assigned by IANA as those used for Object Ids.  However the identification of a Diameter attribute is done by a simple pair of identifiers, 32-bits for the Enterprise Id and then another 32-bits for the specific attribute identifier.

By not using the object id mechanism, Diameter bounds the size of any identifier to exactly 8 bytes.  This also makes the machine readability slightly faster, because the decode step associated with object ids is eliminated.  However this has the downside that delegation and extension is somewhat comprimised.

For instance the likely policy for delegating identifiers in a Diameter AVP context would be to assign blocks of identifiers to a given service (e.g. VoD gets 1-499, VoIP gets 500-999, etc.)  Although this is a workable scheme it lacks the clear hierarchical delineation expressed by object ids.  For instance if IPDR embarked on defining provisioning attributes, then in a hierarchical space, we'd simply define a new identifier under ipdr (in addition to the existing ndmU, e.g. provisioning) and take identifiers below this point.  In the Diameter AVP model, we might chose to allocate provisioning items from blocks of numbers beginning with 100,000, but this seems more arbitrary and less elegant.