Abstract Syntax Notation One ( ASN.1 ) es un lenguaje de descripción de interfaz estándar para definir estructuras de datos que se pueden serializar y deserializar de manera multiplataforma. Se utiliza ampliamente en telecomunicaciones y redes informáticas , y especialmente en criptografía . [1]
Notación de sintaxis abstracta uno | |
Estado | En vigor; reemplaza X.208 y X.209 (1988) |
---|---|
Año iniciado | 1995 |
Ultima versión | (15/08) Agosto de 2015 |
Organización | ITU-T |
Estándares básicos | ASN.1 |
Estándares relacionados | X.208 , X.209 , X.509 , X.680, X.681, X.682, X.683 |
Dominio | criptografía , telecomunicaciones |
Sitio web | https://www.itu.int/rec/T-REC-X.680/ |
Los desarrolladores de protocolos definen las estructuras de datos en los módulos ASN.1, que generalmente son una sección de un documento de estándares más amplio escrito en el lenguaje ASN.1. La ventaja es que la descripción ASN.1 de la codificación de datos es independiente de una computadora o lenguaje de programación en particular. Debido a que ASN.1 es legible por humanos y por máquina, un compilador de ASN.1 puede compilar módulos en bibliotecas de código, códecs , que decodifican o codifican las estructuras de datos. Algunos compiladores de ASN.1 pueden producir código para codificar o decodificar varias codificaciones, por ejemplo, empaquetado, BER o XML .
ASN.1 es una norma conjunta del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones ( UIT-T ) en la Comisión de Estudio 17 del UIT-T e ISO / IEC , originalmente definida en 1984 como parte de CCITT X.409: 1984. [2] En 1988, ASN.1 pasó a su propio estándar, X.208 , debido a su amplia aplicabilidad. La versión de 1995 sustancialmente revisada está cubierta por la serie X.680 . [3] La última revisión de la serie de recomendaciones X.680 es la Edición 5.0, publicada en 2015.
Ayuda de idioma
ASN.1 es una notación de declaración de tipo de datos. No define cómo manipular una variable de ese tipo. La manipulación de variables se define en otros lenguajes como SDL (lenguaje de especificación y descripción) para modelado ejecutable o TTCN-3 (notación de control de pruebas y pruebas) para pruebas de conformidad. Ambos lenguajes admiten de forma nativa declaraciones ASN.1. Es posible importar un módulo ASN.1 y declarar variable de cualquiera de los tipos ASN.1 declarados en el módulo.
Aplicaciones
ASN.1 se utiliza para definir una gran cantidad de protocolos. Sus usos más extensos continúan siendo las telecomunicaciones, la criptografía y la biometría.
Protocolo | Especificación | Reglas de codificación específicas o habituales | Usos |
---|---|---|---|
Protocolo de interledger | https://interledger.org/rfcs/asn1/index.html | Reglas de codificación de octetos | |
NTCIP 1103 - Protocolos de gestión de transporte | NTCIP 1103 | Reglas de codificación de octetos | Gestión de tráfico, transporte e infraestructura |
Servicios de directorio X.500 | Serie de recomendaciones ITU X.500 | Reglas de codificación básicas, reglas de codificación distinguidas | Certificados LDAP, TLS ( X.509 ), autenticación |
Protocolo ligero de acceso a directorios (LDAP) | RFC 4511 | Reglas de codificación básicas | |
Estándares de criptografía PKCS | Estándares de criptografía PKCS | Reglas de codificación básicas y reglas de codificación distinguidas | Claves asimétricas, paquetes de certificados |
Manejo de mensajes X.400 | Serie de recomendaciones ITU X.400 | Uno de los primeros competidores al correo electrónico | |
EMV | Publicaciones EMVCo | Tarjetas de pago | |
Conferencia multimedia T.120 | La serie de recomendaciones ITU T.120 | Reglas de codificación básicas, reglas de codificación empaquetadas | Protocolo de escritorio remoto de Microsoft (RDP) |
Protocolo simple de administración de redes (SNMP) | RFC 1157 | Reglas de codificación básicas | Administrar y monitorear redes y computadoras, particularmente características relacionadas con el rendimiento y la confiabilidad |
Protocolo de información de gestión común (CMIP) | Recomendación UIT X.711 | Un competidor de SNMP pero más capaz y no tan popular | |
Sistema de señalización N. ° 7 (SS7) | Serie de recomendaciones ITU Q.700 | Gestión de conexiones telefónicas a través de la red telefónica pública conmutada (PSTN) | |
Protocolos multimedia de la serie H de la UIT | Las series de recomendaciones ITU H.200, H.300 y H.400 | Protocolo de voz sobre Internet (VOIP) | |
Protocolo de interfuncionamiento de BioAPI (BIP) | ISO / IEC 24708: 2008 | ||
Marco común de formatos de intercambio biométrico (CBEFF) | NIST IR 6529-A | Reglas de codificación básicas | |
Contextos de autenticación para datos biométricos (ACBio) | ISO / IEC 24761: 2019 | ||
Aplicaciones de telecomunicaciones asistidas por computadora (CSTA) | https://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm | Reglas de codificación básicas | |
Comunicaciones dedicadas de corto alcance (DSRC) | SAE J2735 | Reglas de codificación empaquetadas | |
Sistema global de comunicaciones móviles (GSM) | http://www.ttfn.net/techno/smartcards/gsm11-11.pdf | Comunicaciones por telefonía móvil | |
Servicio general de radio por paquetes (GPRS) / Velocidades de datos mejoradas para la evolución global (EDGE) | http://www.3gpp.org/technologies/keywords-acrónimos/102-gprs-edge | Comunicaciones por telefonía móvil | |
Sistema universal de telecomunicaciones móviles (UMTS) | http://www.3gpp.org/DynaReport/25-series.htm | Comunicaciones por telefonía móvil | |
Evolución a largo plazo (LTE) | http://www.3gpp.org/technologies/keywords-acrónimos/98-lte | Comunicaciones por telefonía móvil | |
Protocolo de alerta común (CAP) | http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html | Reglas de codificación XML | Intercambio de información de alerta, como alertas ámbar |
Comunicaciones de enlace de datos controlador-piloto (CPDLC) | Comunicaciones aeronáuticas | ||
Servicios de extensión de enlace espacial (SLE) | Comunicaciones de sistemas espaciales | ||
Especificación de mensajes de fabricación (MMS) | ISO 9506-1: 2003 | Fabricación | |
Transferencia, acceso y administración de archivos (FTAM) | Un competidor temprano y más capaz del Protocolo de transferencia de archivos, pero ya casi no se usa. | ||
Protocolo de elemento de servicio de operaciones remotas (ROSE) | Recomendaciones UIT X.880, X.881 y X.882 | Una forma temprana de llamada a procedimiento remoto | |
Elemento de servicio de control de asociación (ACSE) | Recomendación UIT X.227 | ||
Protocolo de redes de control y automatización de edificios (BACnet) | ASHRAE 135-2020 | Reglas de codificación BACnet | Automatización y control de edificios, como alarmas contra incendios, ascensores, sistemas HVAC, etc. |
Kerberos | RFC 4120 | Reglas de codificación básicas | Autenticación segura |
WiMAX 2 | Redes de área amplia | ||
Red inteligente | La serie de recomendaciones ITU Q.1200 | Telecomunicaciones y redes informáticas | |
X2AP | Reglas básicas de codificación de paquetes alineados |
Codificaciones
ASN.1 está estrechamente asociado con un conjunto de reglas de codificación que especifican cómo representar una estructura de datos como una serie de bytes. Las reglas de codificación estándar ASN.1 incluyen:
Reglas de codificación | Identificador de objeto | OID-IRI | Descripción | ||||||
---|---|---|---|---|---|---|---|---|---|
Reglas de codificación básicas (BER) [4] | 2.1.1 | /ASN.1/Basic-Encoding | Codificación básica de un solo tipo ASN.1 | UIT X.690 | Octeto | sí | sí | No | Las primeras reglas de codificación especificadas. Codifica elementos como secuencias de valores de longitud de etiqueta (TLV). Normalmente proporciona varias opciones sobre cómo codificar los valores de los datos. Esta es una de las reglas de codificación más flexibles. |
Reglas de codificación distinguidas (DER) [5] | 2.1.2.1 | /ASN.1/BER-Derived/Distinguished-Encoding | Codificación distinguida de un solo tipo ASN.1 | UIT X.690 | Octeto | sí | sí | No | Un subconjunto restringido de las reglas básicas de codificación (BER). Normalmente se usa para cosas que están firmadas digitalmente porque, dado que el DER permite menos opciones de codificación, y debido a que es más probable que los valores codificados en DER se vuelvan a codificar en los mismos bytes exactos, las firmas digitales producidas por un valor abstracto dado serán sean iguales en todas las implementaciones y las firmas digitales producidas sobre datos codificados en DER serán menos susceptibles a los ataques basados en colisiones. |
Reglas de codificación canónica (CER) [6] | 2.1.2.0 | /ASN.1/BER-Derived/Canonical-Encoding | Codificación canónica de un solo tipo ASN.1 | UIT X.690 | Octeto | sí | sí | No | Un subconjunto restringido de las reglas básicas de codificación (BER). Emplea casi todas las mismas restricciones que las Reglas de codificación distinguida (DER), pero la diferencia notable es que el CER especifica que muchos valores grandes (especialmente cadenas) se deben "dividir" en elementos de subcadena individuales en los 1000 bytes o Marca de 1000 caracteres (según el tipo de datos). |
Reglas de codificación empaquetadas básicas (PER) alineadas [7] | 2.1.3.0.0 | /ASN.1/Packed-Encoding/Basic/Aligned | Codificación empaquetada de un solo tipo ASN.1 (alineación básica) | UIT X.691 | Un poco | No | sí | No | Codifica valores en bits, pero si los bits codificados no son divisibles por ocho, se agregan bits de relleno hasta que un número entero de octetos codifica el valor. Capaz de producir codificaciones muy compactas, pero a expensas de la complejidad, y los PER dependen en gran medida de las restricciones impuestas a los tipos de datos. |
Reglas de codificación empaquetadas básicas (PER) no alineadas [7] | 2.1.3.0.1 | /ASN.1/Packed-Encoding/Basic/Unaligned | Codificación empaquetada de un solo tipo ASN.1 (básica no alineada) | UIT X.691 | Un poco | No | No | No | Una variante de las reglas de codificación empaquetadas básicas alineadas (PER), pero no rellena los valores de datos con bits para producir un número entero de octetos. |
Reglas de codificación empaquetadas canónicas (CPER) alineadas [7] | 2.1.3.1.0 | /ASN.1/Packed-Encoding/Canonical/Aligned | Codificación empaquetada de un solo tipo ASN.1 (alineación canónica) | UIT X.691 | Un poco | No | sí | No | Una variante de las Reglas de codificación empaquetadas (PER) que especifica una forma única de codificar valores. Las Reglas de codificación empaquetadas canónicas tienen una relación similar con las Reglas de codificación empaquetadas que las Reglas de codificación distinguida (DER) y las Reglas de codificación canónica (CER) tienen con las Reglas de codificación básicas (BER). |
Reglas de codificación empaquetadas canónicas (CPER) no alineadas [7] | 2.1.3.1.1 | /ASN.1/Packed-Encoding/Canonical/Unaligned | Codificación empaquetada de un solo tipo ASN.1 (canónica no alineada) | UIT X.691 | Un poco | No | No | No | Una variante de las Reglas de codificación empaquetadas canónicas alineadas (CPER), pero no rellena los valores de datos con bits para producir un número entero de octetos. |
Reglas básicas de codificación XML (XER) [8] | 2.1.5.0 | /ASN.1/XML-Encoding/Basic | Codificación XML básica de un solo tipo ASN.1 | UIT X.693 | Personaje | sí | sí | sí | Codifica datos ASN.1 como XML. |
Reglas de codificación XML canónicas (CXER) [8] | 2.1.5.1 | /ASN.1/XML-Encoding/Canonical | Codificación XML canónica de un solo tipo ASN.1 | UIT X.693 | Personaje | sí | sí | sí | |
Reglas de codificación XML extendidas (EXER) [8] | 2.1.5.2 | /ASN.1/XML-Encoding/Extended | Codificación XML extendida de un solo tipo ASN.1 | UIT X.693 | Personaje | sí | sí | sí | |
Reglas de codificación de octetos (REA) [9] | 2.1.6.0 | Codificación básica de REA de un solo tipo ASN.1 | UIT X.696 | Octeto | No | sí | Un conjunto de reglas de codificación que codifica valores en octetos, pero no codifica etiquetas o determinantes de longitud como las Reglas de codificación básicas (BER). Los valores de datos codificados mediante las reglas de codificación de octetos a menudo se parecen a los que se encuentran en los protocolos "basados en registros". Las reglas de codificación de octetos (REA) fueron diseñadas para ser fáciles de implementar y producir codificaciones más compactas que las producidas por las reglas de codificación básicas (BER). Además de reducir el esfuerzo de desarrollar codificadores / decodificadores, el uso de REA puede disminuir la utilización del ancho de banda (aunque no tanto como las Reglas de codificación empaquetadas), ahorrar ciclos de CPU y disminuir la latencia de codificación / decodificación. | ||
Reglas de codificación canónica (REA) [9] | 2.1.6.1 | Codificación canónica de REA de un solo tipo ASN.1 | UIT X.696 | Octeto | No | sí | |||
Reglas de codificación JSON (JER) [10] | UIT X.697 | Personaje | sí | sí | sí | Codifica datos ASN.1 como JSON. | |||
Reglas genéricas de codificación de cadenas (GSER) [11] | 1.2.36.79672281.0.0 | Reglas genéricas de codificación de cadenas (GSER) | RFC 3641 | Personaje | sí | No | Una especificación incompleta para las reglas de codificación que producen valores legibles por humanos. El propósito de GSER es representar datos codificados al usuario o datos de entrada del usuario, en un formato muy sencillo. GSER se diseñó originalmente para el Protocolo ligero de acceso a directorios (LDAP) y rara vez se usa fuera de él. Se desaconseja el uso de GSER en protocolos reales, ya que no todas las codificaciones de cadenas de caracteres admitidas por ASN.1 pueden reproducirse en él. | ||
Reglas de codificación BACnet | ASHRAE 135 | Octeto | sí | sí | sí | Codifica elementos como secuencias de valor de longitud de etiqueta (TLV) como las Reglas de codificación básicas (BER). | |||
Reglas de codificación específicas de señalización (SER) | Documento interno de I + D de France Telecom | Octeto | sí | sí | Se utiliza principalmente en protocolos relacionados con las telecomunicaciones, como GSM y SS7. Diseñado para producir una codificación idéntica a partir de ASN.1 que producirían los protocolos previamente existentes no especificados en ASN.1. | ||||
Reglas de codificación ligera (LWER) | Documento interno de INRIA. | Palabra de memoria | sí | Se origina en un documento interno producido por INRIA que detalla la "Sintaxis de peso ligero de árbol plano" (FTLWS). Abandonado en 1997 debido al rendimiento superior de las Reglas de codificación empaquetadas (PER). Opcionalmente, transmisión Big-Endian o Little-Endian, así como palabras de memoria de 8, 16 y 32 bits. (Por lo tanto, hay seis variantes, ya que hay seis combinaciones de esas opciones). | |||||
Reglas de codificación de bits mínimos (MBER) | Un poco | Propuesto en la década de 1980. Pretende ser lo más compacto posible, como las Reglas de codificación empaquetadas (PER). | |||||||
Reglas de codificación empaquetadas NEMA | Un poco | Una especificación de regla de codificación incompleta producida por NEMA. Está incompleto porque no puede codificar y decodificar todos los tipos de datos ASN.1. Compacto como las Reglas de codificación empaquetadas (PER). | |||||||
Reglas de codificación de alta velocidad | "Reglas de codificación para redes de alta velocidad" | La definición de estas reglas de codificación fue un subproducto del trabajo de INRIA en la sintaxis de peso ligero de árbol plano (FTLWS). |
Notación de control de codificación
Las recomendaciones de ASN.1 proporcionan una serie de reglas de codificación predefinidas. Si ninguna de las reglas de codificación existentes es adecuada, la Notación de control de codificación (ECN) proporciona una forma para que el usuario defina sus propias reglas de codificación personalizadas.
Relación con la codificación de correo con privacidad mejorada (PEM)
La codificación del correo con privacidad mejorada (PEM) no está relacionada en absoluto con ASN.1 y sus códecs, sin embargo, los datos ASN.1 codificados (que a menudo son binarios) suelen estar codificados con PEM. Esto puede ayudar con el transporte a través de medios sensibles a la codificación textual, como retransmisiones SMTP, así como con la copia y el pegado.
Ejemplo
Este es un módulo ASN.1 de ejemplo que define los mensajes (estructuras de datos) de un protocolo Foo ficticio :
FooProtocol DEFINICIONES :: = BEGIN FooQuestion :: = SECUENCIA { trackingNumber INTEGER, pregunta IA5String } FooAnswer :: = SECUENCIA { questionNumber INTEGER, responder BOOLEAN }FINAL
Esta podría ser una especificación publicada por los creadores de Foo Protocol. Los flujos de conversación, los intercambios de transacciones y los estados no se definen en ASN.1, pero se dejan para otras notaciones y descripciones textuales del protocolo.
Suponiendo un mensaje que cumple con el Protocolo de Foo y que se enviará a la parte receptora, este mensaje en particular ( unidad de datos de protocolo (PDU)) es:
myQuestion FooQuestion :: = { trackingNumber 5, pregunta "¿Hay alguien ahí?"}
ASN.1 admite restricciones sobre valores y tamaños, y extensibilidad. La especificación anterior se puede cambiar a
FooProtocol DEFINICIONES :: = BEGIN FooQuestion :: = SECUENCIA { trackingNumber INTEGER (0..199), pregunta IA5String } FooAnswer :: = SECUENCIA { questionNumber INTEGER (10..20), responder BOOLEAN } FooHistory :: = SECUENCIA { preguntas SECUENCIA (TAMAÑO (0..10)) DE FooQuestion, responde SECUENCIA (TAMAÑO (1..10)) DE FooAnswer, anArray SECUENCIA (TAMAÑO (100)) DE INTEGER (0..1000), ... }FINAL
Este cambio obliga a trackingNumbers a tener un valor entre 0 y 199 inclusive, y questionNumbers a tener un valor entre 10 y 20 inclusive. El tamaño de la matriz de preguntas puede estar entre 0 y 10 elementos, con la matriz de respuestas entre 1 y 10 elementos. El campo anArray es una matriz de enteros de 100 elementos de longitud fija que debe estar en el rango de 0 a 1000. El marcador de extensibilidad '...' significa que la especificación del mensaje FooHistory puede tener campos adicionales en versiones futuras de la especificación; Los sistemas compatibles con una versión deberían poder recibir y transmitir transacciones desde una versión posterior, aunque solo pueden procesar los campos especificados en la versión anterior. Los buenos compiladores de ASN.1 generarán (en C, C ++, Java, etc.) código fuente que verificará automáticamente que las transacciones se encuentren dentro de estas restricciones. Las transacciones que violen las restricciones no deben aceptarse ni presentarse en la aplicación. La gestión de restricciones en esta capa simplifica significativamente la especificación del protocolo porque las aplicaciones estarán protegidas de violaciones de restricciones, lo que reduce el riesgo y el costo.
Para enviar el mensaje myQuestion a través de la red, el mensaje se serializa (codifica) como una serie de bytes utilizando una de las reglas de codificación . La especificación del protocolo Foo debe nombrar explícitamente un conjunto de reglas de codificación para usar, de modo que los usuarios del protocolo Foo sepan cuál deben usar y esperar.
Ejemplo codificado en DER
A continuación se muestra la estructura de datos que se muestra arriba como FooQuestion codificada en formato DER (todos los números están en hexadecimal):
30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
DER es una codificación de tipo-longitud-valor , por lo que la secuencia anterior se puede interpretar, con referencia a los tipos estándar SEQUENCE, INTEGER e IA5String, de la siguiente manera:
30 - etiqueta de tipo que indica SECUENCIA13 - longitud en octetos del valor que sigue 02 - etiqueta de tipo que indica INTEGER 01 - longitud en octetos del valor que sigue 05 - valor (5) 16 - tipo de etiqueta que indica IA5String (IA5 significa el conjunto completo de ISO 646 de 7 bits, incluidas las variantes, pero generalmente es US-ASCII) 0e - longitud en octetos del valor que sigue 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - valor ("¿Hay alguien ahí?")
Ejemplo codificado en XER
Alternativamente, es posible codificar la misma estructura de datos ASN.1 con reglas de codificación XML (XER) para lograr una mayor legibilidad humana "a través del cable". Entonces aparecería como los siguientes 108 octetos (el recuento de espacios incluye los espacios utilizados para la sangría):
5 ¿Hay alguien ahí?
Ejemplo codificado en PER (no alineado)
Alternativamente, si se emplean reglas de codificación empaquetadas , se producirán los siguientes 122 bits (16 octetos equivalen a 128 bits, pero aquí solo 122 bits transportan información y los últimos 6 bits son simplemente relleno):
01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0
En este formato, las etiquetas de tipo para los elementos requeridos no están codificadas, por lo que no se pueden analizar sin conocer los esquemas esperados utilizados para codificar. Además, los bytes para el valor de IA5String se empaquetan usando unidades de 7 bits en lugar de unidades de 8 bits, porque el codificador sabe que codificar un valor de byte IA5String requiere solo 7 bits. Sin embargo, los bytes de longitud todavía se codifican aquí, incluso para la primera etiqueta de número entero 01 (pero un empaquetador PER también podría omitirlo si sabe que el rango de valor permitido se ajusta a 8 bits, e incluso podría compactar el byte de valor único 05 con menos de 8 bits, si sabe que los valores permitidos solo pueden caber en un rango más pequeño).
Los últimos 6 bits del PER codificado se rellenan con bits nulos en los 6 bits menos significativos del último byte c0: estos bits adicionales pueden no transmitirse ni usarse para codificar otra cosa si esta secuencia se inserta como parte de una secuencia no alineada más larga. POR secuencia.
Esto significa que los datos PER no alineados son esencialmente un flujo ordenado de bits, y no un flujo ordenado de bytes como con PER alineado, y que será un poco más complejo decodificar por software en procesadores habituales porque requerirá bits contextuales adicionales. desplazamiento y enmascaramiento y no direccionamiento directo de bytes (pero la misma observación sería cierta con procesadores modernos y unidades de memoria / almacenamiento cuya unidad mínima direccionable es mayor que 1 octeto). Sin embargo, los procesadores de señal y procesadores modernos incluyen soporte de hardware para decodificación interna rápida de flujos de bits con manejo automático de unidades informáticas que cruzan los límites de las unidades de almacenamiento direccionables (esto es necesario para un procesamiento eficiente en códecs de datos para compresión / descompresión o con algún cifrado / algoritmos de descifrado).
Si se requiriera la alineación en los límites de los octetos, un codificador PER alineado produciría:
01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
(en este caso, cada octeto se rellena individualmente con bits nulos en sus bits más significativos no utilizados).
Herramientas
La mayoría de las herramientas que admiten ASN.1 hacen lo siguiente:
- analizar los archivos ASN.1,
- genera la declaración equivalente en un lenguaje de programación (como C o C ++),
- genera las funciones de codificación y decodificación en base a las declaraciones anteriores.
Puede encontrar una lista de herramientas compatibles con ASN.1 en la página web de la herramienta ITU-T .
Herramientas en línea
- Herramienta web ASN1 (muy limitada)
- Zona de juegos ASN1 (caja de arena)
Comparación con esquemas similares
ASN.1 tiene un propósito y uso similar a los búferes de protocolo y Apache Thrift , que también son lenguajes de descripción de interfaz para la serialización de datos multiplataforma. Como esos lenguajes, tiene un esquema (en ASN.1, llamado "módulo") y un conjunto de codificaciones, típicamente codificaciones de tipo-longitud-valor . A diferencia de ellos, ASN.1 no proporciona una implementación de código abierto única y fácilmente utilizable, y se publica como una especificación para ser implementada por terceros. Sin embargo, ASN.1, definido en 1984, los precede en muchos años. También incluye una variedad más amplia de tipos de datos básicos, algunos de los cuales están obsoletos, y tiene más opciones de extensibilidad. Un solo mensaje ASN.1 puede incluir datos de múltiples módulos definidos en múltiples estándares, incluso estándares definidos con años de diferencia.
ASN.1 también incluye soporte integrado para restricciones de valores y tamaños. Por ejemplo, un módulo puede especificar un campo entero que debe estar en el rango de 0 a 100. La longitud de una secuencia de valores (una matriz) también se puede especificar, ya sea como una longitud fija o como un rango de longitudes permitidas. Las restricciones también se pueden especificar como combinaciones lógicas de conjuntos de restricciones básicas.
Los valores utilizados como restricciones pueden ser literales utilizados en la especificación de la PDU o valores ASN.1 especificados en otra parte del archivo de esquema. Algunas herramientas ASN.1 harán que estos valores ASN.1 estén disponibles para los programadores en el código fuente generado. Usados como constantes para el protocolo que se está definiendo, los desarrolladores pueden usarlos en la implementación lógica del protocolo. Por lo tanto, todas las PDU y las constantes de protocolo se pueden definir en el esquema, y todas las implementaciones del protocolo en cualquier lenguaje admitido se basan en esos valores. Esto evita la necesidad de que los desarrolladores utilicen constantes de protocolo de código en el código fuente de su implementación. Esto ayuda significativamente al desarrollo del protocolo; Las constantes del protocolo se pueden alterar en el esquema ASN.1 y todas las implementaciones se actualizan simplemente volviendo a compilar, lo que promueve un ciclo de desarrollo rápido y de bajo riesgo.
Si las herramientas ASN.1 implementan correctamente la verificación de restricciones en el código fuente generado, esto actúa para validar automáticamente los datos del protocolo durante la operación del programa. Generalmente, las herramientas ASN.1 incluirán la verificación de restricciones en las rutinas de serialización / deserialización generadas, generando errores o excepciones si se encuentran datos fuera de límites. Es complejo implementar todos los aspectos de las restricciones ASN.1 en un compilador ASN.1. No todas las herramientas admiten la gama completa de posibles expresiones de restricciones. El esquema XML y el esquema JSON admiten conceptos de restricciones similares. El soporte de herramientas para las limitaciones en estos varía. El compilador xsd.exe de Microsoft los ignora.
ASN.1 es visualmente similar al formulario Augmented Backus-Naur (ABNF), que se utiliza para definir muchos protocolos de Internet como HTTP y SMTP . Sin embargo, en la práctica son bastante diferentes: ASN.1 define una estructura de datos, que se puede codificar de varias formas (por ejemplo, JSON, XML, binario). ABNF, por otro lado, define la codificación ("sintaxis") al mismo tiempo que define la estructura de datos ("semántica"). ABNF tiende a usarse con más frecuencia para definir protocolos textuales legibles por humanos, y generalmente no se usa para definir codificaciones de tipo-longitud-valor.
Muchos lenguajes de programación definen formatos de serialización específicos del lenguaje. Por ejemplo, el módulo "pickle" de Python y el módulo "Marshal" de Ruby. Por lo general, estos formatos son específicos del idioma. Tampoco requieren un esquema, lo que los hace más fáciles de usar en escenarios de almacenamiento ad hoc, pero inapropiados para los protocolos de comunicaciones.
JSON y XML tampoco requieren un esquema, lo que los hace fáciles de usar. Sin embargo, ambos son estándares multiplataforma y son muy populares para los protocolos de comunicación, especialmente cuando se combinan con un esquema XML o un esquema JSON .
Algunas herramientas ASN.1 pueden traducir entre ASN.1 y el esquema XML (XSD). La traducción está estandarizada por la UIT. Esto permite definir un protocolo en ASN.1 y también automáticamente en XSD. Por lo tanto, es posible (aunque quizás desaconsejado) tener en un proyecto un esquema XSD compilado por herramientas ASN.1 que produzcan código fuente que serialice objetos hacia / desde formato JSON. Un uso más práctico es permitir que otros subproyectos consuman un esquema XSD en lugar de un esquema ASN.1, quizás satisfaciendo la disponibilidad de herramientas para el lenguaje de subproyectos elegido, con XER utilizado como protocolo de formato de cable.
Para obtener más detalles, consulte Comparación de formatos de serialización de datos .
Ver también
- X.690
- Clase de objeto de información (ASN.1)
- Capa de presentación
Referencias
- ^ "Introducción a ASN.1" . ITU . Archivado desde el original el 9 de abril de 2021 . Consultado el 9 de abril de 2021 .
- ^ "Base de datos de recomendaciones del UIT-T" . ITU . Consultado el 6 de marzo de 2017 .
- ^ UIT-T X.680 - Especificación de notación básica
- ^ UIT-T X.690 - Reglas de codificación básicas (BER)
- ^ UIT-T X.690 - Reglas de codificación distinguidas (DER)
- ^ UIT-T X.690 - Reglas de codificación canónica (CER)
- ^ a b c d ITU-T X.691 - Reglas de codificación empaquetadas (PER)
- ^ a b c UIT-T X.693 - Reglas de codificación XML (XER)
- ^ a b UIT-T X.696 - Reglas de codificación de octetos (REA)
- ^ UIT-T X.697 - Reglas de codificación de notación de objetos JavaScript (JER)
- ^ RFC 3641 - Reglas de codificación de cadenas genéricas (GSER)
enlaces externos
- Una guía básica para un subconjunto de ASN.1, BER y DER Una buena introducción para principiantes
- Sitio web del UIT-T - Introducción a ASN.1
- Una introducción en video a ASN.1
- Tutorial de ASN.1 Tutorial sobre conceptos básicos de ASN.1
- Tutorial Tutorial de ASN.1 en ASN.1
- Un compilador ASN.1-> C ++ de código abierto; Incluye algunas especificaciones ASN.1. , Un compilador ASN.1-> C ++ en línea
- Decodificador ASN.1 Permite decodificar mensajes codificados en ASN.1 en salida XML.
- Comprobador de sintaxis ASN.1 y codificador / decodificador Comprueba la sintaxis de un esquema ASN.1 y codifica / decodifica mensajes.
- Codificador / decodificador ASN.1 de mensajes 3GPP Codifica / decodifica mensajes ASN.1 3GPP y permite una fácil edición de estos mensajes.
- Libros gratuitos sobre ASN.1
- Lista de herramientas ASN.1 en el proyecto IvmaiAsn
- Descripción general de las reglas de codificación de octetos (REA)
- Descripción general de las reglas de codificación JSON (JER)
- Una utilidad de nodo de TypeScript para analizar y validar mensajes ASN.1