Structure of Management Information (SMI) para SNMPv1

1. Abstract Syntax Notation One

ASN.1 es una notación que ofrece un rico conjunto de tipos de datos y contructores que permiten definir estructuras de datos complejas a partir de tipos simples o primitivos. Al igual que cualquier lenguaje de programación, la notación es especificada utilizando gramática BNF.

1.1 Elementos de ASN.1

1.1.1. Tipos y valores

Un tipo (type) es una clase de dato. Este define la estructura de datos que la máquina necesita para entender y procesar información. Tres de estos tipos son: primitivos (Primitive), constructores (Constructor) y definidos (Defined). ASN.1 define varios tipos primitivos (también conocidos como Simple types): INTEGER, BOOLEAN, OCTECT STRING, OBJECT IDENTIFIER, ENUMERATED y NULL. Por convención, los tipos comienzan con una letra mayúscula (ASN.1 define los cuatro tipos listados aquí como secuencias de caracteres reservadas y por esto deben escribirse en mayúsculas). Los tipos constructores (Conocidos también como Aggregate types) generan listas y tablas. Ejemplos de estos constructores son SET, SEQUENCE, CHOICE, SET OF y SEQUENCE OF. Los tipos definidos son nombres alternados de tipos ASN.1 simples o complejos y generalmente son más descriptivos. Ejemplos de tipos definidos son Connected (de la recomendación ITU M.3100) que representa el tipo de conexión: "punto a punto" ó "punto a multipunto" e  IpAddress (del RFC 1155) que representa una dirección IP de 32 bits.

Un valor (value) cuantifica el tipo. Una vez se sabe cuál es el tipo (INTEGER ó OCTECT STRING), el valor proporciona una instancia específica para ese tipo. Por convención, los valores comienzan con letras minúsculas.

Algunas aplicaciones permiten sólo un subconjunto de los posibles valores de un tipo. Una especificación de subtipo (subtype) indica dicha restricción. La especificación de subtipo aparece, colocada entre paréntesis,  después del tipo y muestra el conjunto de valores permitidos. Esto se denomina subtype values. Por ejemplo, si una plicación utiliza el tipo INTEGER y los valores permitidos deben ajustarse a un campo de 8 bits, el posible rango de valores está entre 0 y 255. En ASN.1 se puede expresar como:

    INTEGER (0..255)

Los dos puntos seguidos (..) son el separador de rango e indican que sólo son validos enteros cuyos valores estén entre 0 y 255.

1.1.2. Macros

El anexo J del estándar ISO 8824-1 define la notación de macro que permite extender el lenguaje ASN.1. Por convención, una referencia a macro (es decir, el nombre de la macro) debe tener todas las letras en mayúsculas. Por ejemplo, Las definiciones de la MIB en SNMP utilizan bastante las macros de ASN.1. El primer objeto en la MIB-II, descrito en el RFC1213, es la descripción del sistema (sysDescr) y utiliza la macro OBJECT-TYPE (definida en el RFC1212)
 
 

RFC 1213 sysDescr OBJECT-TYPE     SYNTAX  DisplayString (SIZE (0..255))     ACCESS  read-only      STATUS  mandatory      DESCRIPTION             "A textual description of the entity.  This value              should include the full name and version              identification of the system's hardware type,              software operating-system, and networking              software.  It is mandatory that this only contain              printable ASCII characters."     ::= { system 1 }

 

RFC1212 OBJECT-TYPE MACRO ::= BEGIN               TYPE NOTATION ::=                                "SYNTAX" type(ObjectSyntax)                                 "ACCESS" Access                                 "STATUS" Status                                 DescrPart                                 ReferPart                                 IndexPart                                 DefValPart               VALUE NOTATION ::= value (VALUE ObjectName)               Access ::= "read-only"                               | "read-write"                               | "write-only"                               | "not-accessible"               Status ::= "mandatory"                               | "optional"                               | "obsolete"                               | "deprecated"               DescrPart ::=                          "DESCRIPTION" value (description DisplayString)                               | empty               ReferPart ::=                          "REFERENCE" value (reference DisplayString)                               | empty               IndexPart ::=                          "INDEX" "{" IndexTypes "}"                               | empty               IndexTypes ::=                          IndexType | IndexTypes "," IndexType               IndexType ::=                                   -- if indexobject, use the SYNTAX                                   -- value of the correspondent                                   -- OBJECT-TYPE invocation                             value (indexobject ObjectName)                                   -- otherwise use named SMI type                                   -- must conform to IndexSyntax below                               | type (indextype)               DefValPart ::=                          "DEFVAL" "{" value (defvalue ObjectSyntax) "}"                               | empty END

3. Módulos

ASN.1 agrupa descripciones en módulos. El módulo comienza con un nombre de módulo, este nombre debe comenzar con una letra mayúscula. Las sentencias BEGIN y END encierran el cuerpo del módulo. El módulo puede contener IMPORTS, que son nombres de tipos, valores y macros y ,os modulos en los cuales ellos son declarados. En el siguiente ejemplo, AvailabilityStatus, ObjectInstance y AdministrativeState son  importados del módulo Attribute-ASN1Module.

A continuación se muestra parte del módulo de definición de tipos (ASN1DefinedTypesModule) que se referencian en las plantillas (templates) de GDMO (tomado de la recomendación ITU M.3100). Los comentarios en ASN.1 comienzan con un doble guión (--). Las llaves ({}) indican el comienzo y el final de una lista.
 
 

ASN1DefinedTypesModule {ccitt recommendation m gnm(3100) informationModel(0) asn1Modules(2) asn1DefinedTypesModule(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN --EXPORTS everything IMPORTS AvailabilityStatus, ObjectInstance, AdministrativeState FROM Attribute-ASN1Module {joint-iso-ccitt ms(9) smi(3) part2(2) asn1Module(2) 1} AlarmInfo FROM Notifications-ASN1Module {joint-iso-ccitt ms(9) smi(3) part2(2) asn1Module(2) 1}; m3100InformationModel OBJECT IDENTIFIER ::= {ccitt recommendation m gnm(3100) informationModel(0)} m3100ObjectClass OBJECT IDENTIFIER ::= {m3100InformationModel managedObjectClass(3)} CircuitPackType ::= PrintableString CircuitPackAvailabilityStatus ::= AvailabilityStatus (WITH COMPONENT (notInstalled)) Connected ::= CHOICE {    pointToPoint            [0] PointToPoint,    pointToMultipoint       [1] PointToMultipoint    } ConnectInformation ::= SEQUENCE OF SEQUENCE {    CHOICE {       unidirectional       [0] ConnectionType,       bidirectional        [1] ConnectionTypeBi,       addleg               [2] AddLeg    },    administrativeState AdministrativeState OPTIONAL,    namedCrossConnection [3] NamedCrossConnection OPTIONAL } ConnectResult ::= SEQUENCE OF CHOICE {    failed Failed,    connected Connected    } --the n-th element in the "SEQUENCE OF" is related  --to the n-th element in the "SEQUENCE OF" of the --"ConnectInformation" type. ConnectionType ::= CHOICE {    explicitPToP            [0] ExplicitPtoP,    ptoTpPool               [1] PtoTPPool,    explicitPtoMP           [2] ExplicitPtoMP,    ptoMPools               [3] PtoMPools    } ConnectionTypeBi ::= CHOICE {    ExplicitPToP            [0] ExplicitPtoP,    ptoTpPool               [1] PtoTPPool    } CreateError ::= INTEGER END --end of module

4. Convenciones en ASN.1

ASN.1 hace distinciones entre mayúsculas y minúsculas de la siguiente forma:
 

Elemento	Convención
Types	Inicial en mayúscula
Values	Inicial en minúscula
Macros	Todas las letras en mayúscula
Modules	Inicial en mayúscula
ASN.1 keywors	Todas las letras en mayúscula

Caracteres especiales en ASN.1:
 

Elemento	Nombre
-	Número con signo
--	Comentario
::=	Asignación ("definido como...")
|	Alternativa (opciones de una lista)
{}	Inicio y final de lista
[]	Inicio y final de una etiqueta (tag)
()	Inicio y final de una expresión de subtipo
..	Indica un rango

2. Detalles de ASN.1 – Objetos y tipos

En inglés esta definición ASN.1 significa: Esto define un objeto llamado tcpInSegs que contiene información del Counter. El tipo Counter es un número no negativo que se incrementa monótonamente. Este objeto es de solo lectura (read-only) y es obligatorio para todos los dispositivos administrados que soportan a su padre, mib-2.tcp. Cuando un protocolo de administración accesa este objeto, utiliza el nombre { tcp 10 }, el cual identifica el décimo objeto definido dentro del grupo tcp. .

2. Tipos primitivos (simples)

Para mantener la simplicidad de SNMP, la SMI de Internet usa un subconjunto de los tipos de datos de ASN.1. Éstos son divididos en dos categorías, los tipos primitivos y los tipos constructores. Los tipos de datos primitivos (también llamados tipos simples) incluyen (INTEGER, OCTET, STRING, OBJECT IDENTIFIER y NULL. Los ejemplos siguientes vienen de la MIB-II (RFC 1213).

INTEGER es un tipo primitivo con distinguidos (o únicos) valores que son números enteros positivos o negativos incluyendo el cero. El tipo INTEGER tiene dos casos especiales. El primero es el tipo entero enumerado, en el cual los objetos tienen un número específico distinto de cero, tal como 1, 2, 3. El segundo, el tipo integer-bitstring, es usado por cadenas de bits de longitud corta, tal como (0..127) y muestra el valor en formato hexadecimal. Un ejemplo de INTEGER podría ser:
 

IpDefaultTTL OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUSmandatory DESCRIPTION “The default value inserted into the Time-To-Live  field of yhe Ip header of datagrams originating at this entity, whenever a TTL value is not supplied by the transport layer protocol.” ::= { ip 2 }

El OCTET STRING es un tipo primitivo cuyos valores son una secuencia ordenada de cero, uno, o más octetos. SNMP usa tres casos especiales del tipo OCTET STRING: el DisplayString, el octetBitstring, y el PhysAddress. En el DisplayString, todos los octetos son caracteres ASCII imprimibles. El octetBitstring es utilizado para cadenas de bits que exceden 32 bits en longitud. (TCP/IP frecuentemente incluye 32 campos de bits. Esta cantidad es un valor típico para el ancho de palabra interna de varios procesadores -hosts y routers-en Internet.). La MIB-II define el PhysAddress y lo usa para representar direcciones del medio (o capa física). Un ejemplo del uso del DisplayString podría ser:
 

SysContact OBJECT-TYPE SYNTAX DisplayString ( SIZE (0..255)) ACCES read-write STATUS mandatory DESCRIPTION “The textual identification of the contact person for this managed node, and information on how to contact this person.” ::= { system 4 }

Note que el subtipo indica que el tamaño permisible del DisplayString está entre 0 y 255 octetos.

El OBJECT IDENTIFIER es un tipo cuyos valores son el conjunto de todos los identificadores de objetos asignados de acuerdo a las reglas de ISO 8824-1. El tipo ObjectName, es un caso especial utilizado por SNMP, es restringido a los identificadores de objetos de los objetos y subárboles en la MIB, por ejemplo:
 

IpRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION “A reference to MIB definitions specific to the particular routing protocol responsible for this route, as determined by the value specified in the route’s ipRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identifier, and any conforming implementation of ASN.1 and BER must be able to generate and recognize this value.” ::= { ipRouteEntry 13 }

NULL es un tipo con un único valor, también llamado null. El null sirve para mantener espacio, pero actualmente no es utilizado por los objetos de SNMP.

3. Tipos Constructor o Estructurados

Los tipos constructor (Constructor) o estructurados (Structured) (para mejor comprensión y asociación con otros lenguajes, se usará el término estructurado en el resto de este documento) SEQUENCE y SEQUENCE OF, definen tablas y filas (entradas) dentro de dichas tablas. Por convención, los nombres para los objetos tabla terminan con el sufijo Table, y los nombres para las filas terminan con el sufijo Entry. A continuación se definen los tipos estructurados. El ejemplo viene de la MIB-II.

SEQUENCE es un tipo estructurado definido mediante la referencia a una lista de tipos fijos y ordenados. Algunos de los tipos pueden ser opcionales y todos pueden ser diferentes tipos definidos en ASN.1. Cada valor del nuevo tipo consiste en una lista ordenada de valores, uno por cada tipo de componente. El SEQUENCE como un conjunto, define una fila dentro de un tabla. Cada entrada en la SEQUENCE especifica una columna en la fila.

SEQUENCE OF es un tipo estructurado que está definido mediante la referencia a un solo tipo existente; cada valor en el nuevo tipo es una lista ordenada de cero, uno, o más valores de dicho tipo existente. Como SEQUENCE, SEQUENCE OF define las filas en una tabla; a diferencia de SEQUENCE, SEQUENCE OF solo usa elementos del mismo tipo en ASN.1.

La tabla de conexión TCP que sigue ilustra el uso de SEQUENCE y SEQUENCE OF:
 

TcpConnTable OBJECT-TYPE SINTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “A table containing TCP connection-specific information.” ::= { tcp 13 } tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “Information about a particular current TCP connection. An object of this type is transient; it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state.” INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 } TcpConnEntry ::= SEQUENCE { TcpConnState INTEGER, TcpConnLocalAddress IpAddress, TcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, TcpConnRemPort INTEGER (0..65535) }

El nombre de tabla tcpConnTable finaliza con el sufijo Table. El nombre de fila tcpConnEntry finaliza con el sufijo Entry. El nombre de secuencia TcpConnEntry es semejante al de la fila, excepto por la primera letra. La cláusula INDEX define la construcción y orden de las columnas que conforman las filas. Dave Perkins en su artículo “How to Read and Use an SNMP MIB” [2-14] explora los objetos tablas y filas con gran detalle.

4. Tipos definidos

El cuerpo de administración de la red Internet utiliza los tipos definidos (o application-wide) (descrito en el RFC 1155). Los tipos definidos incluyen NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, y Opaque. Los ejemplos que siguen son tomados del RFC 1213. Para más información, revise la sección titulada “La definición concisa de SMI” y localice el tipo definido bajo la sección de definición ApplicationSyntax.

El tipo NetworkAddress fue ideado para representar una dirección de alguna de las muchas familias de protocolos. Un CHOICE es un tipo primitivo que provee alternativas entre otros tipos; esto es encontrado en muchas secciones de la definición SMI dada en la sección titulada “La definición concisa de SMI”. Actualmente, sin embargo, solo una familia de protocolos, la familia Internet (llamada internet ipAddress en la definición de SMI), ha sido definida para este CHOICE. Aquí hay un ejemplo:
 
 

AtNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCES read-write STATUS deprecated DESCRIPTION “The NetworkAddress (e.g., the IP address) corresponding to the media-dependent ‘physical’ address.” ::= { atEntry 3 }

Debido a que esto soporta solo direcciones IP (dentro del “choice” por defecto), el uso de este tipo de datos es desalentador.

IpAddress es un tipo definido que representa direcciones de internet de 32 bits. Esto es representado como un OCTET STRING de longitud 4 (octetos) en bytes de red ordenados (los bytes ordenados son transmitidos sobre la red):
 
 

TcpConnRemAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION “The remote IP address for this TCP connection.” ::= { tcpConnEntry 4 }

El Counter es un tipo definido que representa un entero no negativo que se incrementa monótonamente hasta alcanzar un valor máximo, luego se reinicia y vuelve a comenzar desde cero. El valor máximo del contador es 2³²-1, o el decimal 4’294.967.295. En otras palabras, el Counter es un número sin signo de 32 bits. Un INTEGER es un valor de 32 bits con signo. Por convención, el nombre del objeto Counter se escribe en plural; esto finaliza con una s minúscula. Aquí está un ejemplo:
 
 

IcmpInDestUnreachs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION “The number of ICMP Destination Unreachable messages received.” ::= { icmp 3 }

Un Gauge es un tipo definido que representa un entero no negativo. Este puede incrementarse o decrementarse, pero no sobrepasa un valor máximo. El máximo valor del contador es 2³²-1 (4’294.967.295 en decimal). Aquí hay un ejemplo:
 

IfSpeed OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION “An estimate of the interface’s current bandwidth in bits per second. For interfaces that do not varyin bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.” ::= { ifEntry 5 }

TmeTicks es un tipo definido que representa un entero no negativo que calcula el tiempo en centésimas de segundos desde algún periodo o instante de tiempo. Cuando la MIB define tipos de objeto que usan este tipo perteneciente a ASN.1, la descripción del tipo del objeto identifica el periodo de referencia. Aquí está un ejemplo:
 

SysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION “The time (in hundredths of a second) since the network management portion of the system was last re-initialized.” ::= { system 3 }

Opaque es un tipo definido que permite el paso de sintaxis ASN.1 arbitrarias. Las reglas básicas de ASN.1 codifican un valor en una cadena de octetos. Esta cadena, a su vez, es codificada como un OCTET STRING, en efecto, “doble envolvimiento” del valor ASN.1 original. Actualmente SNMP no utiliza Opaque, aunque puede ser encontrado en algunas MIBs privadas.

5. Tipos etiquetados (Tagged types)

Los tags (etiquetas) distinguen entre objetos definidos inequívocamente. Mientras un lector humano puede ser capaz de distinguir objetos definidos a través de sus nombres en la notación ASN.1, una máquina no puede hacer esto sin información adicional. Por lo tanto, los tipos tagged usan previamente un tipo definido como una base, y luego añade información única. ASN.1 define cuatro clases de tags: universal, application, context specific y private. ASN.1 (ISO 8824-1) define tags universal. Otros estándares, tal como los de Internet, asignan tags de la clase application. La definición de SNMP (RFC 1157) interpreta los tags de la clase context-especific de acuerdo a su contexto. Aplicaciones de empresas específicas usan tags de la clase private.

Un número entre corchetes ([ ]) identifica tipos tagged (etiquetados). Por ejemplo, la definición concisa de SMI muestra que:
 
 

TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

Por lo tanto, el tipo TimeTicks es un tipo tagged, llamado APPLICATION 3. esto es de la clase application y el numero del tag es 3. Este puede asumir un valor en el rango de valores entre 0 y 4294967295. La palabra clave IMPLICIT indica que el tag asociado con el tipo INTEGER no es transmitido, pero el tag asociado con TimeTicks si. Esto reduce el tamaño del dato que debe ser codificado y transmitido.
 

Reglas de codificación

2. Codificación Tipo-Longitud-Valor (TLV)

Para definir la representación de los datos externos, el BER especifica primero la posición de cada bit en los octetos a ser transmitidos. Cada octeto transmite primero el bit más significativo (Most Significant Bit - MSB) y lo define como bit 8 en el lado izquierdo del octeto. Por su parte, el bit menos significativo (Least Significant Bit - LSB) se define en el octeto como el bit 1 en la parte derecha del mismo (ver figura 2).

La estructura de codificación del dato en si tiene tres componentes: Tipo, Longitud y Valor (TLV). Note que en la literatura es posible que encuentre otros nombres para TLV, incluyendo Etiqueta-Longitud-Valor (Tag-Length-Value) y Identificador-Longitud-Valor (Identifier-Length-Contents) (ISO 8825-1). La estructura de una codificación TLV usada con SNMP es mostrada en la figura 3.

Mediante la definición del orden y estructura de los bits, el BER garantiza que ambos extremos del canal de comunicación interpreten el flujo de bits de una forma consistente. Las siguientes secciones examinan la estructura de cada campo TLV individualmente.

2.1. Campo Tipo (Type field)

El campo Tipo va de primero y alerta el destino a la estructura que sigue. De esta manera, el campo Tipo contiene una identificación para la estructura de codificación; esto codifica el tag de ASN.1 (tanto la clase como el número) para el tipo de dato contenido en el campo Valor. Un subcampo dentro del campo Tipo contiene un bit designado como P/C que indica si la codificación es primitiva (Primitive) (P/C = 0) o estructurada (Constructed) (P/C = 1), como muestra la figura 4.
 
 

Hay dos tipos de campos Tipo; su uso depende de la magnitud del número del tag. Cuando el número del tag está entre 0 y 30, el campo Tag contiene un solo octeto (ver figura 4). Cuando el número del tag es 31 o superior, el campo Tipo contiene múltiples octetos. En cualquier caso, el primer octeto contiene tres subcampos: Clase (Class), bit P/C y numero de tag (tag number). El subcampo Clase codifica la clase de tag en uso:
 

Clase	Bit 8	Bit 7
Universal	0	0
Application	0	1
Context-specific	1	0
Private	1	1

Las aplicaciones SNMP utilizan las primeras tres clases: universal, application, y context-specific. La clase universal codifica el tipo INTEGER, el tipo OCTET STRING y así sucesivamente. La clase application codifica los tipos definidos (IpAddress, Counter, y así sucesivamente). La clase context-specific codifica las cinco unidades de datos de protocolo de SNMP (PDUs), GetRequest, GetResponse, y así sucesivamente.

El subcampo P/C (bit 6) indica la forma del elemento de dato. Codificación primitiva (Primitive encoding) (P/C = 0) quiere decir que el contenido de los octetos representan el valor directamente. Una codificación estructurada (Constructor encoding) (P/C = 1) significa que el contenido de los octetos codifican uno o más valores de datos adicionales, tal como un SEQUENCE.

SNMP usa números de tag entre 0 y 30. EL número del tag aparece en el tercer subcampo y es representado en binario. El bit 5 es el MSB del tag; el bit 1 es su LSB.

ISO 8824-1 contiene números de tag para la clase universal (por ejemplo, UNIVERSAL 2 representa el tipo INTEGER). La especificación SMI, RFC 1155, contiene números de tag para la clase application (por ejemplo, IpAddress es un tipo primitivo con tag [0]). La especificación de SNMP, RFC 1157, contiene números de tag para la clase context-specific (por ejemplo, el PDU GetRequest es un tipo construido con tag [0]).

La lista siguiente muestra un resumen de las tres clases de campos Tipo usados con SNMP y la codificación para éstos: class, P/C, y tag number. Estas codificaciones aparecen en notación binaria y hexadecimal, donde la H representa la notación hexadecimal:
 
 

Universal Class	Valor del campo Tipo (Type)
INTEGER	00000010 = 02H
OCTET STRING	00000100 = 04H
NULL	00000101 = 05H
OBJECT IDENTIFIER	00000110 = 06H
SEQUENCE	00110000 = 30H
SEQUENCE-OF	00110000 = 30H

Application Class	Valor del campo Tipo
IpAddress	01000000 = 40H
Counter	01000001 = 41H
Gauge	01000010 = 42H
TimeTicks	01000011 = 43H
Opaque	01000100 = 44H

 

Context-Specific Class	Valor del campo Tipo
GetRequest	10100000 = A0H
GetNextRequest	10100001 = A1H
GetResponse	10100010 = A2H
SetRequest	10100011 = A3H
Trap	10100100 = A4H

Aunque el BER también provee números de tag de 31 o superiores, SNMP no los utiliza (ver la porción más baja de la figura 4). Para los tags mayores de 31, el campo Tipo usa un formato diferente. El numero del tag en el primer octeto es puesto al binario 11111, y los octetos subsiguientes son adicionados al carry del número del tag. El bit 8 =1 de un octeto indica que seguirán más octetos; el bit 8 = 0 de un octeto especifica el último octeto. Los bits 7 hasta el 1 de cada octeto subsiguiente lleva el entero binario sin signo del número del tag. EL bit 7 del octeto subsiguiente indica el MSB del número del tag.

2.2. Campo Longitud (Length field)

EL campo Longitud sigue al campo Tipo y determina el número de octetos que contendrá el campo Valor (Value field). El campo Longitud puede tomar tanto la forma definida corta como la larga, tal como se muestra en la figura 5. (Otra forma, llamada “indefinida”, no es utilizada por SNMP). Definido indica que la longitud de la codificación es conocida antes de la transmisión; indefinido indica lo contrario.

La forma definida corta indica una longitud de entre 0 y 127 octetos en el contenido del campo; la forma definida larga indica 128 o más octetos en el contenido del campo, aunque esto puede indicar longitudes más cortas.

La forma larga usa múltiples octetos para representar la longitud total. En esta forma, el primer octeto del campo Longitud tiene el bit 8 = 1, seguido por un número binario indicando el número de octetos a seguir. Este número debe estar entre 1 y 126; 127 está reservado para extensiones futuras. El bit 8 del segundo octeto es considerado el MSB del campo Longitud, y el octeto siguiente determina el resto de la longitud. De esta manera, la forma definida larga puede representar una longitud hasta de 2¹⁰⁰⁸-1 octetos. (El 1008 viene del producto entre 126 y 8: 126 octetos subsecuentes a razón de 8 bits por octeto.

2.3. Campo Valor (Value field)

El campo Valor contiene cero o más octetos, los cuales transportan los valores de los datos. Los ejemplos incluyen un entero, un carácter ASCII, ó un OBJECT IDENTIFIER, tal como { 1.3.6.1.2. }.

3. Ejemplos de codificación

Anteriormente se mencionó que el SMI de Internet define un subconjunto de los tipos ASN.1. Este subconjunto incluye los siguientes tipos primitivos universales (universal Primitive types): INTEGER, OCTET STRING, OBJECT IDENTIFIER, y NULL. Los tipos estructurados universales (universal Constructor types) son SECUENCE y SECUENCE OF. Los tipos primitivos de aplicación (applications Primitive types) son IpAddress, Counter, Gauge y TimeTicks. Las aplicaciones relacionadas con SNMP solo utilizan estos diez tipos. Esta información será utilizada en los casos de estudio presentados a continuación. Para una ilustración acerca de los otros tipos se recomienda consultar ISO 8825-1.

3.1. Codificación del tipo INTEGER

El tipo INTEGER es un tipo simple que toma valores de cero, enteros positivos o negativos. Es un tipo primitivo codificado con un campo Valor que contiene uno o más octetos. Los octetos contenidos son números binarios complementos de 2, iguales al valor entero, y pueden usar tantos octetos como sea necesario. Por ejemplo, Boomer, un Labrador, pesa 75 libras. El valor de su peso sería codificado como: campo Tipo = 02H, campo Longitud = 01H y campo Valor = 4BH (ver figura 6). Note que el valor aparece entre comillas (Valor = “75”) para indicar que representa una cantidad, la cual puede ser numérica, un carácter ASCII, una dirección IP y así sucesivamente.

3.2. Codificación del tipo OCTET STRING

El OCTET STRING es un tipo simple cuyos valores distintivos son una secuencia ordenada de cero, uno, o más octetos, cada uno de los cuales debe ser múltiplo de 8 bits. La codificación para valores OCTET STRING es primitiva, con el campo Tipo = 04H. El campo longitud y Valor dependen de la información codificada.

Nuevamente se usará a Boomer en un ejemplo para mostrar la codificación del tipo OCTET STRING. La figura 7 muestra como se ha codificado el valor para las iniciales de Boomer (BBM, por Boomerang Buddy Miller). El campo Tipo contiene 04H, indicando un tipo primitivo OCTET STRING (número de tag igual a 4). El campo Longitud indica 3 octetos en el campo Valor. La codificación del campo Valor proviene del esquema ASCII.
 
 

3.3. Codificación del tipo OBJECT IDENTIFIER

El OBJECT IDENTIFIER nombra (o identifica) ítems. (En SNMP, estos identifican objetos administrados). Su campo Valor contiene una lista ordenada de subidentificadores. Para salvar los esfuerzos de codificación y transmisión, se puede tomar ventaja del hecho de que el primer subidentificador es un número pequeño, tal como 0, 1 o 2 y lo combina matemáticamente con el segundo identificador, el cual puede ser más largo. El número total de subidentificadores es, por lo tanto, menor que el número de componentes de identificador de objetos en el valor OID a ser codificado. Este número reducido (uno menos) resulta de una expresión matemática que usa los primeros dos componentes OID para producir otra expresión:
 
 

Given X is the value of the first OID, and Y is the second:  First subidentifier = (X * 40) + Y.

Los valores de estos subidentificadores son codificados y localizados en el campo Valor. El bit 8 de cada octeto indica si o no que el octeto es el último en la serie de octetos requeridos para describir completamente el valor. Si el bit 8 = 1, al menos uno de los octetos sigue; el bit 8 = 0 indica el último (o único) octeto. Los bits 7 hasta el 1 de cada octeto codifica subidentificadores. Utilizando un ejemplo del árbol de objetos de la MIB-II, en el grupo System, asuma que un OBJECT IDENTIFIER tiene un valor de:

{ iso org(3) dod(6) internet(1) mgmt(2) mib-2 (1) 1 }

Del árbol de objetos (también discutido más abajo), esto está representado por:

{ 1.3.6.1.2.1.1. }

Note que, por convención, los subidentificadores son separados por puntos para mayor claridad.

Usando los valores de X = 1 y Y = 3, y la expresión anterior para el primer valor del subidentificador,

(1 * 40) + 3 = 43

Esto resulta en el primer valor del subidentificador de 43, el segundo valor del subidentificador de 6, el tercero de 1, y así sucesivamente. El primer valor (43) necesita 6 bits, o un octeto, para la codificación (00101011). El segundo valor (6) necesita 3 bits para la codificación (110), y requiere solo un octeto. Los valores subsiguientes también requieren un octeto. Como se puede ver en la figura 8, la codificación viene de esta forma: campo Tipo = 06H (OBJECT IDENTIFIER, tag = 6); campo Longitud = 06H; y campo Valor = 2B 06 01 02 01 01 H.
 
 

3.4. Codificación del tipo NULL

El tipo NULL es un preservador (placeorder) que comunica la ausencia de información. Por ejemplo, cuando un administrador requiere el valor de una variable, éste utiliza el tipo NULL como un preservador en la posición que el agente ocupará en la respuesta.

La codificación para el tipo NULL es primitiva. El campo Tipo = 05H, el campo Longitud = 00H. El campo valor es vacío (no hay octetos de valor), como muestra la figura 9.

3.5. Codificación del tipo SEQUENCE

Es necesario recordar que el tipo SEQUENCE es una lista de tipos pertenecientes a ASN.1. Un valor de SEQUENCE siempre es codificado en forma estructurada (Constructed). Los enlaces de variable usados en los mensajes SNMP proveen un buen ejemplo de SEQUENCE. Los enlace de variable ( o VarBind) enlazan un nombre de objeto con su valor, el cual es transmitido dentro del campo Valor, como se muestra en la figura 3. SNMP (RFC 1157, pag. 32) define el VarBind:
 
 

VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax, } VarBindList ::= SEQUENCE OF VarBind END

Como lo muestra esta sintaxis, el VarBind es un SEQUENCE (enlace) de un nombre, un valor, y la VarBindList es una lista de nombres y valores.

Aquí va un ejemplo: Suponga que Usted necesita la descripción del sistema para un objeto particular cuyo nombre es sysDescr. Para obtener la descripción del sistema, el administrador transmite un SNMP GetRequest al agente preguntando por el valor del objeto sysDescr. El agente responde con un mensaje SNMP GetResponse que contiene el valor, tal como “Retix Local Ethernet Bridge Model 2265M.” El VarBind asocia el objeto (sysDescr) y su valor (“Retix...”), como se muestra en la figura 10.

El primer campo Tipo (30H) indica un tipo estructurado, con Tag = 16 (SEQUENCE). El primer campo Longitud contiene 33H, indicando que sigue el octeto de valor 51. El BER es aplicado entonces para todos los tipos en SEQUENCE. La primera secuencia identifica un tipo primitivo con Tag = 6 (OBJECT IDENTIFIER) y Longitud = 08H. El campo valor contiene la representación numérica del objeto sysDescr {1.3.6.1.2.1.1.1.0}. La segunda secuencia identifica un tipo primitivo con Tag = 4 (OCTET STRING), y Longitud = 27H (39 en decimal). El segundo campo Valor representa el valor del objeto sysDescr (Retix Local Bridge ...”). Si se tiene una calculadora, se puede mirar la longitud total de la codificación. La secuencia # 1 contiene 10 octetos (1 del campo Tipo + 1 de la Longitud + 8 del Valor). La secuencia # 2 contiene 41 octetos (1 + 1 + 39). La secuencia # 1 más la secuencia # 2 (10 + 41) es igual al valor del primer campo de Longitud (51 octetos).

3.6. Codificación del tipo SEQUENCE-OF

El valor del tipo SEQUENCE-OF es codificado en forma estructurada y de la misma manera que el tipo SEQUENCE.

3.7. Codificación del tipo IPADDRESS

Esta discusión se traslada ahora a las codificaciones que hacen uso de la clase application . Esto se puede encontrar en la sección “La definición concisa de SMI”, como tagged types. Puesto que todas estas codificaciones son de clase application (01) y primitivas (P/C = 0) ,con números de tag entre 0 y 4, los campos Tipo estarán en un rango de 40 a 44H (ver figuras 11 a la 14).

La SMI define el tipo IpAddress. El IpAddress lleva una dirección IP de 32 bits, la cual está representada en cuatro octetos. Saltando a la discusión sobre la MIB, el grupo IP contiene objetos que relacionan los procesos IP en un router o un host. Un objeto llamado IpAdEntAddr identifica la dirección IP que está relacionada a la información subsiguiente. Para codificar la IpAdEntAddr (ver figura 11), el campo Tipo es puesto a 40H (clase solicitud, Tag = 0). El campo Longitud = 4, representando los cuatro octetos en la dirección IP. El campo Valor contiene cuatro octetos, los cuales transportan la dirección IP en notación decimal punteada. Para la dirección mostrada en el ejemplo (128.150.161.8), el primer octeto en el campo Valor contiene el binario equivalente a 128 (10000000), el segundo, el binario equivalente a 150, y así sucesivamente.

El tipo TimeTicks (también definido en la SMI) contiene una marca de tiempo (time-stamp) que mide el tiempo transcurrido (en centésimas de segundos) desde algún evento. El objeto sysUpTime mide el tiempo desde que la entidad de administración de la red sobre un dispositivo fue reinicializado. Si el valor de sysUpTime para un dispositivo particular fue 263’691.156 centésimas de segundo (alrededor de 30 días), su valor debería ser codificado como se muestra en la figura 14. El campo Tipo debería ser fijado a 43H (clase solicitud, Primitiva, Tag = 3). Cuatro octetos representan un valor igual a 263691156. Por lo tanto, El campo Longitud contiene 04H. Los cuatro octetos en el campo Valor contienen la representación binaria del valor TimeTicks.

3.11. Codificación de CONTEXT-SPECIFICS para SNMP

La clase final de codificación discutida en esta sección es la codificación de context-specific, la cual es utilizada en el contexto de SNMP. Cinco unidades de dato de protocolo (PDUs), transportan la información de SNMP. Los PDUs son GetRequest, GetNextRequest, GetResponse, SetRequest y Trap. Estos PDUs tienen números de tag de 0 a 4 respectivamente. Estas codificaciones son todas de la clase context-specific (10) y estructurada (P/C = 1). El campo Tipo, de esta manera, tiene valores en el rango de A0 hasta A4H (ver figura 15). Los campos Valor y Longitud dependen de la información transportada.

3. Nombres de objeto

La raíz no necesita una designación, pero un valor numérico específico designa a los tres arcos conectados, o ramas. La Union Internacional de Telecomunicaciones - Sector de estándares de telecomunicaciones (ITU-T) administra la rama etiquetada como 0, la Organización Internacional de Estandarización (ISO) administra la rama etiquetada como 1, y la ISO junto con la ITU-T administran la tercera rama etiquetada como 2.

La rama ITU-T tiene cinco ramas hijas: recommendation (o) identifica las recomendaciones de la ITU-T; question (1) es usado por los grupos de estudio de la ITU-T; administration (2) identifica los valores de X.121 DCCs (Data Country Codes); network-operator (3) identifica los valores de X.121 códigos de identificación de redes de datos ( Data Network Identification codes – DNICs -); e identified-organization (4) identifica los valores asignados por el Departamento de estandarización de la ITU (Telecommunication Standarization Bureau - TSB -) .

El departamento de defensa de los E.E.U.U. es asignado a una de las ramas hijas bajo 1.3, y es designado como 6. En este árbol la comunidad Internet tiene designación 1.

Para identificar una posición particular en el árbol, se deben listar los valores numéricos en una cadena, separados por puntos. Por ejemplo, para identificar la posición del subárbol de Internet, se debe empezar por la raíz y moverse hacia abajo hasta alcanzar la posición {1.3.6.1}.

En el nivel Internet (ver figura 18), se empiezan a ver detalles pertinentes a la administración de la red y a SNMP. El subárbol Internet tiene cinco ramas:

El subárbol directory (1), {internet 1} o {1.3.6.1.1}, es reservado para uso futuro mediante el directorio OSI en el Internet.

El subárbol mgmt (2), {internet 2} o {1.3.6.1.2}, es manejado por la Autoridad de Números Asignados a Internet (Internet Assigned Numbers Authority – IANA -), e incluye la MIBs estándar.

El subárbol experimental (3), {internet 3} o {1.3.6.1.3}, es usado para experimentos de Internet.

El subárbol security (5), {internet 5} o {1.3.6.1.5}, es usado por objetos relacionados con la seguridad.

El subárbol snmpV2 (6), {internet 6} o {1.3.6.1.6}, es usado por los objetos de la versión 2 de SNMP.

El subárbol mail (7), {internet 7} o {1.3.6.1.7}, es usado por objetos mail.

El IANA administra éstos subárboles y los publica en el actual documento de Números Asignados (actualmente RFC 1700).

A continuación se mirará la estructura de árboles aplicables al cuerpo de administración de la red estándar Internet. La MIB estándar de Internet está definida por {mgmt 1} o {1.3.6.1.2.1}. Bajo este árbol están los objetos definidos por la MIB-II (RFc 1213), tal como el monitoreo de red remoto (remote network monitoring (RMON) MIB, (RFC 1757), y muchos otros.

Retornando al ejemplo dado al comienzo de esta sección. Ahora que ya se conoce las identidades de las estructuras de árbol individuales, ahora se puede construir la siguiente secuencia:
 
 

Internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } Mgmt OBJECT IDENTIFIER ::= { internet 2 } mib OBJECT IDENTIFIER ::= { mgmt 1} system OBJECT IDENTIFIER ::= { mib-2 1 } sysDescr OBJECT IDENTIFIER ::= { system 1 }

Cuando estas tres estructuras son combinadas, el resultado es:

sysDescr OBJECT IDENTIFIER ::= { 1.3.6.1.2.1.1.1 }

Al OID se le necesita añadir un último elemento – un sufijo que identifica si una variable particular ocurre justo una vez (un escalar) o si la variable ocurre múltiples veces (como en entradas de columnas).

Desde que sysDescr sea un objeto escalar, no columnar, hay solo una instancia de esto. (En orden de palabras, se puede tener solo una descripción del sistema a ser manejado.)

{ 1.3.6.1.2.1.1.1.0 }

Si el objeto fue una entrada columnar, la cual tendría múltiples instancias, un índice más un sufijo distinto de cero (.1, .2, una dirección IP, y así sucesivamente ), identificaría al objeto en la tabla.

Los códigos experimentales con prefijo {1.3.6.1.3}, han sido asignados a muchos objetos LAN y WAN y MIBs, tal como ISO CLNS (Servicios de red no orientados a conexión – Connectionless Network Service), a objetos de la Red Óptica Sincrónica (SONET) , y objetos de ATM (Modo de Transferencia Asíncrono), mientras la tecnología y sus MIBs estuvieron en la fase de prueba de desarrollo. De esta forma, como los grupos de trabajo de la Fuerza de Tareas de Ingeniería de Internet (IETF) desarrollan MIBs, ellos las definen bajo una rama en el árbol experimental. Una vez estas MIBs son publicadas y puestas en la pista estándar, ellos la mueven a la rama en el subárbol Internet.

MIBs de vendedores específicos utilizan códigos empresariales privados con prefijo { 1.3.6.1.4.1 }. Esta es un área de rápido crecimiento porque numerosos vendedores están desarrollando estructuras para soportar sus dispositivos de Internetworking, servidores, y así sucesivamente. Los ejemplos incluyen a 3Com Corporation (Santa Clara, CA) con código { 1.3.6.1.4.1.43 }; FTP Software Inc. (Ahora parte de NetManage, Inc., North Andover, MA) con código { 1.3.6.1.4.1.121 }; y US West Advanced Technologies (Denver, CO) with code { 1.3.6.1.4.1.312 }.

La definición concisa De SMI

Todos los derechos reservados.