AIDA NG - Documento de Control de Interfaz (ICD)

1 Descripción General
(1) El sistema AIDA-NG proporciona una amplia gama de protocolos de comunicación en apoyo del
intercambio de mensajes, acceso a directorios y gestión de red.

(2) El presente documento describe las interfaces externas de AIDA-NG. Esto incluye también
interfaces proporcionadas por componentes COTS integrados con AIDA-NG, tales como X.400
Message Store y ATN Directory Server si corresponde.

2 Protocolo
(1) El sistema AIDA-NG proporciona dos (2) conjuntos de protocolos para aprovechar la diversidad
y la eficiencia del sistema operativo, por un lado, y para satisfacer requisitos específicos, por otro.
El primer conjunto de protocolos denominado también "Pila del Sistema" es parte del sistema
operativo y proporciona un conjunto comúnmente utilizado de protocolos robustos.
El segundo conjunto de protocolos se denomina "COMSOFT Network Architecture (CNA)" y
proporciona un conjunto de protocolos relacionados con ATN y otros requisitos específicos. La CNA
hace uso de la pila del sistema donde sea aplicable.

(2) La pila del sistema se describe en el capítulo 2.1, la CNA se describe en el capítulo 2.2. La Figura
1 y la Figura 2 de los capítulos siguientes ofrecen una visión general de todos los protocolos y pilas
de protocolos integrados en el sistema AIDA-NG. Cada protocolo se asigna a una capa determinada
(L1-L7) según el modelo de referencia ISO/OSI. Protocolos que se ejecutan en la misma capa - p.
Para las asignaciones de transporte - están separados por una barra.

(3) El lector debe ser consciente del hecho de que no todas las combinaciones de protocolo
teóricamente posibles están disponibles. La Tabla 1 y la Tabla 2 enumeran los protocolos y
combinaciones de protocolo soportados disponibles para el sistema.

(4) El software está estructurado modularmente de tal manera que protocolos adicionales y
combinaciones de protocolos podrían ser soportados en extensiones futuras, si es necesario.

2.1 Pila del Sistema

(1) Los protocolos y combinaciones de protocolos de la pila del sistema se dan a continuación en
Figura 1:
2) La Tabla 1 muestra las diversas posibilidades de comunicación ofrecidas por la pila del sistema.
La tabla enumera todas las posibles combinaciones de protocolos que estarán disponibles.

No App. L7 L6 L5 L4 L3 L2 L1
1. SSH Apps. SSH TCP IP --- Ethernet
2. SCP Apps. SCP TCP IP --- Ethernet
3. --- (CNA) TCP IP --- Ethernet
4. NTP Apps. NTP UDP IP --- Ethernet
5. --- (CNA) UDP IP --- Ethernet
Table 1: Overview: System Stack Protocol Combinations

(3) Los protocolos basados en TCP y UDP de la CNA hacen uso de los protocolos TCP y UDP de la
pila del sistema, como indica el color de fondo blanco de las casillas denominadas 'CNA (TCP)' y
'CNA (UDP)'.

(4) La pila del sistema se basa en zócalos. La descripción de la casilla denominada «Ethernet» figura
en la sección 3.1.

(5) La pila del sistema comprende protocolos adicionales, combinaciones de protocolos y

Aplicaciones proporcionadas por el sistema operativo LINUX que se enumeran anteriormente.

2.2 Arquitectura de red de COMSOFT

(1) Los protocolos y combinaciones de protocolo de la arquitectura de red COMSOFT (CNA) se
indican a continuación:
(2) La siguiente tabla muestra las distintas posibilidades de comunicación ofrecidas por CNA. Es
evidente que el AIDA-NG apoya plenamente el AMHS basado en IP Infraestructura de tierra/tierra
en la Región EUR de la OACI, así como en la Infraestructuras tierra/tierra en otras regiones (por
ejemplo, en la región de Asia y el Pacífico, etc.). Por lo tanto, AIDA-NG es perfectamente adecuado
para actuar como la puerta de enlace frontera entre dos (2) regiones con diferentes
infraestructuras de red.

(3) Los detalles de los protocolos de aplicación basados en UDP y TCP, así como en los protocolos
basados en ISO. Los protocolos que se dan directamente debajo de las "Aplicaciones (CNA)" están
en la Tabla 2.

(4) La CNA utiliza la implementación de TCP, UDP y capas inferiores de la pila del sistema, como se
indica en el color de fondo blanco de las casillas denominadas "UDP (Sistema)", "TCP (Sistema)",
(Sistema) 'y' Ethernet (Sistema)’. La descripción de la casilla denominada «Ethernet (Sistema)»
figura en la sección 3.1.

(5) Las aplicaciones, así como los protocolos basados en TCP y UDP de la CNA se basan
actualmente en IPv4 y/o IPv6.
(6) La interfaz en serie mencionada en las tablas anteriores puede ser cualquiera de las interfaces
en serie disponibles del sistema (por ejemplo, V.11). TTY (ITA-2 Baudot) se puede suministrar como
una tarjeta de interfaz adicional conectada a una interfaz serie V.24. Las secciones 3.2 y 3.3
proporcionan detalles sobre las interfaces serie.

(7) El protocolo Asynchronous Byte (Byte asíncrono), el protocolo HDLC y el protocolo X.25 se
ejecutan sobre todos los tipos de interfaces en serie, pero no pueden compartirlas. Véase también
(6).

(8) Las conexiones basadas en IP pueden vincularse con cualquier tipo de protocolo de transporte
de red subyacente (X.25, Frame Relay, ATM, VPN). El equipo de red requerido debe ser acordado
con el cliente y puede ser entregado a petición.

(9) Las conexiones ATN a los interlocutores de comunicación nacionales/adyacentes pueden estar
basadas en enlaces directos ISO TP4 o en conexiones BIS / BBIS (= Enrutador ATN).
2.3 Detalles de las pilas de protocolo CNA
2.3.1 Detalles de la aplicación ISO CNA Protocol Stacks

(1) Esta pila de protocolos proporciona el protocolo de transferencia MTS X.400 (P1) y el protocolo
de acceso MTS X.400 (P3) para el ATSMHS con acceso LAN. Se basa en ISO y protocolos de Internet.
ISO TP0 se utiliza en la capa de transporte. Una asignación de ISO TP0 a TCP/IP se implementa por
medio de RFC 1006 y RFC 2126.

(2) Esta pila de protocolos proporciona el protocolo de transferencia MTS X.400 (P1) para el
ATSMHS con acceso WAN. Está basado en los protocolos ISO y UIT-T. TP0 se utiliza en la capa de
transporte. Se proporciona una correspondencia de transporte de ISO TP0 a UIT-T X.25. Debe
instalarse al menos una interfaz para cada tipo de interfaz serie que se va a utilizar.
(3) Esta pila de protocolos proporciona el Protocolo de Transferencia MTS X.400 (P1) para el
ATSMHS con acceso LAN, basado en protocolos ISO puros y utiliza ATN/TP4 en la capa de
transporte.

(4) Esta pila de protocolos proporciona el protocolo de transferencia MTS X.400 (P1) para el
ATSMHS con acceso WAN. Se basa en protocolos ISO y utiliza ATN/TP4 en la capa de transporte. El
mapeo de CLNP a X.25 se implementa de acuerdo con el Manual de Especificaciones Técnicas
Detalladas de la ATN usando Estándares y Protocolos ISO/OSI (Doc. 9880, Parte III de la OACI).
Debe instalarse al menos una interfaz para cada tipo de interfaz serie que se va a utilizar.

(5) Esta pila de protocolos proporciona el Protocolo de acceso a directorios X.500 (DAP) con acceso
de LAN para los usuarios del directorio que forman parte del servicio de gestión de mensajes ATS
extendido. Se basa en ISO y protocolos de Internet. ISO TP0 se utiliza en la capa de transporte. Una
asignación de ISO TP0 a TCP/IP se implementa por medio de RFC 1006 y RFC 2126.
6) Esta pila de protocolos proporciona el Protocolo de acceso a directorios (DAP), el Protocolo de
sistema de directorios (DSP) y el Protocolo de sombreado de información de directorio (DISP) para
el directorio ATN con acceso LAN. Se basa en ISO y protocolos de Internet. ISO TP0 se utiliza en la
capa de transporte. Una asignación de ISO TP0 a TCP/IP se implementa por medio de RFC 1006 y
RFC 2126. El agente de servicio de directorio (DSA) implementa esta pila de protocolo.

2.3.2 Detalles de la aplicación AFTN CNA Protocol Stacks

(1) Esta pila de protocolos proporciona un simple protocolo de bytes asíncronos con acceso WAN.
El protocolo de bytes asíncronos está destinado al intercambio de mensajes con terminales AFTN.
Los procedimientos AFTN apoyados por AIDA-NG se describen en el documento de enrutamiento
(ROUT).
(2) Esta pila de protocolos proporciona acceso WAN utilizando X.25 o HDLC para el intercambio de
mensajes AFTN. Los procedimientos AFTN apoyados por AIDA-NG se describen en el documento
de enrutamiento (ROUT).

(3) Esta pila de protocolos proporciona acceso LAN mediante TCP en la capa de transporte para el
intercambio de mensajes AFTN. Los procedimientos AFTN apoyados por AIDA-NG se describen en
el documento de enrutamiento (ROUT).

(4) Esta pila de protocolos proporciona acceso LAN mediante ATN/OSI-TP4 en la capa de transporte
para el intercambio de mensajes AFTN. Los procedimientos AFTN apoyados por AIDA-NG se
describen en el documento de enrutamiento (ROUT).
(5) Esta pila de protocolos proporciona el Protocolo simple de transferencia de correo (SMTP) para
el intercambio de mensajes AFTN. SMTP utiliza TCP en la capa de transporte.

2.3.3 Detalles de las pilas internas del protocolo CNA

(1) Esta pila de protocolos proporciona el protocolo de intercambio de mensajes (MEP) para el
intercambio transparente de datos binarios. MEP utiliza TCP en la capa de transporte.

(2) Esta pila de protocolos proporciona el protocolo SNMP (Simple Network Management Protocol)
para su uso por agentes SNMP. SNMP utiliza UDP en la capa de transporte.
(3) Esta pila de protocolos proporciona el Protocolo de impresión en Internet (IPP) para imprimir.
IPP utiliza TCP en la capa de transporte.

3 Interfaces de hardware
(1) El sistema proporciona el siguiente tipo de interfaces de hardware externas para el acceso LAN:
 Ethernet

(2) El sistema proporciona los siguientes tipos de interfaces de hardware externas para el acceso
WAN:
 X.21 para conexiones de alta velocidad
 V.24/X.21bis para conexiones de baja velocidad

(3) Una interfaz serie es de cualquiera de los tipos indicados en (2) y asignados al protocolo de Byte
Asíncrono o la combinación de protocolo HDLC y X.25. Ambos protocolos no se pueden utilizar
simultáneamente en una interfaz.

(4) Una configuración de sistema redundante, es decir, un sistema en una ubicación dada que
consiste en la Unidad A y la Unidad B proporciona estas interfaces en serie dos veces - una por
unidad. Durante el funcionamiento normal sólo se conecta una unidad a las líneas externas y se
procesan mensajes de tráfico y, por lo tanto, sólo se pueden utilizar las interfaces de esta unidad
conectada.

(5) Las características mencionadas anteriormente sólo se aplican a las interfaces del sistema para
la comunicación con socios externos, pero no para la comunicación interna entre los subsistemas
por medio de la LAN interna.

3.1 Ethernet
(1) Las interfaces LAN Ethernet admiten:
 10/100 / 1000BaseT, detección automática
 Conector RJ45
La disponibilidad de 1000BaseT (Gigabit Ethernet) depende del hardware seleccionado.

(2) En una interfaz LAN, se pueden parametrizar los tipos de protocolo TCP y UDP en la parte
superior de IP y ATN/ISO TP4 en la parte superior de CLNP. Estos protocolos se pueden utilizar
simultáneamente en una interfaz.

(3) La dirección MAC es proporcionada por el hardware de la tarjeta de interfaz. Opcionalmente, la

dirección MAC puede ser proporcionada por el software y sobrescrita en la tarjeta de interfaz.
(4) La interfaz Ethernet cumplirá con las siguientes normas y recomendaciones (consulte el
documento RulStd para más detalles):
 ISO/IEC 8802-3/IEEE 802.3

3.2 X.21 / V.11 para conexiones de alta velocidad

(1) El sistema admite interfaces X.21/V.11 para comunicaciones de alta velocidad.

(2) La interfaz X.21 cumplirá con los siguientes documentos y normas (ver el documento RulStd
para más detalles):
 UIT-T X.21
 UIT-T V.11
 UIT-T X.24
 ISO 4903
 CEPT NET-2 / L1

3.2.1 Definiciones de señal

(1) La Recomendación UIT-T X.24 define la función de las señales de interfaz utilizadas para X.21.

(2) Nota: La dirección de las señales se ve desde el equipo de terminación de datos (DTE).

3.2.2 Procedimientos X.21

(1) El sistema AIDA-NG sólo admite los procedimientos X.21 para las conexiones punto a punto
mediante líneas dedicadas.

(2) Cuando está listo para comunicarse, el DTE envía una señal "ON" en el circuito "C". Si recibe
una señal "ON" en el circuito "I", el DTE puede enviar cualquier dato en el circuito "T" y también
puede recibir los datos en el circuito "R".

(3) La siguiente tabla muestra los posibles estados de la interfaz X.21:

3.2.3 Asignación de pines
(1) La siguiente tabla muestra la asignación de los pines del conector Sub-D de 15 patillas de
acuerdo con la recomendación ISO 4903:

3.3 Interfaz V.24/X.21bis

(1) El sistema admite interfaces V.24/X.21bis para la comunicación a través de enlaces dedicados
utilizando módems de velocidad media (V-Series).
(2) La interfaz V.24 (X.21bis) estará en conformidad con los siguientes documentos y estándares
(ver detalles de la piel de RulStd):
 UIT-T V.24
 UIT-T V.28
 UIT-T X.21bis
 ISO 2110
 CEPT NET 2 L1

3.3.1 Definiciones de señal

(1) Para la transferencia síncrona de datos orientada a bit como HDLC/X.25 y para protocolos
asíncronos orientados a caracteres, el sistema soporta un subconjunto de señales V.24
especificadas en la recomendación ITU-T X.21bis. Estas señales se utilizan para comunicarse a
través de líneas arrendadas utilizando módems de velocidad media de tipo V.

(2) El DTE, si está listo para enviar y recibir datos, envía "ON" lógico en los circuitos DTR y RTS.
Espera recibir "ON" lógico en los circuitos DSR, CTS y DCD. Si se recibe "ON" lógico en todos estos
circuitos, al menos para un intervalo de tiempo dado (programable), el DTE puede enviar y recibir
datos desde/hacia el DCE conectado.

(3) Se admiten los siguientes circuitos:

(4) Nota: La dirección de las señales se ve desde el equipo de terminación de datos (DTE).

3.3.2 Asignación de pines

(1) En la siguiente tabla se muestra la asignación de pines del conector Sub-D de 25 patillas de
acuerdo con la Recomendación ISO 2110:
4 Protocolo BYTE asincrónico
(1) El protocolo de bytes asíncronos (BYTE) es un simple protocolo orientado a caracteres para
recibir y transmitir datos AFTN. Durante la transmisión, el controlador trabaja totalmente
transparente y transmite todos los caracteres de la aplicación. Se requiere una interfaz serie para
cada conexión de bytes asíncronos, ya que las interfaces serie no pueden ser compartidas entre las
conexiones de bytes asíncronas.

(2) El protocolo admite las siguientes características:

 Transmisión y recepción full duplex,
 Control automático de la línea del módem,
 Control de flujo por XON/XOFF (DC-1/DC-3),
 Detección de errores por bit de paridad,
 Formatos de mensajes ITA-2 e IA5,
 Detección de señales de inicio de mensaje (SOM) y de fin de mensaje (EOM) que faltan,
 Suministro de datos de diagnóstico.

(3) Cuando se transmiten o reciben mensajes AFTN, se admiten todos los procedimientos AFTN
requeridos y los formatos de mensaje IA5 e ITA-2 especificados en el Anexo 10 de la OACI. Para
obtener más información, consulte la sección correspondiente de este documento.

(4) Cuando se reciben datos asíncronos, se comprueba el final de un mensaje:

 Tiempo de espera de caracteres,
 Recepción de las señales de Inicio de Mensaje (SOM) y de Fin de Mensaje (EOM)
 Recepción de señal SOM repetida sin recepción de señal EOM,
  Señales SOM y EOM configurables por el usuario.

(5) Apoya los procedimientos de la línea TELEX de acuerdo con el Anexo-10 de la OACI:
 Arranque del motor,
 Señal de separación,
 Secuencia adicional de alimentación de cinta,
 Procedimiento de cinta pegado.

(6) Para obtener una lista detallada de los parámetros del protocolo, consulte el documento A
OpsGde.

4.1 Asincrónico BYTE LA Handling

(1) Cada interfaz de bytes asíncronos se asigna a un objeto LA. La transferencia de datos
asincrónica en sí es sin conexión. En la mayoría de los casos, los módems se utilizan para transferir
los datos a través de las líneas telefónicas arrendadas. Antes de la transferencia de datos, los
módems ejecutan un procedimiento de configuración de conexión. El estado de las líneas del
módem indica si la transferencia de datos al módem remoto es posible o no. El estado de conexión
de la conexión LA sigue el estado del módem de acuerdo con las siguientes reglas:

(2) El estado de las líneas de módem salientes sigue el modo del LA; No está influenciado por el
parámetro "Use Modem Lines".
5 Servicios de Protocolo de Transporte ATN / ISO TP4
(1) Desde el punto de vista del protocolo, el protocolo de transporte ISO Clase 0 (TP0) es un
subconjunto de la clase de protocolo de transporte ISO 4 (TP4). Sin embargo, ISO TP0 se
implementa como un módulo de software separado debido a ciertas restricciones en la
especificación ISO TP0.

(2) ATN/ISO TP4, ISO TP0 cumple con las siguientes normas y recomendaciones (ver el documento
RulStd para más detalles):
 ISO/IEC 8072
 ISO/IEC 8073 incluyendo el Anexo 2
 ISO/IEC ISP 10608-1
 Doc. 9880 de la OACI, Parte III

5.1 ISO TP0

(1) El protocolo ISO TP0 admite las siguientes características:
 Negociación del tamaño de la TPDU
 Servicios orientados a la conexión.

(2) ISO TP0 no tiene parámetros.

(3) El TP0 de ISO hace uso de TCP - por medio del protocolo RFC 1006 y RFC 2126 - o X.25 y
proporciona su servicio a la capa de sesión ISO. Las aplicaciones/transportistas no tienen acceso a
la ISO TP0.

5.2 ATN / ISO TP4

(1) El protocolo ISO TP4 admite las siguientes características:
 Tamaño TPDU negociable,
 Formatos normales y extendidos (negociables),
 Servicio acelerado de datos (negociable),
 Servicios orientados a la conexión,
 Números de sub-secuencia,
 Reducción del crédito,
 Uso de checksum negociable,
 Temporizadores de retransmisión autoajustables.

(2) ATN sobre X.25 (representado en la Figura 3) se realiza mapeando CLNP NSAP en X.25 VCs. Las
asignaciones forman parte de la configuración de AIDA-NG, se instalan en la puesta en marcha y se
pueden agregar, modificar y eliminar en tiempo de ejecución. Las conexiones de transporte a
diferentes socios (A, C) se asignan a diferentes VC (VC 1, VC 2), mientras que conexiones de
transporte con el mismo interlocutor (A, B) se asignan el mismo VC (VC 1).
(3) La ISO TP4 hace uso de ISO CLNP y proporciona su servicio a la Sesión ISO Capa y la AFTN
encargada de la aplicación.

(4) Para una lista detallada de los parámetros del protocolo, consulte el documento A-OpsGde.

6 IP
(1) El Protocolo de Internet (IP) cumple con las siguientes normas y recomendaciones (vea el
documento RulStd para más detalles):
 RFC 791
 RFC 792
 RFC 826
 RFC 903
 RFC 919
 RFC 922
 RFC 950
 RFC 1112
 RFC 1981
 RFC 2460
 RFC 3232 (obsoletes RFC 1700)
 RFC 4213
  RFC 4291
 RFC 4443
 RFC 4861
 RFC 4862

(2) El protocolo admite las siguientes características:

 Dirección IP de Clase A, B y C,
 Protocolo ARP y RARP,
 Direccionamiento IPv6.

(3) El protocolo de Internet hace uso de las interfaces LAN y proporciona su servicio a TCP y UDP,
que también son necesarios. Las aplicaciones no tienen acceso directo al protocolo de Internet.

(4) Para una lista detallada de los parámetros del protocolo, consulte el documento A-OpsGde.

7 UDP
(1) El protocolo UDP (User Datagram Protocol) cumple con las siguientes normas y
recomendaciones (consulte el documento RulStd para más detalles):
 RFC 768
 RFC 3232 (obsoletes RFC 1700)

(2) No hay parámetros para configurar UDP.

(3) UDP hace uso de la IP y proporciona su servicio a SNMP. Las aplicaciones / transportistas no
tienen acceso directo a UDP.

8 TCP
(1) El Protocolo de Control de Transmisión (TCP) cumple con las siguientes normas y
recomendaciones (consulte el documento RulStd para más detalles):
 RFC 793
 RFC 1122
 RFC 1323
 RFC 3232 (obsoletes RFC 1700)

(2) Para obtener una lista detallada de los parámetros del protocolo, consulte el documento A-
OpsGde.

9 RFC 1006 y RFC 2126

(1) RFC 1006 y RFC 2126 describen el mecanismo para permitir que los servicios de transporte ISO
(aquí TP0) para ejecutar en la parte superior de TCP sobre IPv4 o IPv6.

(2) RFC 2126 también define una serie de nuevas características, que no se proporcionan en RFC
1006.

(3) El mapeo TP0-to-TCP cumple con las siguientes normas y recomendaciones (vea el documento
RulStd para más detalles):
 RFC 1006
 RFC 2126 (actualizaciones RFC 1006)
(4) No hay parámetros para configurar para RFC 1006 y RFC 2126.

(5) RFC 1006 y RFC 2126 hacer uso de la TCP y proporcionar su servicio a ISO TP0.
Aplicaciones/promotores no tienen acceso directo a RFC 1006 o RFC 2126.

10 NTP
(1) El Network Time Protocol (NTP) cumple con las siguientes normas y recomendaciones (vea el
documento RulStd para más detalles):
 RFC 1305

(2) Si se configura, Network Time Protocol es utilizado por el sistema para sincronizar su tiempo
con un servidor NTP externo.

11 SNMP
(1) Para la administración de la red a través del protocolo simple de administración de red (SNMP),
el AIDA-NG implementa el MIB AIDA-NG específico de la empresa. El AIDA-NG utiliza el Protocolo
de Extensibilidad del Agente para proporcionar el MIB AIDA-NG a través del demonio Linux SNMP a
las estaciones de gestión SNMP. El MIB AIDA-NG cumple con las siguientes normas y
recomendaciones:
 RFC 1155
 RFC 1212
 RFC 2741

(2) El MIB AIDA-NG se proporciona como un documento separado.

(3) El MIB completo de AIDA-NG es proporcionado por el CSS operacional, no hay ninguna otra
plataforma que deba ser monitoreada para información relacionada con AIDA-NG.

(4) Además, el demonio SNMP de Linux en cada plataforma proporciona acceso a MIB-2 estándar y
MIBs específicas de hardware (por ejemplo, diferentes MIBs de compaq para supervisión SNMP de
servidores HP).

(5) Para más detalles sobre el demonio Linux SNMP, consulte su documentación.

12 IPP
(1) El protocolo de impresión por Internet (IPP) cumple con las siguientes normas y
recomendaciones:
 RFC 2911
 RFC 3196

(2) El sistema utiliza IPP para enviar trabajos de impresión a impresoras y consultar el estado de las
impresoras.
13 Servicio de manejo de mensajes ATS
(1) El Servicio de Manejo de Mensajes ATS (ATSMHS) proporciona un servicio genérico de mensajes
a través de la Red de Telecomunicaciones Aeronáuticas (ATN).

(2) La implementación del ATSMHS por AIDA-NG conecta a los usuarios al Sistema de Tratamiento
de Mensajes ATS (AMHS) e incluye una serie de protocolos, los cuales se dan aquí en detalle.

13.1 Normas y recomendaciones

(1) La implementación del ATSMHS considera una serie de normas y recomendaciones esbozadas
en las secciones subsiguientes que cubren la especificación de la OACI y las normas de base X.400,
incluidas las capas superiores OSI.

13.1.1 ATSMHS
(1) La ATSMHS ha sido especificada por la OACI en apoyo a las aplicaciones de mensajería en los
entornos de la ATN (segmento tierra-tierra). La lista a continuación detalla las normas pertinentes
aplicadas por el sistema en apoyo de la ATSMHS.
 Anexo 10, Volumen II de la OACI
 Doc. 9880 de la OACI, Subtítulo III
 Doc. 9739 de la OACI (retirado)

(2) Además, el sistema implementa los defectos aplicables que se han resuelto como se da en el
documento RulStd.

(3) Como resultado de la labor del estudio SPACE, se dispone de un plan maestro para la
implantación del ATSMHS en la región europea. El informe final del ESPACIO figura a continuación
(ver el documento RulStd para más detalles):
 ESPACIO/STNA/411/WPR/224, Versión 1.0 (02/12/2002)

13.1.2 Sistema de manejo de mensajes

(1) El ATSMHS hace referencia a las normas ISO/IEC MHS.

(2) Las normas del MHS habían sido liberadas inicialmente por el UIT-T (antiguo CCITT).
Posteriormente, la ISO/CEI adoptó las normas y perfeccionamientos del MHS, y las mejoras fueron
desarrolladas conjuntamente por la ISO/CEI y el UIT-T.

(3) En la lista que figura a continuación se enumeran las normas ISO/IEC y las Recomendaciones
UIT-T correspondientes que definen el MHS aplicable al servicio de gestión de mensajes ATS
ampliado:
 ISO/ IEC 10021-1: 2003 Véase también UIT-T X.400/F.400 (1999)
 ISO/ IEC10021-2: 2003 Véase también UIT-T X.402 (1999)
 ISO/ CEI 10021-4: 2003 Véase también UIT-T X.411 (1999)
 ISO / IEC10021-5: 1999 Véase también UIT-T X.413 (1999)
 ISO / IEC10021-6: 2003 Véase también UIT-T X.419 (1999)
 ISO / IEC10021-7: 2003 Véase también UIT-T X.420 (1999)

(4) El servicio básico de manejo de mensajes ATS hace referencia al conjunto de normas ISO / IEC
10021: 1990.
(5) Los Perfiles Estandarizados Internacionales ISO/IEC 10611 y 12062 subdividen la gama de
elementos de servicio definidos en la norma de base ISO/IEC 10021 en las categorías obligatorias y
optativas para los grados requeridos de los servicios MHS.

(6) En la siguiente lista se identifican los ISP de ISO/IEC aplicables al servicio de mensajes ATS
extendido:
 ISO /IEC ISP 10611-1: 2003
 ISO /IEC ISP 10611-2: 1994
 ISO /IEC ISP 10611-3: 2003
 ISO /IEC ISP 10611-4: 2003
 ISO/IEC ISP 10611-5: 2003
 ISO/IEC ISP 12062-1: 2003
 ISO/IEC ISP 12062-2: 2003
 ISO/IEC ISP 12062-3: 2003
 ISO/IEC ISP 12062-4: 2003
 ISO/IEC ISP 12062-5: 2003

(7) El Servicio de Manejo de Mensajes ATS Básico hace referencia a los ISP de ISO/IEC publicados
en 1994.

13.1.3 Servicio de aplicación ISO

(1) La comunicación entre dos entidades MHS ubicadas en diferentes sistemas está soportada por
los Elementos de Servicio de Aplicación genéricos (ASE), que a su vez utilizan el servicio de
presentación subyacente.

(2) La siguiente lista identifica las normas ISO/IEC pertinentes y las Recomendaciones UIT-T
correspondientes:
 ISO/CEI 8649: 1996 Véase también UIT-T X.217 (1992)
 ISO/CEI 8650-1: 1996 Véase también UIT-T X.227 (1994)
 ISO/CEI 9066-1: 1989 Véase también UIT-T X.218 (1988)
 ISO/CEI 9066-2: 1989 Véase también UIT-T X.228 (1988)
 ISO/CEI 9072-1: 1989 Véase también UIT-T X.219 (1988)
 ISO/IEC 9072-2: 1989 Véase también UIT-T X.229 (1988)

(3) ISO/IEC ISP 10611-2: 2003 especifica cómo se utilizarán estos ASEs para MHS'.

13.1.4 Servicio de presentación ISO

(1) El servicio de presentación, que hace uso del servicio de sesión subyacente, está definido por
las normas ISO/IEC y las Recomendaciones UIT-T correspondientes que se enumeran a
continuación:
 ISO/CEI 8822: 1994 Véase también UIT-T X.216 (1994)
 ISO/CEI 8823-1: 1994 Véase también UIT-T X.226 (1994)

(2) ISO / IEC ISP 10611-2: 2003 especifica cómo se utilizará el servicio de presentación para MHS.
13.1.5 Servicio de sesión ISO
(1) El servicio de sesión, que hace uso del servicio de transporte, está definido por las normas
ISO/IEC y las Recomendaciones UIT-T correspondientes que se enumeran a continuación:
 ISO/CEI 8326: 1994 Véase también UIT-T X.215 (1994)
 ISO/CEI 8327: 1994 Véase también UIT-T X.225 (1994)

(2) ISO/IEC ISP 10611-2: 2003 especifica cómo se utilizará el servicio de sesión para MHS'.

13.2 Funciones admitidas

(1) La implementación del ATSMHS incluye una serie de protocolos y características que se dan en
esta sección.

13.2.1 Nivel de Apoyo

(1) El Manual sobre Especificaciones Técnicas Detalladas de la ATN que utiliza Normas y Protocolos
ISO/OSI (Doc. 9880, Parte II de la OACI) especifica dos (2) niveles de servicio para la ATSMHS:
 Servicio básico de manejo de mensajes ATS y
 Servicio extendido de manejo de mensajes ATS.

(2) El servicio de manejo de mensajes ATS básico permite la transición de AFTN a AMHS
reduciendo la complejidad de X.400 a un mínimo.

(3) La implementación del ATSMHS es compatible con todos los protocolos, atributos y
procedimientos obligatorios especificados para el Servicio Básico de Tratamiento de Mensajes ATS.

(4) El Servicio de Manejo de Mensajes ATS Extendido es un super conjunto y por lo tanto es
compatible con el Servicio de Manejo de Mensajes ATS Básico. Introduce una serie de elementos
X.400 adicionales como transferencia de archivos y partes del cuerpo definidas bilateralmente,
mejoras de seguridad y uso del directorio.

(5) En apoyo del Servicio de Manejo de Mensajes ATS Extendido, la implementación de la ATSMHS
provee
 Protocolo de transferencia MTS (P1),
 Protocolo de acceso MTS (P3),
 Protocolo MS Access (P7) (no es parte de AIDA-NG pero puede ser proporcionado por
COMSOFT a través de una aplicación MS externa),
 Protocolo de acceso a directorios (DAP)
 Grupo Funcional de Uso del Directorio (DIR) IPM,
 Extensiones de encabezamiento de IPM: tiempo de autorización, origen-referencia,
precedencia-identificador de política y precedencia, según lo solicitado en la Parte II de la
OACI Doc. 9880,
 Transferencia de archivos y partes del cuerpo definidas bilateralmente.

(6) Además, el sistema admite elementos de servicio opcionales aparte del Servicio de Manejo de
Mensajes ATS Básico y Ampliado, tales como
 Indicación de receptor de copia oculta,
  La última designación de entrega, y
 Indicación de la solicitud de notificación de recibo.

13.2.2 Protocolo de transferencia MTS P1

(1) El MTA de AIDA-NG apoya el MTS Transfer Protocol comúnmente referido como P1 para el
intercambio de mensajes con MTAs adyacentes.

(2) De conformidad con la parte II de la Doc. 9880 de la OACI, la aplicación de P1 se basa en el

conjunto de normas de 1988. Y el contexto de la aplicación está limitado a MTS-Transfer para
soportar el atributo Common-Name en direcciones O/R, es decir, los contextos de aplicación MTS-
Transfer-Protocol y MTS-Transfer-Protocol-1984 no pueden ser soportados.

(3) En apoyo del Servicio de Manejo de Mensajes ATS Básico y Ampliado, el AIDA-NG implementa
todos los requisitos básicos de AMH11 y AMH22, y el Grupo Funcional de Lista de Distribución (DL)
para P1 (1988) como se detalla a continuación.

(4) La implementación del P1 establece y libera las asociaciones según sea necesario; Permanecen
establecidos siempre que se vayan a transferir mensajes. Además, la implementación soporta
asociaciones permanentes hasta la duración configurable. Se establecen asociaciones simultáneas
al mismo/MTA adyacente diferente según se requiera.

(5) El AIDA-NG limita el número de asociaciones simultáneas a cada MTA adyacente por
configuración. Los límites configurados para iniciadores y respondedores son controlados por
AIDA-NG. La liberación de asociaciones puede iniciarse por intervención del operador.

(6) Para el establecimiento de asociaciones y el intercambio de mensajes, el MTA apoya las

operaciones abstractas MTA-Bind, MTA-Unbind y Message-Transfer. La implementación
proporciona soporte para todos los elementos obligatorios de las operaciones mencionadas
anteriormente. La operación de enlace de MTA admite autenticación simple pero no autenticación
fuerte y contextos de seguridad.

(7) La implementación del P1 realiza el registro de tráfico para cada mensaje recibido o enviado. La
cantidad de información registrada excede los requisitos del Doc. 9880, Parte II de la OACI.

(8) Los errores transitorios, como los errores MTA-Bind y los fallos de transferencia, provocan un
evento y por lo tanto notifican al operador.

13.2.3 Protocolo de acceso MTS P3

(1) El MTA de AIDA-NG soporta el protocolo de acceso MTS comúnmente denominado P3 para el
intercambio de mensajes con agentes de usuario de mensajes ATS, almacenes de mensajes y otras
aplicaciones de mensajes ATS.

(2) De conformidad con la parte II de la OACI Doc. 9880, la implementación de P3 se basa en el

conjunto de normas de 1988 y respalda los contextos de aplicación, MTS-Access y MTS-Forced-
Access. Hay dos (2) modos disponibles: sólo MTS-Access y MTS-Access/MTS-Forced-Access.
(3) En apoyo del Servicio de Manejo de Mensajes ATS Extendido, el AIDA-NG implementa todos los
requisitos obligatorios de los ISPs AMH12 (MTS Access) y AMH 23 (IPM Requisitos para MTS
Access) para P3 (1988) como se detalla a continuación.

(4) En caso de que se use el contexto de aplicación MTS-Access, el Usuario MTS inicia el
establecimiento de la asociación. Una vez que se establece una asociación, se utiliza para las
operaciones de envío por el usuario MTS y para las operaciones de entrega por el MTA. El MTA
pone en cola mensajes destinados al usuario MTS hasta que el usuario MTS establece una
asociación.

(5) En caso de que se usen ambos contextos de aplicación, el usuario MTS y el MTA iniciarán el
establecimiento de asociación según sea necesario. Ambos usan las asociaciones que ha
establecido para las operaciones que inicia. El usuario MTS establece asociaciones para realizar
operaciones de envío. El MTA establece asociaciones para realizar las operaciones de entrega.

(6) Para el establecimiento de asociaciones y el intercambio de mensajes, el MTA apoya las

operaciones abstractas MTS-Bind, MTS-Unbind, Message-Submission, Probe-Submission, Message-
Delivery y Report-Delivery. La implementación proporciona soporte para todos los elementos
obligatorios de las operaciones mencionadas anteriormente. La operación MTS-bind admite
autenticación sencilla. Operaciones adicionales están disponibles por funciones de administración
en lugar de por protocolo.

(7) La administración de asociaciones, registro de tráfico y generación de eventos se aplica como se

especifica en 13.2.2 para el protocolo de transferencia MTS.

(8) CADAS puede conectarse mediante P3.

13.2.4 Pilas de protocolos de transporte

(1) En general, en los entornos MHS, la capa de sesión hace uso de los servicios de transporte OSI
orientados a la conexión. Por lo tanto, los servicios de transporte TCP y X.25 no se pueden utilizar
directamente. De acuerdo con la recomendación X.419 del UIT-T, es obligatorio el apoyo de la clase
de transporte 0 (TP0). El uso de la clase 0 refleja la intención inicial de la UIT de ejecutar MHS
sobre redes X.25. El soporte de otras clases es opcional. El ATSMHS se proporciona a través de la
implementación del MHS sobre los Servicios de Comunicación de Internet de ATN, que se basan en
la Clase de Transporte 4 (TP4).

(2) Para obtener más información, consulte la sección correspondiente de los respectivos servicios
ISO de capa inferior.

(3) Los protocolos de capa de transporte TP0 y TP4 están soportados.

(4) TP0 ofrece las variantes del protocolo

 TP0/RFC-1006 + RFC-2126/TCP/LAN y
 TP0/X.25/WAN.

(5) TP4 ofrece las variantes del protocolo

 ATN (TP4)/CLNP/LAN y
 ATN (TP4)/CLNP/X.25/WAN.
13.3 Parámetros globales de ATSMHS
(1) La mayoría de los parámetros del protocolo de transferencia MTS X.400 se configuran
individualmente para cada combinación de MTA y pila de protocolos adyacentes (X.400 LA), de
modo que todas las combinaciones pueden tener diferentes conjuntos de parámetros. Consulte la
especificación de X.400 LAs a continuación para obtener detalles sobre estos parámetros.

(2) Los parámetros globales de todo el sistema se enumeran en la Tabla 14.

(3) Para más detalles consulte el documento A-OpsGde.

13.4 Diagnóstico y estadística de ATSMHS

(1) Se proporcionan diagnósticos y estadísticas acumulativos. Los diagnósticos y estadísticas
recopilan información sobre mensajes de datos X.400, informes y sondeos enviados y recibidos.
(2) Detalles sobre el diagnóstico y las estadísticas véase el documento A-OpsGde.

13.5 X.400 LAs

(1) Dos (2) tipos de X.400 LAs están disponibles dependiendo del protocolo en vigor.
 X.400 P1 LA y
 X.400 P3 LA.

(2) Un (1) X.400 P1 LA representa un interlocutor externo en el AMHS distribuido alcanzable por
medio de P1. En términos de X.400, un X400 P1 LA es un MTA adyacente que se comunica a través
de una de las pilas de protocolo de transporte de capa inferior dadas disponibles.

(3) El sistema funciona con cuatro PX especiales de X.400 P1 incorporadas. Una X.400 P1 LA está
disponible para:
 Intercambio local de mensajes con la Unidad de Transferencia y Control de Mensajes de la
Puerta de enlace AFTN/AMHS,
 Intercambio local de mensajes con la Unidad de Presentación y Entrega de AMHS,
 El destino de los mensajes no entregados y el origen de los informes generados, y
 Destino y fuente en caso de expansión de las listas de distribución.

(4) Una X.400 P3 LA representa un proceso de aplicación de mensajes MS, ATS o ATS accesible por
medio de P3. En términos de X.400, un X.400 P3 LA es un usuario MTS.

13.5.1 Parámetros
(1) Para cada socio de comunicación X.400 se debe configurar una X.400 P1 LA o una X.400 P3 LA.

La Tabla 15 detalla los parámetros X.400 LA relacionados con el tipo de mensaje y el protocolo.

(2) Los parámetros marcados con asterisco (*) en la Tabla 15 se definen una sola vez para todos los
usuarios de MTS que utilizan el mismo sistema de servidor MTS (como CADAS-ATS).
13.5.2 Diagnóstico y estadística
(1) Para cada X.400 LA, se proporcionan diagnósticos y estadísticas que muestran información
sobre mensajes de datos X.400, informes y sondas enviados y recibidos.

(2) Detalles sobre el diagnóstico y las estadísticas véase el documento A-OpsGde.

14 AFTN
(1) Esta sección describe las funciones y parámetros disponibles para la comunicación AFTN
heredada (sobre BYTE, X.25, TCP).

14.1 Legacy LA Parámetro

(1) Los parámetros del convertidor AFTN/verificador se describen en la parte de reenvío de
mensajes de este documento (sección 15.1).

(2) Para cada Legacy LA es posible especificar parámetros de verificación de canal y parámetros
relacionados con el manejo de SVC.

14.1.1 Parámetro de comprobación de canal

(1) El control de Channel Check sólo se aplica a los protocolos de comunicación heredados. Para
cada LA genera mensajes de verificación de canal salientes y supervisa los intervalos de recepción
de mensajes. La tabla siguiente especifica los parámetros configurables para el manejo de Chequeo
de Canal.

14.1.2 Mensajes de prueba AFTN

(1) Es posible recibir y transmitir mensajes de prueba AFTN a través de cualquier AFTN LA
heredado. Para ello, el AFTN LA correspondiente debe ajustarse en modo "Test", tanto para ambas
direcciones como para Recepción o Transmisión solamente. Entonces, es posible el intercambio de
mensajes de prueba AFTN.
(2) Los mensajes de prueba AFTN no se enrutan mediante ninguna tabla de enrutamiento, sino
que se transmiten directamente a través de la correspondiente AFTN LA. Los mensajes recibidos
mientras el LA está en modo de prueba no se reenvían.

(3) Todos los mensajes de prueba AFTN recibidos o transmitidos se registran en el RSS.

14.1.3 Parámetro de manejo de mensajes SVC

(1) Se reciben SVC QTA MIS y SVC QTA RPT recibidos si están configurados para ser procesados
automáticamente. Si es así, el mensaje se enruta al Auto-Repeat-Handler, que inicia el
procedimiento necesario (es decir, recuperando y repitiendo los mensajes perdidos). De lo
contrario, el mensaje se encamina normalmente, al igual que todos los demás mensajes SVC.

Tenga en cuenta que además de los parámetros LA, el receptor del mensaje también debe coincidir
con una entrada en el AFTN SVC Routing Indicator Parameters para ser manejado
automáticamente.

(2) En varios casos de error, el sistema - si está habilitado para hacerlo - genera mensajes SVC con
un texto de mensaje definido por OACI. La generación de los siguientes mensajes SVC puede
parametrizarse por AL:
(3) El manejo del número de secuencia de canal (CSN) sólo se aplica a los protocolos de
comunicación heredados. Para cada LA se basa en un CSN para la transmisión y un CSN para la
recepción de mensajes y comprende las siguientes funciones:

(4) Cuando se transmite un mensaje, el CSN actual para la transmisión se inserta en el mensaje. A
continuación, se incrementa el CSN. A medianoche, el CSN se establece en el valor inicial '1'.

(5) Si el número de secuencia excede 999 (9) dentro del mismo día (antes de la medianoche), se
realiza un envolvente a 000 (0).

15 Comprobación y conversión de mensajes

15.1 Verificación y conversión de mensajes AFTN
(1) Puede configurarse una multitud de parámetros de comprobación y conversión de mensajes
para cada socio de comunicación externo. Algunos parámetros se aplican a los flujos de mensajes
entrantes y salientes, mientras que otros parámetros se aplican sólo a un flujo de mensajes. La
tabla siguiente detalla los parámetros del formato de mensaje AFTN, la mayoría de ellos aplicables
a ambos flujos de mensajes, y configurables por AFTN LA.

(2) Dependiendo del formato de mensaje configurado, se usan los caracteres de control IA5-SOH
habituales SOH (01), STX (02), ETX (03) y VT (0B) para dar formato a mensajes o imprimir el control
IA5-ZCZC Se utilizan caracteres (por ejemplo, ZCZC como señal de inicio de mensaje) o se utilizan
caracteres codificados en ITA-2 (BAUDOT). Los mensajes codificados en el conjunto de caracteres
ITA2 se convertirán en IA5 antes del análisis AFTN. En la conversión de ITA2 a IA5, el carácter ITA2
NULL (cinta no perforada) se eliminará. LTRS y FIGS serán evaluados y eliminados después. No hay
restricción sobre el número o secuencia de caracteres NULL, LTRS o FIGS.

(3) El formato de mensaje configurado se aplica a los mensajes AFTN salientes para ser reenviados
a un interlocutor externo. Para los mensajes AFTN entrantes recibidos de un interlocutor externo,
los mensajes deben cumplir con el formato de mensaje configurado. De lo contrario, los mensajes
son rechazados y deben ser corregidos por el operador primero antes de que puedan ser
procesados por el sistema. Si el mensaje cumple con el formato definido, se convertirá en el
formato configurado para el mensaje saliente, p. Un mensaje con formato IA5 SOH entrante se
convierte en un mensaje saliente de formato ITA-2 (Baudot).

(4) Es posible definir cómo el sistema manejará los mensajes entrantes y/o salientes cuyos textos
contengan caracteres fuera del conjunto de caracteres AFTN estándar: El sistema acepta/envía
tales mensajes o convierte los caracteres que no están en línea con El formato de mensaje o, en lo
que respecta a los mensajes entrantes, rechazar el mensaje. Al convertir, el sistema sustituye los
caracteres minúsculos por sus equivalentes mayúsculas; No se permitirán símbolos de puntuación
(! "$ #% & *; <> @ [\] ^ _` {|} ~) Se convertirá (mapeo de caracteres configurable).

(5) El sistema acepta todos los mensajes AFTN entrantes siempre y cuando su alineación contenga
exactamente un LF y al menos un CR. Sin embargo, es posible restringir este ajuste para que la
alineación de los mensajes entrantes deba leer "CR-LF" o "CR-CR-LF". Estas dos (2) posibilidades de
alineación también pueden aplicarse a los mensajes AFTN salientes.

(6) También se debe configurar el envolvimiento de las líneas largas. Si está activada, todas las
líneas de texto que contienen 70 caracteres y más en un mensaje AFTN saliente se envuelven
después del carácter 69º.

(7) En cada mensaje de formato AFTN IA5 entrante recibido de un socio de comunicación externo,
pueden realizarse ciertas operaciones de conversión. La conversión/eliminación tiene lugar
inmediatamente después de la recepción del mensaje. Los siguientes parámetros de conversión
pueden configurarse para cada AFTN LA:
(8) El sistema puede configurarse para eliminar todos los caracteres de control no necesarios para
los mensajes AFTN del mensaje entrante; Los cuales son NUL (00), EOT (04), ENQ (05), ACK (06), BS
(08), HT (09), FF (0C), SO (0E), SI (0F) ), DC1 (11), DC2 (12), DC3 (13), DC4 (14), NAK (15), SYN (16),
ETB (17), CAN (18), EM (19) ), ESC (1B), FS (1C), GS (1D), RS (1E) y US (1F); Es decir, todos los
caracteres de control (00 a 1F) excepto para SOH, STX, ETX, BEL, LF, VT y CR. El carácter DEL (7F)
siempre se eliminará del mensaje durante esta conversión.

(9) Si una o varias de las operaciones de sustitución y eliminación basadas en caracteres descritas
anteriormente están desactivadas, ciertos caracteres no válidos pueden permanecer dentro del
mensaje AFTN entrante. Si quedan caracteres no válidos, el mensaje se rechaza y debe ser
corregido por el operador primero antes de que el sistema pueda procesar el mensaje.

(10) Después de que se ha comprobado un mensaje y de que se han convertido los caracteres
como se ha descrito anteriormente, todavía puede contener caracteres ASCII imprimibles, p. Los
caracteres de control IA5 habituales y las líneas de cualquier longitud. La tabla siguiente ilustra el
conjunto de caracteres que puede contener el mensaje (tenga en cuenta que hasta ahora sólo se
ha ajustado el conjunto de caracteres), pueden ser necesarias más verificaciones de mensajes y
operaciones de corrección, por ejemplo para corregir un indicador de prioridad corrupto que
contiene un dígito).

(11) Para los mensajes AFTN entrantes recibidos de un interlocutor externo, se pueden configurar
ciertas operaciones de comprobación y corrección de mensajes. Los siguientes parámetros
controlan el rechazo/corrección de un mensaje entrante en función de los errores encontrados
durante el análisis del mensaje. Si se detecta el error descrito y el parámetro correspondiente se
establece en Rechazar, el mensaje entrante se rechazará y se enviará a la cola REJECTED. Si el
parámetro está ajustado a Forward, el mensaje será reenviado, es decir, el error será ignorado o
corregido.
(12) Con "Errores en el texto del mensaje" ajustado en "Reenviar", el sistema sustituye los
caracteres de control no permitidos en el texto del mensaje por un signo de interrogación; El
último carácter de una secuencia de caracteres no permitida en el texto del mensaje también se
sustituye por un signo de interrogación. Esto permite el procesamiento automático incluso de
mensajes que contengan otro mensaje.

(13) La tabla siguiente ilustra el conjunto de caracteres que puede estar contenido en un mensaje
AFTN saliente para ser reenviado a un socio de comunicación externo, después de que el conjunto
de caracteres estaba restringido de acuerdo con todas las operaciones de conversión de mensajes
descritas anteriormente.
(14) Se permiten espacios de arrastre y de avance dentro de cada línea del encabezado del
mensaje. Entre los elementos de cada línea del encabezado del mensaje, cualquier número de
espacios es aceptable. Además, puede omitirse la separación por un carácter de espacio entre
ZCZC y el CID, y entre el tiempo de presentación y el originador.

(15) Otros parámetros son:

(16) El modo de descarte de basura activado hace que el sistema se niegue a aceptar un flujo de
datos recibido sin un carácter de control "SOH", "STX" o "ETX"; En consecuencia, el mensaje será
descartado (sólo relevante para el formato de mensaje IA-5).

(17) El sistema puede configurarse para enviar automáticamente un mensaje de servicio para
acusar la recepción de un mensaje “SS” transmitido a un determinado LA.

15.2 Comprobación y conversión de mensajes de AMHS

(1) Los mensajes AMHS deben ajustarse a la última especificación dada en el Doc. 9880, Parte II de
la OACI (Manual sobre Especificaciones Técnicas Detalladas para la ATN utilizando Normas y
Protocolos IS /OSI, Aplicaciones Ground-Ground) y eventuales defectos resueltos.

(2) Los mensajes X.400 recibidos de la aplicación de mensajes X.400 se comprueban en

cumplimiento antes de ser reenviados a la aplicación de mensajes AMHS o convertidos en
mensajes AFTN, respectivamente. El indicador de prioridad de elementos y el tiempo de
presentación del mensaje ATS deben estar disponibles. Sus valores se contrastan con el posible
rango de valores. El elemento indicador de prioridad, tiempo de presentación, información de
encabezamiento opcional y el Texto-Mensaje ATS se convierten según lo especificado en la Parte II
de la OACI Doc. 9980.

(3) Se puede configurar una cierta tolerancia en la comprobación de mensajes como se indica en la
Tabla 25

(4) La verificación de mensajes AMHS es realizada por el MTCU y el ASDU. La conversión de

mensajes AMHS es realizada por el MTCU.

16 Centro de gestión de mensajería ATS (AMC)

(1) El Centro de Gestión de Mensajería ATS (AMC) gestiona los datos relacionados con AFS en
apoyo de la AFTN, CIDIN y AMHS, y exporta varios datos para descarga manual. La descarga de los
archivos AMC en formato CSV está disponible en el sitio web de AMC
https://www.eurocontrol.int/amc.

(2) AIDA-NG puede importar las siguientes tablas de archivos AMC CSV:
 Tabla de búsqueda de dominios de administración (Registro MD de AMHS)
 Tabla de búsqueda de CAAS (Direccionamiento Intra MD)
 Tabla de búsqueda de direcciones de usuario (direccionamiento intra-MD)

(3) El formato de archivo AMC CSV se especifica en el Documento de la OACI EUR Doc. 021
(Manual de gestión de mensajería ATS), apéndice D.

17 AFTN sobre TCP/IP

(1) Esta sección proporciona información detallada sobre el intercambio de mensajes AFTN a través
de TCP/IP.

17.1 Configuración
(1) Con el fin de intercambiar mensajes AFTN a través de TCP/IP, es necesaria la configuración de
los LAs correspondientes. La tabla siguiente detalla los parámetros esenciales específicos del
protocolo configurables para tales LAs. Además de estos parámetros, también son configurables
los parámetros AFTN habituales (por ejemplo, parámetros de comprobación de mensajes).
(2) Los parámetros listados en la tabla anterior se detallan en las secciones siguientes.

17.2 Establecimiento de conexión activa

(1) En este modo de operación, AIDA-NG inicia la conexión TCP con el interlocutor de
comunicación, dirigiéndose al interlocutor utilizando el Puerto TCP Remoto y la Dirección IP
Remota configurada.

(2) La información de dirección local de la conexión TCP comprende un puerto TCP local arbitrario
y la dirección IP local asignada a la interfaz de LAN local.

17.3 Establecimiento de conexión pasiva

(1) En este modo de operación, AIDA-NG escucha en la Interfaz de LAN Local y el Puerto TCP Local
configurado para establecimiento de conexión TCP por el interlocutor.

(2) Si el puerto TCP remoto y/o la dirección IP remota están configurados, AIDA-NG rechaza las
conexiones TCP de otros puertos y/o direcciones.

17.4 Indicadores de marco

(1) Al intercambiar mensajes AFTN a través de TCP/IP, las aplicaciones de mensajería AFTN que
utilizan TCP/IP deben asegurar el ensamblaje y el re-ensamblado adecuados de los mensajes AFTN,
ya que TCP/IP no proporciona ningún medio para estructurar datos de aplicación en unidades
lógicas separadas. En otras palabras, los mensajes AFTN transmitidos por una aplicación de
mensajería AFTN se presentan como un flujo de bytes continuos a la aplicación de mensajería
AFTN receptora.

(2) AIDA-NG puede separar los mensajes AFTN usando una multitud de los llamados indicadores de
trama. El indicador de cuadro más sencillo es obviamente el uso de los caracteres de control SOH y
ETX. AIDA-NG soporta los siguientes indicadores de marco:
 IA5-SOH El inicio y el final de cada mensaje AFTN están indicados por los caracteres de
control SOH y ETX
 LW4 Cada mensaje AFTN está precedido por una palabra de longitud de cuatro bytes
  LW2 Cada mensaje AFTN está precedido por una palabra de longitud de dos bytes
 SPL-ACK Cada mensaje AFTN está precedido por una palabra de longitud de cuatro bytes
Cada mensaje AFTN es confirmado por el mensaje SPL-ACK
 MEP Cada mensaje comienza con un encabezado MEP de longitud fija
 EMEP Cada mensaje comienza con un encabezado MEP de longitud fija
 CPX Cada mensaje comienza con el encabezado CPX de tres bytes
 GWDI Cada mensaje comienza con el encabezado GWDI de ocho octetos

17.4.1 Indicador de trama IA5_SOH

Manejo de errores para el indicador de trama IA5-SOH

17.4.2 Indicadores de marco de palabra de longitud LW4/LW2

(1) Se puede configurar si se agrega el tamaño del indicador de trama (2 o 4 bytes) a la longitud
indicada y si se utiliza el pequeño endian (LW2 => 12; LW4 => 1234) o big endian (LW2 => 21; LW4
=> 4321).
(2) A pesar de que la longitud del indicador de trama es configurable, considerando la longitud
potencial de los mensajes AFTN, siempre se debe usar una longitud de indicador de trama de
cuatro bytes.

(3) Dependiendo del tipo de endian, el indicador de cuadro codifica la longitud del mensaje AFTN
siguiente en orden pequeño endian o big endian. Utilizando el orden big endian, un mensaje AFTN
con una longitud de 400 bytes es precedido por el siguiente indicador de trama (representación
binaria):

17.4.2.2 Indicador de trama LW4

(1) AIDA-NG toma los primeros cuatro bytes recibidos después del establecimiento de conexión
como longitud de mensaje N. Después de leer N Bytes, los siguientes cuatro bytes se toman como
el indicador de trama del mensaje siguiente y así sucesivamente.

Manejo de errores para el indicador de trama LW4

17.4.2.3 Indicador de trama LW2

Manejo de errores para el indicador de trama LW2

17.4.3 Indicador de trama SPL-ACK

Descripción del protocolo Simple-ACK
SPL-ACK utiliza una palabra de cuatro (4) bytes big endian longitud. Las PDU pueden contener
mensajes AFTN o confirmaciones. Los agradecimientos se usan para garantizar una transmisión
segura de mensajes de almacenamiento y envío. El tamaño de ventana para el acuse de recibo es
1. Los bytes de datos transferidos en un acuse de recibo SPL-ACK se especifican en el LA (1 a 10
bytes). Cada mensaje recibido que tiene más de diez (10) caracteres se maneja como un mensaje
de datos. Se descartan mensajes de diez (10) caracteres y más cortos y que no contienen los datos
ACK configurados; Se genera un evento apropiado.
La figura siguiente ilustra la secuencia de indicadores de trama y PDU en la corriente de bytes
transportada por TCP/IP.

Las figuras 2 y 3 muestran cómo un mensaje AFTN de 400 bytes y un acuse de recibo de 3 bytes
(contenido ASCII "ACK") se formatearán en el flujo de datos.
Los caracteres de control SOH, STX y ETX se consideran parte del mensaje AFTN.

Reconocimiento Simple-ACK
Al intercambiar mensajes AFTN a través de SPL-ACK, AIDA-NG utiliza un mensaje de confirmación
configurable para confirmar la recepción. El mensaje de acuse puede tener como máximo 10 bytes.
Al enviar mensajes, AIDA-NG enviará exactamente un mensaje, y luego esperar hasta que reciba un
acuse de recibo. Si la conexión se libera antes de que AIDA-NG reciba un acuse de recibo, el
mensaje se mantendrá pendiente y se repetirá.

Al recibir un mensaje AFTN, almacenará el mensaje y después de que el mensaje se almacene

permanentemente, envía un acuse de recibo.
Tenga en cuenta que a pesar de enviar con el tamaño de ventana 1, AIDA-NG puede recibir
mensajes múltiples. En este caso, cada confirmación confirma el mensaje más antiguo que todavía
no se ha confirmado.
17.4.4 Indicador de marco MEP
Descripción del Protocolo MEP
El MEP usa un encabezado MEP de dieciséis (16) bytes de longitud fija; Cada PDU de datos es
reconocida.

El tamaño de ventana se puede configurar en el rango 1-9. MEP Versión 2 agrega suma de
comprobación CRC. MEP se debe utilizar para conexiones AIDA PassThrough
17.4.5 Indicador de trama EMEP
Descripción general del Protocolo EMEP
EMEP utiliza un encabezado EMEP de dieciséis(16) bytes de longitud fija; Cada PDU de datos es
reconocida. El tamaño de ventana se puede configurar en el rango 1 - 9. La información de estado
de una conexión asociada se puede transferir a través de la conexión EMEP. Las órdenes de control
de flujo dirigidas a la conexión asociada pueden ser transportadas a través de la conexión EMEP.

17.4.6 Indicador de trama CPX

Descripción general del protocolo CPX
CPX utiliza un encabezado CPX de tres bytes de longitud fija; El primer byte de la cabecera es la
versión de CPX, se fija la fijación a 0x0. Los próximos dos bytes de la cabecera son la palabra de
longitud de big endian, la longitud de cabecera de CPX tres se agrega al valor de longitud de
palabra (lw).
17.4.7 Indicador de trama GWDI
Visión general del protocolo GWDI
GWDI utiliza un encabezado GWDI de ocho bytes de longitud fija;

La palabra de longitud está en orden de bytes de red. Cada PDU de datos debe ser reconocida por
el interlocutor receptor basándose en el número de secuencia GWDI. La ventana de confirmación
está limitada por el rango de números de secuencia GWDI solamente. Para las PDU de datos no
válidas recibidas (por ejemplo, sobre largo de mensaje) se puede enviar un reconocimiento
negativo (NAK). En la instalación de la conexión hay una autentificación a través del nombre de
canal GWDI especificado. Un GWDI establecido es controlado permanentemente por el latido del
corazón GWDI. El intervalo de las sondas de latido se especifica con el 'Probe Period Time', el valor
predeterminado es 20 segundos

17.5 Liberación de conexión

(1) La conexión permanece establecida hasta que se produzcan las siguientes condiciones:
 El interlocutor comunica la conexión,
 La retransmisión de datos falla varias veces,
 El AIDA-NG TCP/IP LA es inhabilitado por el operador, o
 El CSS operativo deja de estar operativo (por ejemplo, debido a una conmutación)