Structure of Management Information (SMI) para SNMPv1

El SMI establece que cada objeto administrado debe tener un nombre, una sintaxis y una codificación. El nombre, o identificador de objeto (OID), identifica de manera única el objeto. La sintaxis define el tipo de dato, por ejemplo, un entero o una cadena de octetos. La codificación describe como la información asociada con los objetos administrados es "serializada" para transmitir entre máquinas.

1. Abstract Syntax Notation One

Para que los agentes y los managers puedan intercambiar datos, ambos deben entenderlos, sin importaar la forma en cada uno lo pueda representar internamente (los procesadores Intel y los Motorola representan de diferente manera los datos). Para que esto pueda darse deben estandarizarse dos cosas: la sintaxis abstracta y la sintaxis de transferencia. La sintaxis abstracta define las especificaciones para notación de datos. La sintaxis de transferencia define la codificación para (transmitir) los elementos definidos en la sintaxis abstracta.

La SMI del modelo de información de la arquitectura de administración de Internet define que ASN.1 define la sintaxis abstracta para los mensajes; es decir ASN.1 define los elementos de lenguaje básico y proporciona las reglas para combinar elementos en mensajes. Las reglas básicas de codificación (BER) proporciona la sisntaxis de transferencia. Las reglas BER están asociadas con la sintaxis abstracta y provee la comunicación a nivel de bit entre máquinas.

La notación ASN.1 fue publicada en la recomendación ITU-T X.208 | ISO/IEC 8824 (diciembre/1987). En 1995 se hicieron revisiones para corregir errores, ambiguedades e incluir nuevas capacidades. Los documentos revisados están contenidos en las recomendaciones de la serie X.680. 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

1.1.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 los 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

1.1.4. Convenciones en ASN.1

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

Caracteres especiales en ASN.1:

2. Detalles de ASN.1 – Objetos y tipos

Esta definición ASN.1 significa: definición de un objeto llamado tcpInSegs que contiene información del tipo 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 accede este objeto, utiliza el nombre { tcp 10 }, el cual identifica el décimo objeto definido dentro del grupo tcp.

2.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 están divididos en dos categorías: los tipos primitivos (Primitive) y los tipos constructores (Constructor). Los tipos de datos primitivos (también llamados tipos simples) incluyen INTEGER, OCTET, STRING, OBJECT IDENTIFIER y NULL.

INTEGER es un tipo primitivo con valores diferenciados (o únicos) 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 uso del tipo INTEGER es:

ipDefaultTTL OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol." ::= { ip 2 }

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 de acceso al medio (o capa física). Un ejemplo del uso del DisplayString es:

sysContact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The textual identification of the contact person for this managed node, together with 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 which is 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 syntatically valid object identifier, and any conformant 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 como placeholder, pero actualmente no es utilizado por los objetos de SNMP. (NULL es utilizado como placeholder en varios campos de asociación de variables en el PDU GetRequest de SNMP: NULL sustituye el valor de una variable desconocida, es decir el valor que GetRequest está solicitando).

2.3. Tipos Constructor o Estructurados

Los tipos constructor (Constructor) o estructurados (Structured), SEQUENCE y SEQUENCE OF, definen tablas y filas (entries) 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.

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. SEQUENCE como un todo, define una fila dentro de un tabla. Cada entrada (entry) en la SEQUENCE especifica una columna dentro de 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. Al igual que 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 SYNTAX 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, in that 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 la 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 que está en mayúscula. La cláusula INDEX define la construcción y orden de las columnas que conforman las filas.

2.4. Tipos definidos

El modelo de información de la arquitectura de administración Internet utiliza los tipos definidos (o application-wide) (descrito en el RFC 1155). Los tipos definidos incluyen NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, y Opaque.

El tipo NetworkAddress fue diseñado para representar una dirección de alguna de las diversas familias de protocolos existentes. CHOICE es un tipo primitivo que provee alternativas entre otros tipos; esto es encontrado en muchas secciones de 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. Ejemplo:

atNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCESS 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 sólo direcciones IP (y, por tanto, “choice” por omisión), no se recomienda el uso de este tipo de datos.

IpAddress es un tipo definido que representa direcciones de internet de 32 bits. Es representado como un OCTET STRING de longitud 4 (octetos) utilizando el orden "de red" para los bytes (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 }

Counter es un tipo definido (application-wide) 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; finaliza con una s minúscula. Ejemplo:

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

Gauge es un tipo definido que representa un entero no negativo. Este puede incrementarse o decrementarse, pero dentro de un valor máximo. El máximo valor del contador es 2³²-1 (4’294.967.295 en decimal). 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 which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth." ::= { ifEntry 5 }

TimeTicks es un tipo definido que representa un entero no negativo que cuenta el tiempo en centésimas de segundos desde algún periodo o instante de tiempo. Cuando la MIB define tipos de objeto que usan éste tipo ASN.1, la descripción del tipo del objeto identifica el instante (inicial) de referencia. 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, “envolviendo dos veces” el valor ASN.1 original. Actualmente SNMP no utiliza Opaque, aunque puede ser encontrado en algunas MIBs privadas.

2.5. Tipos etiquetados (Tagged types)

Los tags (etiquetas) distinguen entre objetos definidos. 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 un tipo definido (previamente) como base, y luego se añade la información "exclusiva". 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 (RFC1157) 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 los paréntesis cuadrados ([ ]) identifica tipos tagged (etiquetados). Por ejemplo, en la definición concisa de SMI encontramos:

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

Por lo tanto, el tipo TimeTicks es un tipo tagged, llamado APPLICATION 3. Es de la clase application y el número del tag es 3. Este puede asumir un valor en el rango de valores entre 0 y 4.294'967.295. La palabra IMPLICIT indica que el tag asociado con el tipo INTEGER no será transmitido, pero el tag asociado con TimeTicks sí. Esto reduce el tamaño del dato que debe ser codificado y transmitido.

3. Reglas de codificación

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

Para definir la representación de los datos externos, las reglas BER especifican primero la posición de cada bit dentre de los octetos a ser transmitidos. Cada octeto transmite primero el bit más significativo (Most Significant Bit - MSB) y lo definen como el bit 8 del lado izquierdo del octeto. El bit menos significativo (Least Significant Bit - LSB) se define en el octeto como el bit 1 colocado a la derecha del mismo (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) o 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, BER garantiza que ambos extremos (nodos) interpreten el flujo de bits de una forma consistente.

3.2.1. Campo Tipo (Type field)

El campo Tipo va de primero e informa para que se destinó la estructura que sigue. El campo Tipo contiene una identificación para la estructura codificada; 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) (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 (figura 4). Cuando el número del tag es 31 o superior, el campo Tipo está construido con múltiples octetos. En cualquier caso, el primer octeto contiene tres subcampos: Clase (Class), bit P/C y número de tag (tag number). El subcampo Clase codifica la clase de tag en uso:

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

El subcampo P/C (bit 6) indica la forma del elemento. 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 utiliza 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 (bit más significativo) del tag; el bit 1 es el LSB.

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

La siguiente lista 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:

Aunque BER también permite números de tag como 31 o superiores, SNMP no los utiliza. Para los números de tag mayores de 31, el campo Tipo usa un formato diferente (figura 4). El numero de tag en el primer octeto es el binario 11111 (decimal 31), y octetos adicionales se agregan para "trasportar" el número de tag. El bit 8 = 1 (MBS = 1) de un octeto indica que siguen más octetos; el bit 8 = 0 (MBS = 0) de un octeto especifica que es 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 primer octeto subsiguiente representa el MSB del número del tag.

3.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 definida larga (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 camp Valor; la forma definida larga indica 128 o más octetos en el campo Valor, aunque esta puede representar longitudes más cortas.

La forma larga usa múltiples octetos para representar la longitud total: el primer octeto del campo Longitud tiene el bit 8 = 1, seguido por un número binario indicando el número de octetos que siguen. Este número debe estar entre 1 y 126; el valor 127 está reservado para extensiones futuras. El bit 8 del segundo octeto es considerado el MSB del campo Longitud, y los octetos siguientes conforman 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).

3.2.3. Campo Valor (Value field)

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

3.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. Los otros tipos se pueden encontrar en ISO 8825-1.

3.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 complemento-2, iguales al valor entero, y pueden usar tantos octetos como sea necesario. Por ejemplo, el entero "75" sería codificado como: campo Tipo = 02H, campo Longitud = 01H y campo Valor = 4BH (figura 6).

3.3.2. Codificación del tipo OCTET STRING

El OCTET STRING es un tipo simple cuyos valores 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 el campo Valor dependen de la información codificada.

Se usará la cadena "BBM" en el ejemplo para mostrar la codificación del tipo OCTET STRING (figura 7). 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 utiliza ASCII.(figura 7)

3.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 subidentificador, el cual puede ser más grande. 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 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, el OBJECT IDENTIFIER tiene un valor de:

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

Del árbol de objetos, esto está representado por:

{ 1.3.6.1.2.1.1. }

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

Usando los valores de X = 1 y Y = 3, el primer valor del subidentificador es:

(1 * 40) + 3 = 43

Esto nos lleva a saber que el primer valor de subidentificador es 43, el segundo valor del subidentificador es 6, el tercero es 1, etcétera. El primer valor (43) necesita seis bits para su codificación (que cabe en un octeto: 00101011). El segundo valor (6) necesita 3 bits para la codificación (110), y requiere sólo un octeto. Los valores subsiguientes también requieren un octeto. La codificación tiene de esta forma: campo Tipo = 06H (OBJECT IDENTIFIER, tag = 6); campo Longitud = 06H; y campo Valor = 2B 06 01 02 01 01 H (figura 8).

3.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.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.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.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.

3.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.

4. Nombres de los objetos

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 }.

5. Definición concisa de la SMI