grupo de expertos sobre comunicaciones …±ol/acp_1_dp... · proyecto de sarps sobre el conjunto...

S07-2246

ACP/1-DP3 15/5/07

GRUPO DE EXPERTOS SOBRE COMUNICACIONES AERONÁUTICAS (ACP)

PRIMERA REUNIÓN

Montreal, 10 - 18 de mayo de 2007

Cuestión 3 del orden del día:

3.1

3.2

3.3 3.4

Examen de los SARPS y textos de orientación sobre la Red de telecomunicaciones aeronáuticas (ATN), incluidos los siguientes: Proyecto de SARPS sobre el conjunto de protocolos de Internet en la ATN (ATN/IPS) Reestructuración de los SARPS sobre la interconexión de sistemas abiertos en la ATN (ATN/OSI) Proyecto de Manual sobre las especificaciones técnicas detalladas para ATN/IPS Proyecto de Manual sobre las especificaciones técnicas detalladas para la ATN basadas en las normas y protocolos OSI de la ISO

PROYECTO DE INFORME

ACP/1-DP/3 (Proyecto)

Informe sobre la cuestión 3 del orden del día 3-1

Cuestión 3 del orden del día:

Examen de los SARPS y textos de orientación sobre la Red de telecomunicaciones aeronáuticas (ATN)

3.1. INTRODUCCIÓN 3.1 En el marco de esta cuestión del orden del día, la reunión examinó el informe del Grupo de trabajo N (WG-N). 3.1.1 Una de las tareas principales del WG-N fue considerar la introducción del conjunto de protocolos de Internet (IPS) en la red de telecomunicaciones aeronáuticas (ATN/IPS). Esta actividad incluyó una revisión de las normas y métodos recomendados (SARPS) para la ATN, con el objeto de alinearlos con las disposiciones de la Resolución A35-14 de la Asamblea y las directrices para la preparación de textos de SARPS sobre sistemas complejos de la Comisión de Aeronavegación. El Grupo de trabajo WG-N abordó además las posibles soluciones con respecto a movilidad en la ATN/IPS y protección en la ATN. Además, el WG-N preparó textos que actualizan las especificaciones técnicas detalladas para la ATN según el Manual de especificaciones técnicas detalladas de la red de telecomunicaciones aeronáuticas (Doc 9880) y el Manual completo sobre la red de telecomunicaciones aeronáuticas (ATN) (Doc 9739). 3.1.3 Desde la primera reunión del Grupo de trabajo plenario del ACP (21-29 de junio de 2005, Montreal, Canadá), el WG-N ha celebrado dos reuniones: — 3-7 de julio de 2006 (Bruselas, Bélgica); y — 24 de enero – 2 de febrero de 2007 (Bangkok, Tailandia). 3.1.3.1 El ponente del WG-N fue el Sr. J.-Y. Piram, Francia. 3.1.3.2 En la labor del WG-N se ha contado con el respaldo de los subgrupos de trabajo siguientes: — Subgrupo de trabajo N1 (Ponente: K. Kitchens, Estados Unidos); — 7-10 de noviembre de 2005 (Montreal, Canadá); — 30 de enero – 3 de febrero de 2006 (Bangkok, Tailandia); — 27-31 de marzo de 2006 (Malmo, Suecia); — 15-19 de mayo de 2006 (Copenhage, Dinamarca); — 26-30 de junio de 2006 (Bruselas, Bélgica); — 25-29 de septiembre de 2006 (Montreal, Canadá); — 13-17 de noviembre de 2006 (Montreal, Canadá); — 22-26 de enero de 2007 (Bangkok, Tailandia);

ACP/1-DP/3

3-2 Informe sobre la cuestión 3 del orden del día — 16-20 de abril de 2007 (Montreal Canadá); — Subgrupo de trabajo N2 (Ponente: F. Picard, Francia); — 25-26 de enero de 2007 (Bangkok, Tailandia); — Subgrupo de trabajo N3 (Ponente: J-M. Vacher, Francia); — 25-26 de enero de 2007 (Bangkok, Tailandia); — Subgrupo de trabajo N4 (Ponente: T. McParland, Estados Unidos); — 7-10 de noviembre de 2005 (Montreal, Canadá); — 30 de enero – 3 de febrero de 2006 (Bangkok, Tailandia); — 7-10 de marzo de 2006 (Atlantic City, Estados Unidos); — 27-31 de marzo de 2006 (Malmo, Suecia); — 25-29 de septiembre de 2006 (Montreal, Canadá); — 13-17 de noviembre de 2006 (Montreal, Canadá); — 22-26 de enero de 2007 (Bangkok, Tailandia); y — 16-20 de abril de 2007 (Montreal, Canadá). 3.1.3.3 El grupo de expertos tomó nota con reconocimiento de que el intenso calendario de reuniones de los Subgrupos N1 y N4 contribuyó a la finalización oportuna de las complejas tareas que debían abordar. 3.1.4 Según lo acordado en la primera reunión del Grupo de trabajo plenario del ACP, las tareas del WG-N son las que se mencionan en los párrafos siguientes. 3.1.4.1 Preparar textos técnicos de la OACI para interfuncionamiento y aplicaciones aeronáuticas aire-tierra y tierra-tierra para completar las funciones y mejoramientos siguientes en relación con los SARPS o disposiciones técnicas existentes: a) preparar SARPS y disposiciones técnicas para la utilización del IPS en las

comunicaciones tierra-tierra CNS/ATM; b) estudiar y resolver los problemas técnicos, que incluyen movilidad, protección y

repercusión en las aplicaciones, para poder utilizar el IPS en las comunicaciones aeroterrestres CNS/ATM;

c) dependiendo del resultado de las tareas mencionadas, preparar textos de la OACI

pertinentes para la introducción del IPS en respaldo de las aplicaciones aeroterrestres del futuro;

ACP/1-DP/3

Informe sobre la cuestión 3 del orden del día 3-3 d) evaluar los requisitos para incorporar nuevas funciones como multidifusión y cifrado,

y preparar y validar disposiciones técnicas apropiadas, según sea necesario, en el contexto IPS;

e) supervisar la preparación de nuevos requisitos operacionales y de nuevas subredes

fijas o móviles, y rendir informe; f) ... g) perfeccionar las aplicaciones actuales, incluyendo la preparación de disposiciones

técnicas para PM-vigilancia dependiente automática (ADS) y PM-servicio de información de vuelo (FIS), y la actualización de las aplicaciones de comunicaciones por enlace de datos controlador-piloto (CPDLC) y comunicación de datos entre instalaciones ATS (AIDC) de conformidad con las conclusiones de la primera reunión del Grupo de expertos sobre enlaces de datos operacionales (OPLINKP), 12-23 de septiembre de 2005;

h) preparar disposiciones técnicas para la gestión de sistemas con directorio de

mejoramiento IPS y servicios de seguridad; i) participar, en coordinación con el WG-M y mediante las actividades del Subgrupo de

mantenimiento (AMSG) de la ATN (subgrupo conjunto del WG-M y WG-N), para el mantenimiento de los actuales SARPS, disposiciones técnicas y textos de orientación sobre la ATN; y

j) definir la repercusión institucional del interfuncionamiento aeronáutico en el

rendimiento de las tareas anteriores, considerando la aplicación de normas establecidas y maduras.

3.1.5 La reunión procedió con la consideración de los resultados alcanzados, según se refleja en los párrafos siguientes. 3.2 PROYECTO DE SARPS SOBRE ATN/IPS 3.2.1 En 2005, en la primera reunión de Grupo del trabajo plenario del ACP, se convino en que la utilización del IPS en la ATN era factible y en la Recomendación 2/3 de esa reunión se pidió que un órgano pertinente de la OACI preparara SARPS y textos de orientación para la introducción del IPS en la ATN. La Comisión de Aeronavegación estuvo de acuerdo con esta recomendación y pidió al ACP que preparara el texto necesario. 3.2.2 La reunión tomó nota de que se proponía que la introducción de los SARPS sobre ATN/IPS en el Anexo 10 — Telecomunicaciones aeronáuticas se efectuara de manera que se considerara la implementación de la ATN basada en normas OSI e IPS. La implementación de la ATN/IPS requeriría asegurar el interfuncionamiento con la red de telecomunicaciones fijas aeronáuticas (ATFN), la red OACI común de intercambio de datos (CIDIN) y las redes ATN/OSI. Estos aspectos de interfuncionamiento deben aclararse más a fondo en el Manual sobre especificaciones técnicas detalladas para la ATN/IPS, actualmente en preparación.

ACP/1-DP/3

3-4 Informe sobre la cuestión 3 del orden del día 3.2.3 Las enmiendas propuestas de los SARPS ATN introducen elementos del IPS en el Anexo 10 que son esenciales para una ATN basada en IPS mediante referencias a las normas preparadas por el Equipo de trabajo de ingeniería de Internet (IETF) con el auspicio de la Sociedad Internet (ISOC). Estas normas son normas abiertas y están disponibles. De conformidad con estas normas IETF, se han introducido disposiciones para TCP, UDP e IPv6 BGP1. 3.2.4 La introducción del IPS en la ATN reconoce los sistemas ya implantados y el uso continuo, de conformidad con los SARPS relativos a la ATN/OSI. También prevé el interfuncionamiento con las redes AFTN y CIDIN. 3.2.5 Se examinaron además los SARPS actuales relativos a la ATN teniendo en cuenta la Resolución A35-14 de la Asamblea. En las enmiendas, se propone reestructurar los SARPS, transformándolos en SARPS funcionales y de alto nivel; sólo se incluyen textos técnicos cuando son necesarios para el interfuncionamiento de la ATN a escala mundial. Se incorporan especificaciones técnicas detalladas en el Doc 9880 para la ATN/OSI y, en un nuevo manual, para la ATN/IPS. La reunión tomó nota de que el manual sobre la ATN/IPS estará terminado para finales de 2008. Los requisitos para la implementación de la ATN/OSI y de la ATN/IPS se basarán en acuerdos regionales de navegación aérea. 3.2.6 Las propuestas de enmienda del Anexo 10, Volumen III — Sistemas de comunicaciones, Parte I — Sistemas de comunicaciones de datos digitales, Capítulos 1 y 3, figuran en el Apéndice A del presente informe. El Apéndice B contiene la “versión limpia” (sin marcas de enmienda) de esos SARPS, con todas las enmiendas propuestas en el Apéndice A ya “aceptadas”, y se incluye (en inglés únicamente) para facilitar su lectura. 3.2.7 Por consiguiente, la reunión formuló la siguiente recomendación:

RSPP

Recomendación 3/1 —

Enmienda del Anexo 10, Volumen III, Parte I, Capítulo 1 (Definiciones) y Capítulo 3 (Red de telecomunicaciones aeronáuticas)

Que el Anexo 10, Volumen III, Parte I, Capítulos 1 y 3, se enmiende como se indica en el Apéndice A del Informe sobre la cuestión 3 del orden del día.

3.3 MANUAL SOBRE LAS ESPECIFICACIONES TÉCNICAS DETALLADAS PARA LA ATN/IPS 3.3.1 Paralelamente a la elaboración de SARPS para la red de telecomunicaciones aeronáuticas con utilización del IPS, el WG-N redactó el Manual sobre las especificaciones técnicas detalladas para la ATN/IPS. Si bien los SARPS relativos a la ATN/IPS (que figuran en el Apéndice A del Informe sobre la cuestión 3 del orden del día) incluyen disposiciones tanto para la parte tierra-tierra como para la parte aire-tierra de la ATN, actualmente el manual sólo contiene textos relativos a la parte tierra-tierra de la ATN. 3.3.2 El manual debe considerarse conjuntamente con los SARPS pertinentes para una ATN basada en IPS, como se indica en el Apéndice A del Informe sobre la cuestión 3 del orden del día. En él se definen los protocolos y servicios de comunicaciones de datos requeridos para la implementación de

1 Protocolo de control de transmisión (TCP), Protocolo de datagrama de usuario (UDP), Protocolo de Internet versión 6 (IPv6),

Protocolo de pasarela de frontera (BGP).

ACP/1-DP/3

Informe sobre la cuestión 3 del orden del día 3-5 la ATN/IPS. El manual proporciona información detallada sobre los requisitos relativos a la capa de red, a la capa de transporte y a la seguridad de la capa de red. 3.3.3 Se acordó que el manual mencionado constituye la base para facilitar la implementación de la ATN/IPS. Si bien la reunión reconoció que todavía se están introduciendo cambios para mejorar el manual, debería dársele la mayor difusión posible entre los Estados contratantes y en la industria de la aviación para suministrar información relativa a los proyectos de SARPS para una ATN/IPS y para facilitar su pronta aplicación. 3.3.4 En el Apéndice C del Informe sobre la cuestión 3 del orden del día, se presenta el Manual sobre las especificaciones técnicas detalladas para la ATN/IPS. La reunión formuló la siguiente Recomendación: Recomendación 3/2 — Manual sobre las especificaciones técnicas detalladas

para la ATN/IPS Que el Manual sobre las especificaciones técnicas detalladas para la ATN/IPS,

que figura en el Apéndice C del Informe sobre la cuestión 3 del orden del día, se distribuya a los Estados contratantes de la OACI y a las organizaciones internacionales pertinentes para suministrarles información y orientación relativa a los proyectos de SARPS para la ATN/IPS y facilitar su pronta aplicación.

3.3.5 Se informó a la reunión que los subgrupos de trabajo N1 y N4 están preparando especificaciones técnicas detalladas y/o textos de orientación adicionales sobre los aspectos que se indican a continuación para facilitar la implementación de la ATN/IPS: a) compatibilidad e interfuncionamiento de la ATN/IPS con la ATN/OSI, la AFTN y

CIDIN; b) elaboración de planes de numeración para el direccionamiento IPv6, incluyendo

aeronaves; c) elaboración del plan de numeración para sistemas autónomos (p. ej., una red

ATN/IPS dentro de un país); d) calidad de servicio (QoS); e) el uso de diversas aplicaciones, como por ejemplo: CPDLS, AIDC, y el servicio de

tratamiento de mensajes ATS (ATSMHS), en la ATN/IPS; y f) introducción de soluciones de seguridad que puedan utilizarse tanto en los enlaces

aire-tierra como tierra-tierra. 3.3.6 Se prevé que las especificaciones técnicas detalladas para la ATN/IPS, incluidos los enlaces aire-tierra, estarán terminadas para finales de 2008. Esas especificaciones servirán de complemento de los SARPS para la ATN/IPS, cuya entrada en vigor se prevé para noviembre de 2008.

ACP/1-DP/3

3-6 Informe sobre la cuestión 3 del orden del día 3.4 MOVILIDAD 3.4.1 El WG-N continuó trabajando en el estudio de factibilidad, en cumplimiento de la Recomendación 2/3 de la primera reunión del Grupo de trabajo plenario del ACP, y concluyó que el uso del IPS en los enlaces aire-tierra era factible. Esa conclusión se confirmó al conocerse el resultado de un estudio de EUROCONTROL. De conformidad con la Recomendación 2/3 c) de la primera reunión del Grupo de trabajo plenario del ACP, el WG-N siguió estudiando las disposiciones necesarias para los SARPS y textos de orientación relativos a los enlaces aire-tierra de la ATN/IPS. Los resultados del estudio del WG-N figuran en el “Análisis de las potenciales soluciones de movilidad de la ATN/IPS”, incluido en el Apéndice D del Informe sobre la cuestión 3 del orden del día. 3.4.2 El análisis de las potenciales soluciones de movilidad de la ATN/IPS demuestra que se encuentran disponibles varias soluciones que permitirían la movilidad y seguridad necesarias para los enlaces aire-tierra en la ATN. Actualmente, se han identificado 10 soluciones, cada una de las cuales presenta ventajas particulares en cuanto a las características de la implementación técnica de los posibles enfoques para la movilidad IPS. 3.4.3 El ACP continuará trabajando en los aspectos de movilidad de los enlaces aire-tierra, concentrándose en las soluciones de movilidad identificadas, con miras a elaborar especificaciones técnicas detalladas que cumplan con los requisitos de movilidad aire-tierra. Actualmente, no se prevén enmiendas de los SARPS relativos a la ATN/IPS propuestos para su incorporación en el Anexo 10. El objetivo de esta actividad consiste en identificar un conjunto mínimo de disposiciones sobre movilidad en la ATN. Eventualmente, será necesario que la o las soluciones de movilidad seleccionada(s) garantice(n) la movilidad a escala mundial de los enlaces aire-tierra. La solución seleccionada debería formar parte de las soluciones de movilidad homologadas por la Sociedad Internet (ISOC) y por el Equipo de Trabajo de Ingeniería Internet (IETF). 3.4.4 Por otra parte, la reunión señaló que sería preferible convergir en una única solución de movilidad, que podría aumentarse mediante soluciones de movilidad adicionales compatibles. También debería validarse debidamente la solución seleccionada. Al seleccionar la o las soluciones de movilidad, debería tenerse en cuenta la tara que deba añadirse a los mensajes. 3.4.5 El análisis de las potenciales soluciones de movilidad, que se utilizará en la labor ulterior a ese respecto, según lo convenido por la reunión, figura en el Apéndice D del Informe sobre la cuestión 3 del orden del día. 3.4.6 La reunión analizó la propuesta de estudiar el uso de los servicios basados en XML/Web en el entorno de mensajes de control del tránsito aéreo (ATC) de próxima generación. Se acordó tomar en cuenta esa propuesta como parte de las actividades que ya se están realizando para elaborar textos de la OACI para una ATN basada en IPS. 3.4.7 La reunión tomó nota de que se está actualizando el texto del Manual de disposiciones técnicas de la red de telecomunicaciones aeronáuticas (ATN)(Doc 9705), que la OACI reeditará en el Manual de especificaciones técnicas detalladas para la ATN utilizando normas y protocolos (ISO/OSI) (Doc 9880), dividido en partes. La Parte I (CM y CPDLC) y la Parte IIA (AIDC) del Doc 9880 ya se aprobaron y publicaron en el sitio web del ACP para que se las pueda consultar hasta que la OACI haya publicado oficialmente el documento. Se actualizaron los textos pertinentes al ATSMHS y los servicios de comunicaciones de las capas superiores (ULCS), y se prevé publicarlos próximamente. El texto del Doc 9880 actualiza y reemplaza los textos pertinentes del Doc 9705. La publicación de esos textos en el Doc 9880 está en manos de la Secretaría, dado que no están previstos cambios ulteriores de los textos

ACP/1-DP/3

Informe sobre la cuestión 3 del orden del día 3-7 técnicos, y se espera que, con la ayuda de los miembros del grupo de expertos, se complete dentro de los próximos 12 meses. El Manual completo sobre la Red de comunicaciones aeronáuticas (ATN) (Doc 9739) se está actualizando de la misma forma. 3.4.8 Con respecto a la publicación de las actualizaciones del modo ADS-C protegido, la reunión señaló que, dado que actualmente se están modificando los requisitos operacionales de la ADS-C, es improbable que se disponga de actualizaciones ulteriores en el corto plazo. Es necesario que el grupo de trabajo M analice esas actualizaciones oportunamente. No obstante, con respecto al modo FIS protegido, la reunión consideró que, si bien cabe prever que se introduzcan algunas modificaciones en sus requisitos, su publicación no debería demorarse.

— — — — — — — —

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-1

APÉNDICE A

PROPUESTA DE ENMIENDA

DE LAS NORMAS Y MÉTODOS RECOMENDADOS INTERNACIONALES

TELECOMUNICACIONES AERONÁUTICAS

ANEXO 10 AL CONVENIO SOBRE AVIACIÓN CIVIL INTERNACIONAL

VOLUMEN III

(SISTEMAS DE COMUNICACIONES)

PARTE I — SISTEMAS DE COMUNICACIONES DE DATOS DIGITALES CAPÍTULO 1 Y CAPÍTULO 3

NOTA SOBRE LA PRESENTACIÓN DE LA PROPUESTA DE ENMIENDA

El texto de la enmienda se presenta de modo que el texto que ha de suprimirse aparece

tachado y el texto nuevo se destaca con sombreado, como se ilustra a continuación: 1. el texto que ha de suprimirse aparece tachado

texto que ha de suprimirse

2. el nuevo texto que ha de insertarse se destaca

con sombreado

nuevo texto que ha de insertarse

3. el texto que ha de suprimirse aparece tachadoy

a continuación aparece el nuevo texto que se destaca con sombreado

nuevo texto que ha de sustituir al actual

ACP/1-DP/3

A3-2 Apéndice A del informe sobre la cuestión 3 del orden del día

NORMAS Y MÉTODOS RECOMENDADOS INTERNACIONALES

TELECOMUNICACIONES AERONÁUTICAS

ANEXO 10

AL CONVENIO SOBRE AVIACIÓN CIVIL INTERNACIONAL

VOLUMEN III (SISTEMAS DE COMUNICACIONES)

PARTE I — SISTEMAS DE COMUNICACIONES DE DATOS DIGITALES

CAPÍTULO 1. DEFINICIONES

Nota 1.— Todas las referencias al “Reglamento de Radiocomunicaciones” se refieren al Reglamento de Radiocomunicaciones publicado por la Unión Internacional de Telecomunicaciones (UIT). El Reglamento de Radiocomunicaciones se enmienda de tiempo en tiempo en el marco de las decisiones adoptadas en las actas finales de las Conferencias Mundiales de Radiocomunicaciones celebradas normalmente cada dos a tres años. También se dispone de más información sobre los procesos seguidos por la UIT en el uso de las frecuencias para los sistemas radioeléctricos aeronáuticos en el Manual relativo a las necesidades de la aviación civil en materia de espectro de radiofrecuencias, que incluye la declaración de las políticas aprobadas por la OACI (Doc 9718). Nota 2.— Esta parte del Anexo 10 comprende normas y métodos recomendados sobre ciertas clases de equipo para sistemas de comunicaciones. Si bien los Estados contratantes determinan la necesidad de instalaciones específicas de acuerdo con las condiciones prescritas en la norma o método recomendado pertinente, el Consejo examina periódicamente la necesidad de instalaciones específicas y expone a los Estados contratantes interesados la opinión y recomendaciones de la OACI, basándose generalmente en las recomendaciones de las conferencias regionales de navegación aérea (Doc 8144, Instrucciones para las reuniones regionales de navegación aérea y reglamento interno de las mismas). Nota 3.— En este capítulo figuran las definiciones generales que corresponden a los sistemas de comunicaciones. Las definiciones específicas de cada uno de los sistemas que se incluyen en este volumen figuran en los capítulos pertinentes. Nota 4.— En el Anexo 10, Volumen I, 2.9 y Volumen I, Adjunto F, respectivamente, figura texto acerca de la fuente secundaria de energía y texto de orientación relativo a la confiabilidad y disponibilidad de los sistemas de comunicaciones. Acceso múltiple por división en el tiempo (TDMA). Un plan de acceso múltiple basado en la utilización

en tiempo compartido de un canal RF que utiliza: 1) intervalos de tiempo discretos contiguos como el recurso fundamental compartido; y 2) un conjunto de protocolos operacionales que permiten a los usuarios interactuar con una estación principal de control para obtener acceso al canal.

Aloha a intervalos. Estrategia de acceso aleatorio por la cual múltiples usuarios tienen acceso

independiente al mismo canal de comunicaciones, pero cada comunicación debe limitarse a un intervalo de tiempo fijo. Todos los usuarios conocen la estructura común de intervalos de tiempo, pero no existe ningún otro tipo de coordinación entre ellos.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-3 Circuito virtual conmutado (SVC). El procedimiento de gestión de circuitos primarios proporcionado

mediante el protocolo ISO 8208. Los recursos de red se asignan dinámicamente cuando son necesarios y se liberan cuando ya no son necesarios.

Comunicaciones aeronáuticas administrativas (AAC). Comunicaciones necesarias para el intercambio

de mensajes aeronáuticos administrativos (Véase Anexo 10, Volumen II, párrafo 4.4.1.1.7). Comunicaciones por enlace de datos controlador-piloto(CPDLC). Comunicación entre el controlador y

el piloto por medio de enlace de datos para las comunicaciones ATC. (Véase Anexo 11, Capítulo 1 – Definiciones).

Control de las operaciones aeronáuticas (AOC). Comunicaciones necesarias para ejercer la autoridad

respecto a la iniciación, continuación, desviación o terminación de un vuelo por razones de seguridad operacional, regularidad y eficiencia (Véase Anexo 6, Parte I, Capítulo 1 – Definiciones).

Corrección de errores sin canal de retorno (FEC). Proceso que consiste en añadir información

redundante a la señal transmitida de manera que sea posible corregir, en el receptor, los errores en que se haya incurridos durante la transmisión.

De extremo a extremo. Indicación perteneciente o relativa a la totalidad de un trayecto de

comunicaciones, ordinariamente desde (1) la interfaz entre la fuente de información y el sistema de comunicaciones en el extremo de transmisión hasta (2) la interfaz entre el sistema de comunicaciones y el usuario de la información, o el procesador, o la aplicación, en el extremo de recepción.

Desviación Doppler. Desviación de frecuencia observada en un receptor debido al movimiento relativo de

transmisor y receptor. Dirección de aeronave. Combinación única de 24 bits que puede asignarse a una aeronave para los fines

de las comunicaciones aeroterrestres, la navegación y la vigilancia. Enlace digital en VHF (VDL). Subred móvil constituyente de la red de telecomunicaciones aeronáuticas

(ATN), que funciona en la banda de frecuencias VHF móviles aeronáuticas. Además, el VDL puede proporcionar funciones ajenas a la ATN, tales como, por ejemplo, la voz digitalizada.

Estación terrena de aeronave (AES). Estación terrena móvil del servicio móvil aeronáutico por satélite

instalada a bordo de una aeronave (véase también “GES”). Estación terrena de tierra (GES). Estación terrena del servicio fijo por satélite o, en algunos casos, del

servicio móvil aeronáutico por satélite, instalada en tierra en un punto fijo especificado para proporcionar un enlace de alimentación al servicio móvil aeronáutico por satélite.

Nota.— Esta definición se utiliza en el Reglamento de Radiocomunicaciones de la UIT bajo el título de “Estación terrena aeronáutica”. La definición de “GES” que figura en este documento para ser empleada en los SARPS, se adjuntaincluye para distinguirla claramente entre GES yde la estación terrena de aeronave (AES), que es una estación del servicio móvil a bordo de una aeronave. Modo circuito. Configuración de la red de comunicaciones que confiere la apariencia a la aplicación de

un trayecto de transmisión especializado.

ACP/1-DP/3

A3-4 Apéndice A del informe sobre la cuestión 3 del orden del día Multiplex por distribución en el tiempo (TDM). Estrategia de compartición de canal por la que se

establece una secuencia en tiempo, en el mismo canal, de paquetes de información provenientes de la misma fuente pero hacia destinos distintos.

Paquete. La unidad básica de transferencia de datos entre dispositivos de comunicaciones dentro de la

capa de red. Potencia isótropa radiada equivalente (p.i.r.e). Producto de la potencia suministrada a la antena

transmisora y la ganancia de antena en una dirección determinada en relación con una antena isótropa (ganancia absoluta o isótropa).

Precisión de velocidad de transmisión por canal. Precisión relativa del reloj con el que se sincronizan

los bits transmitidos por canal. Por ejemplo, a una velocidad de transmisión por canal de 1,2 kbits/s, un error máximo de una parte en 106 implica que el error máximo admisible en el reloj es de ±1,2 x 10-3 Hz.

Proporción de errores en los bits (BER). Número de errores en los bits en una muestra dividido por el

número total de bits de la muestra, obtenido generalmente como promedio de numerosas muestras del mismo tipo.

Protocolo de capa de paquete (PLP). Protocolo para establecer y mantener la conexión entre entidades de

nivel par en la capa de red y para transferir paquetes de datos entre ellas. En el contexto de esta norma, la expresión se refiere al protocolo definido por la Norma ISO 8208 según se aplica en este documento.

Punto-a-punto. Perteneciente o relativo a la interconexión de dos dispositivos, particularmente

instrumentos de usuario de extremo. Trayecto de comunicaciones de servicio cuyo objetivo consiste en conectar dos usuarios de extremo discretos; por contraposición al servicio de radiodifusión o al servicio multipunto.

Red de telecomunicaciones aeronáuticas (ATN). Arquitectura mundial entre redes que permite el

interfuncionamientointercambio de datos digitales de las subredes de datos de tierra, aire/-tierra y aviónica, mediante la adopción de servicios y protocolos con equipo común de interfaz basados en el modelo de referencia para la interconexión de sistemas abiertos (OSI) de la Organización Internacional de Normalización (ISO)para la seguridad operacional de la navegación aérea y el funcionamiento regular, eficiente y económico de los servicios de tránsito aéreo.

Relación de energía por símbolo a densidad de ruido (ES / N0). Relación entre el promedio de energía

transmitida por símbolo de canal y el promedio de potencia de ruido en una anchura de banda de 1 Hz, habitualmente expresada en dB. Para la A-BPSK y A-QPSK, un símbolo de canal se refiere a un bit de canal.

Relación de ganancia a temperatura de ruido. La relación, habitualmente expresada en dB/K, entre la

ganancia de antena y el ruido en la salida del receptor del subsistema de antena. El ruido se expresa como la temperatura a la que debe elevarse una resistencia de un ohmio para producir la misma densidad de potencia de ruido.

Relación de portadora a densidad de ruido (C/N0). Relación entre la potencia total de portadora y la

potencia promedio de ruido en una anchura de banda de 1 Hz, habitualmente expresada en dBHz.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-5 Relación de portadora a trayectos múltiples (C/M). Relación entre la potencia de portadora recibida

directamente, es decir, sin reflexión, y la potencia de trayectos múltiples, es decir, la potencia de portadora recibida por reflexión.

Retardo de tránsito. En los sistemas de datos por paquete, el tiempo transcurrido entre una petición de

transmisión de un paquete de ensamblado de datos y una indicación en el extremo de recepción de que el correspondiente paquete ha sido recibido y de que está preparado para ser utilizado o transferido.

Servicio automático de información terminal (ATIS). Suministro automático de información de rutina,

actualizada, a las aeronaves que llegan y que salen, durante las 24 horas o un período inferior determinado. (Véase Anexo 11, Capítulo 1 – Definiciones).

Servicio automático de información terminal por enlace de datos (ATIS-D). Suministro del ATIS

mediante enlace de datos. Servicio automático de información terminal-voz (ATIS-voz). Suministro del ATIS mediante

radiodifusiones orales continuas y repetitivas. Servicio de información de vuelo (FIS). Servicio cuya finalidad es aconsejar y facilitar información útil

para la realización segura y eficiente de los vuelos. (Véase Anexo 11, Capítulo 1 – Definiciones). Servicio de información de vuelo por enlace de datos (D-FIS). El suministro de FIS por enlace de datos

(Véase Anexo 11, Capítulo 1 – Definiciones). Servicio de tránsito aéreo. Expresión genérica que se aplica, según el caso, a los servicios de información

de vuelo, alerta, asesoramiento de tránsito aéreo, control de tránsito aéreo (servicios de control de área, control de aproximación o control de aeródromo) (Véase Anexo 11, Capítulo 1 – Definiciones).

Subred en Modo S. Uno de los medios para ejecutar un intercambio de datos digitales mediante el uso de

interrogadores y transpondedores del radar secundario de vigilancia (SSR) en Modo S, de conformidad con protocolos definidos.

Usuario de extremo. Fuente primera o usuario último de la información. Velocidad de transmisión por canal. Velocidad a la cual se transmiten los bits por canal RF. Entre estos

bits se incluyen aquellos de alineación de trama y de corrección de errores, así como los de información. En la transmisión en ráfagas, la velocidad de transmisión por canal se refiere a la velocidad instantánea de ráfaga durante el período de la ráfaga.

Vigilancia dependiente automática — Contrato (ADS-C). Medio por el cual el sistema terrestre y la

aeronave intercambiarán, mediante enlace de datos, los términos de un acuerdo ADS, especificándose en qué condiciones se iniciarían informes ADS-C y qué datos contendrían dichos informes. (Véase, Anexo 11, Capítulo 1 – Definiciones).

_____________________

ACP/1-DP/3


CAPÍTULO 3. RED DE TELECOMUNICACIONES AERONÁUTICAS

Nota 1.— Las especificaciones técnicas detalladas para las aplicaciones ATN/OSI figuran en el documento titulado “Manual of Detailed Technical Specifications for the ATN using ISO/OSI standards and protocols”(Manual de especificaciones técnicas detalladas para la ATN utilizando normas y protocolos ISO/OSI) (Doc. 9880). Nota 2.— Las especificaciones técnicas detalladas para las aplicaciones ATN/IPS figuran en el documento titulado “Manual of Detailed Technical Specifications for the ATN using IPS standards and protocols”(Manual de especificaciones técnicas detalladas para la ATN utilizando normas y protocolos IPS) (Doc. XXX xxxx) [en preparación].

3.1 DEFINICIONES Nota 1.— Las definiciones siguientes fueron extraídas de ISO/IEC 7498-1. Tecnología de información — Interconexión de sistemas abiertos — Modelo de referencia básico [Referencia: UIT-T Rec. X.200 (1994)] y del Doc 9705 de la OACI — Manual de disposiciones técnicas de la red de telecomunicaciones aeronáuticas (ATN). Nota 2.— El Doc 9705 de la OACI ha evolucionado de una edición a la siguiente. En cada subvolumen de este documento se indica la evolución de las disposiciones entre ediciones sucesivas. Nota 3.— En el Subvolumen I del Doc 9705 de la OACI figura un diagrama con las referencias recíprocas entre las versiones (capacidad de soporte lógico integrada) y las ediciones (disposiciones técnicas). Aplicación. Uso final de un sistema de información, por contraposición con el sistema en sí mismo. Aplicación ADS. Aplicación ATN que proporciona datos ADS de la aeronave a las dependencias ATS para fines de vigilancia. Aplicación AIDC. Aplicación ATN para el intercambio de información de control de tránsito aéreo (ATC) entre dependencias ATS (ATSU) a efectos de notificación y coordinación de los vuelos y para las transferencias de control, comunicaciones, datos de vigilancia y datos generales. Aplicación ATIS. Aplicación FIS que presta apoyo al ATIS-D. Aplicación CPDLC. Aplicación ATN que proporciona un medio de comunicación de datos ATC entre dependencias ATS de control, receptora o subsiguiente y la aeronave mediante subredes aire-tierra y tierra-tierra, en la que se observa la fraseología de la OACI empleada para las comunicaciones orales ATC vigentes. Aplicación de gestión de contexto (CM). Aplicación ATN que proporciona un servicio de conexión para la entrada inicial de la aeronave en la ATN y un directorio de todas las demás aplicaciones de enlace de datos de a bordo. También incluye funciones para transmitir direcciones entre dependencias ATS.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-7 Nota.— Gestión de contexto es también una expresión reconocida que se utiliza en la capa de presentación OSI. El uso OSI y el uso en la ATN nada tienen en común. Aplicación FIS. Aplicación ATN que proporciona a las aeronaves información y avisos útiles para la realización segura y eficaz de los vuelos. Aplicación METAR. Aplicación FIS que presta apoyo al METAR-D. Autenticación. Procedimiento utilizado para asegurar la identidad de una persona, usuario o entidad de red. Clase de ATSC. El parámetro clase de ATSC permite al usuario ATSC especificar la calidad de servicio que se espera de los datos ofrecidos. El valor de la clase de ATSC se especifica en términos de retardo de tránsito ATN de extremo a extremo con una probabilidad del 95%. Comunicación aeronáutica administrativa (AAC). Comunicación utilizada por las empresas explotadoras aeronáuticas para los aspectos comerciales de explotación de sus vuelos y servicios de transporte. Esta comunicación se utiliza con diversos fines, tales como vuelos y transporte terrestre, reservas, despliegue de tripulaciones y aeronaves o cualesquiera otros fines logísticos que permitan mantener o mejorar la eficiencia de operación global de los vuelos. Capacidad de iniciación de enlace de datos (DLIC). Aplicación de enlace de datos que proporciona la función de intercambiar las direcciones, nombres y números de versión que sean necesarios para iniciar aplicaciones de enlace de datos. (Véase el Doc 4444). Comunicación de datos entre instalaciones ATS (AIDC). Intercambio automatizado de datos entre dependencias de servicios de tránsito aéreo, particularmente en materia de coordinación y transferencia de vuelos.en apoyo de la notificación y coordinación de vuelos, así como de la transferencia de control y de comunicación. Comunicaciones aeronáuticas de los pasajeros (APC). Comunicaciones de voz y datos relacionadas con servicios ajenos a la seguridad que se ofrecen a los pasajeros y a los miembros de la tripulación para comunicaciones privadas. Comunicaciones ATS (ATSC). Comunicación relacionada con los servicios de tránsito aéreo, comprendido el control de tránsito aéreo, la información aeronáutica y meteorológica, la notificación de posición y los servicios relacionados con la seguridad y regularidad de los vuelos. En esta comunicación intervienen una o varias administraciones de servicios de tránsito aéreo. Estos términos se utilizan con fines de administración de direcciones. Comunicaciones entre centros (ICC). ICC es una comunicación de datos entre dependencias ATS en apoyo de los servicios ATS, tales como notificación, coordinación, transferencia de control, planificación de los vuelos, gestión del espacio aéreo y gestión de afluencia del tránsito aéreo. Comunicaciones por enlace de datos controlador-piloto (CPDLC). Un medio de comunicación entre el piloto y el controlador utilizando enlace de datos para las comunicaciones ATC. Control de las operaciones aeronáuticas (AOC). Comunicaciones necesarias para ejercer la autoridad respecto a la iniciación, continuación, desviación o terminación de un vuelo, por razones de seguridad, regularidad y eficiencia.

ACP/1-DP/3

A3-8 Apéndice A del informe sobre la cuestión 3 del orden del día De extremo a extremo. Perteneciente o relativo a un trayecto completo de comunicaciones, ordinariamente desde (1) la interfaz entre la fuente de información y el sistema de comunicaciones en el extremo de transmisión hasta (2) la interfaz entre el sistema de comunicaciones y el usuario o procesador de la información, o la aplicación en el extremo receptor. Dependencia ATS (ATSU). Expresión genérica que se aplica, según el caso, a una dependencia de control de tránsito aéreo, a un centro de información de vuelo o a una oficina de notificación de los servicios de tránsito aéreo. Entidad. Elemento activo de cualquier capa que puede ser una entidad de soporte lógico (por ejemplo un proceso) o una entidad de soporte físico [por ejemplo una microplaqueta inteligente de I/O (entrada/salida)]. Entidad de aplicación (AE). Una AE representa un conjunto de capacidades de comunicación OSI de un proceso de aplicación en particular. (Véase ISO Doc 9545 para mayores detalles)Parte de un proceso de aplicación relacionado con las comunicaciones en el entorno OSI. Los aspectos de un proceso de aplicación que deben tenerse en cuenta con fines OSI están representados por una o varias AE. Gestión de configuración. Elemento de gestión de sistemas ATN que permite a los administradores cambiar la configuración de elementos distantes. Gestión de contabilidad. Elemento de gestión de sistemas ATN para vigilar y limitar el uso que de los recursos de la red hacen los usuarios. Gestión de eficacia. Elemento de gestión de sistemas ATN para vigilar y evaluar la eficacia de los sistemas. Gestión de fallas. Elemento de gestión de sistemas ATN para detectar, aislar y corregir problemas. Gestión de seguridad. Elemento de gestión de sistemas ATN para control de acceso, autenticación e integridad de los datos. Gestión de sistemas ATN (SM). Grupo de elementos para controlar, coordinar y supervisar los recursos que permiten establecer las comunicaciones en el entorno ATN. Entre estos elementos se incluyen la gestión de fallas, la gestión de contabilidad, la gestión de configuración, la gestión de eficacia y la gestión de seguridad. Información de aplicación. Se refiere a los nombres de aplicación (p. ej., calificadores de AE como ADS y CPC), los números de versión y las direcciones (TSAP largo o breve, según se requiera) de cada aplicación. Integridad de los datos. Probabilidad de que los datos no han sido alterados ni destruidos. METAR-D. Acrónimo que se utiliza para designar el servicio de informes meteorológicos aeronáuticos por enlace de datos. Modelo de referencia para interconexión de sistemas abiertos (OSI). Modelo que proporciona un enfoque normalizado al diseño de red a base de módulos por los que se subdividen los conjuntos

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-9 complejos de funciones en siete capas más manejables, independientes y funcionales. Convencionalmente se representan habitualmente las capas en pilas verticales. Nota.— El modelo de referencia OSI se define en ISO/IEC 7498-1. Performance de comunicación requerida (RCP). Declaración de los requisitos de performance de las comunicaciones operacionales en apoyo de funciones específicas de ATM. (Véase el Manual sobre la performance de comunicación requerida (RCP) (Doc 9869). Requisito de nivel del sistema. El requisito de nivel del sistema es un requisito técnico de alto nivel obtenido a partir de los requisitos operacionales, limitaciones tecnológicas y restricciones normativas (administrativas e institucionales). Los requisitos de nivel del sistema sirven de base para los requisitos funcionales y para los requisitos de los niveles inferiores. Retardo de tránsito. En los sistemas de datos por paquete, el tiempo transcurrido entre una petición de transmisión de un paquete de ensamblado de datos y una indicación en el extremo receptor de que el correspondiente paquete ha sido recibido y de que está preparado para ser utilizado o retransmitido. Servicio automático de información terminal (ATIS). Suministro automático de información regular, actualizada, a las aeronaves que llegan y a las que salen, durante las 24 horas o determinada parte de las mismas.

Servicio automático de información terminal por enlace de datos (ATIS-D). Suministro del ATIS mediante enlace de datos. Servicio automático de información terminal voz (ATIS-voz). Suministro del ATIS mediante radiodifusiones vocales continuas y repetitivas.

Servicio de comunicaciones de las capas superiores (UL). Expresión relacionada con las capas de sesión, presentación y aplicación del modelo de referencia OSI. Servicio de comunicaciones interred. Arquitectura entre redes que permite el interfuncionamiento de las subredes de datos de tierra, aire-tierra y aviónica, mediante la adopción de servicios y protocolos con equipo común de interfaz basados en el modelo de referencia ISO/OSI. Servicio de directorio ATN (DIR). Servicio que hace posible que una entidad de aplicación o un usuario de la comunidad ATN consulte una base de datos de directorio distribuida y extraiga información sobre las capacidades de direccionamiento, seguridad y técnicas de otros usuarios o entidades de la comunidad ATN. Servicio de información de vuelo (FIS). Servicio cuya finalidad es aconsejar y facilitar información útil para la realización segura y eficaz de los vuelos. Servicios de seguridad ATN. Conjunto de disposiciones sobre seguridad de la información que permiten al sistema receptor de extremo o intermedio identificar (o sea, autenticar) inequívocamente la fuente de la información recibida y verificar la integridad de dicha información. Servicio de tránsito aéreo. Expresión genérica que se aplica, según el caso, a los servicios de información de vuelo, alerta, asesoramiento de tránsito aéreo, control de tránsito aéreo (servicios de control de área, control de aproximación o control de aeródromo).

ACP/1-DP/3

A3-10 Apéndice A del informe sobre la cuestión 3 del orden del día Servicio de tratamiento de mensajes ATS (ATSMHS). Aplicación ATN que consiste en Pprocedimientos utilizados para intercambiar mensajes ATS en modo de almacenamiento y retransmisión por la ATN en forma tal que la transmisión de un mensaje ATS por el proveedor de servicios no esté correlacionada en generalgeneralmente no está correlacionada con la transmisión de otro mensaje ATS. Sistema de tratamiento de mensajes ATS (AMHS). Conjunto de recursos de computación y comunicaciones que aplican las organizaciones de ATS para prestar el servicio de tratamiento de mensajes ATS. Servidor de gestión de contexto (CM). Elemento ATS que proporciona información de aplicación relativa a otras ATSU a las aeronaves o a las ATSU que la solicitan. Sistema de extremo (ES). Sistema que contiene las siete capas OSI y uno o varios procesos de aplicación de usuario de extremo. Sistema intermedio (IS). Sistema que ejecuta funciones de retransmisión y de encaminamiento y comprende las tres capas inferiores del modelo de referencia OSI. Subred. Una aplicación real de una red de datos que utiliza un protocolo y un plan de direccionamiento homogéneos y que está bajo control de una única autoridad. Trayecto autorizado. Trayecto de comunicaciones que el administrador o administradores de un dominio o dominios de encaminamiento han definido previamente como adecuado para determinado tipo y categoría de tráfico de mensajes. Vigilancia dependiente automática (ADS). Técnica de vigilancia que permite a las aeronaves proporcionar automáticamente, mediante enlace de datos, aquellos datos extraídos de sus sistemas de navegación y determinación de la posición instalados a bordo, lo que incluye la identificación de la aeronave, su posición en cuatro dimensiones y otros datos adicionales, de ser apropiado.

3.2 INTRODUCCIÓN 3.2.1 La red de telecomunicaciones aeronáuticas (ATN) incluye entidades de aplicación y servicios de comunicaciones que permiten el interfuncionamiento de las subredes de datos de tierra, aire-tierra y aviónica, mediante la adopción de servicios y protocolos con equipo común de interfaz basados en el modelo de referencia para la interconexión de sistemas abiertos (OSI) de la Organización Internacional de Normalización (ISO). El modelo conceptual de la ATN aparece en la Figura 3-1.* 3.2.2 La ATN, y los procedimientos de aplicación correspondientes, se diseñaron para servir de apoyo a los sistemas de comunicaciones, navegación, vigilancia y gestión del tránsito aéreo (CNS/ATM). La ATN:

a) tiene por finalidad específica y exclusivamente proporcionarprestar servicios de comunicaciones de datos digitales a los organismos proveedores de servicios de tránsito aéreo y a las empresas explotadoras de aeronaves para los siguientes tipos de tráfico de mensajes de comunicacionesen apoyo de:

* Todas las figuras se encuentran al final de este capítulo.

ACP/1-DP/3


1) comunicaciones de los servicios de tránsito aéreo (ATSC) con la aeronave; 2) comunicaciones de los servicios de tránsito aéreo entre dependencias ATS; 2)3) comunicaciones de control de las operaciones aeronáuticas (AOC); y 3)4) comunicaciones aeronáuticas administrativas (AAC); y. 4) comunicaciones aeronáuticas de los pasajeros (APC);

b) proporciona, de forma transparente para el usuario, un servicio de comunicaciones de

extremo a extremo fiable, esencial para el suministro de servicios de tránsito aéreo seguros y eficientes entre: 1) sistemas de a bordo y sistemas de tierra; y 2) sistemas de tierra múltiples;

c) proporciona un servicio de comunicaciones de datos capaz de satisfacer los requisitos de los usuarios en materia de protección y seguridad operacional;

d) se basa en normas de comunicaciones de datos internacionalmente reconocidas que

facilitarán el desarrollo de sistemas armonizados y alentarán el suministro de servicios de red competitivos;

e) se adecúa a los distintos tipos/categorías/clases de servicio (incluida la subred aire-

tierra preferida/seleccionada) que requieren las diversas aplicaciones; f) define una arquitectura que permite la integración de subredes públicas y privadas,

tanto aire-tierra como tierratierra. Esto permite utilizar la infraestructura y las tecnologías de red existentes/planificadas, ofreciendo al mismo tiempo a los encargados de la ejecución la posibilidad de implantar la red progresivamente para satisfacer las necesidades crecientes de los usuarios; y

g) utiliza eficientemente las subredes aire-tierra de anchura de banda limitada y en

consecuencia se reducen los costos correspondientes.

3.2.3 Las aplicaciones ATN definidas en la actualidad se elaboraron para proporcionar servicios de comunicaciones, vigilancia e información. Estas aplicaciones tienen por objeto dar apoyo a los servicios siguientes:

a) Servicios de tránsito aéreo (ATS):

1) servicio de control de tránsito aéreo; 2) servicio de información de vuelo (FIS); y 3) servicio de alerta;

ACP/1-DP/3


b) gestión de afluencia del tránsito aéreo (ATFM); y c) gestión del espacio aéreo.

3.2.4 En este capítulo figuran disposiciones amplias y generales para la ATN. Las disposiciones técnicas detalladas se reseñan en el Doc 9705. El resto de este capítulo está organizado para tratar los siguientes requisitos y funciones:

a) generalidades; b) de nivel del sistema; c) requisitos de las aplicaciones ATN; d) del servicio de comunicaciones ATN; e) asignación de nombres y direccionamiento ATN; f) requisitos de gestión del sistema ATN; y g) requisitos de seguridad ATN.

3.3 GENERALIDADES Nota.— Las normas y métodos recomendados que figuran en las secciones 3.4 a 3.8 definen los protocolos y servicios mínimos requeridos para la implementación de la Red de telecomunicaciones aeronáuticas (ATN) de la OACI a escala mundial. 3.3.1 La red de telecomunicaciones aeronáuticas (ATN) proporcionará servicios de comunicaciones de datos y entidades de aplicación en apoyo de:

a) la entrega de servicios de tránsito aéreo (ATS) a las aeronaves; b) el intercambio de información ATS entre dependencias ATS; y c) otras aplicaciones, tales como el control de las operaciones aeronáuticas (AOC) y las

comunicaciones aeronáuticas administrativas (AAC).

Nota 1.— Se ha previsto lo necesario para permitir el intercambio de información, por ejemplo, información meteorológica, planes de vuelo, avisos a los aviadores y gestión de afluencia del tránsito aéreo dinámica en tiempo real, entre los sistemas basados en tierra de las empresas explotadoras de aeronaves y las dependencias ATS. Nota 2.— Se ha dispuesto también lo necesario para permitir las comunicaciones aeronáuticas de los pasajeros (APC). 3.3.2 Cuando se utilice la ATN como ayuda para los servicios de transporte aéreo, se ajustará a lo dispuesto en este capítulo. 3.3.1 Los servicios de comunicaciones de la ATN funcionarán con las aplicaciones ATN.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-13 3.3.32 Los requisitos para la utilizaciónimplementación de la ATN se formularán sobre la base de acuerdos regionales de navegación aérea. En esos acuerdos, se especificará el área en que se aplicarán las normas de comunicaciones para ATN/OSI o ATN/IPS. 3.3.4 Recomendación.— Las autoridades de aviación civil deberían coordinar con las autoridades nacionales y la industria aeronáutica aquellos aspectos de la implantación de la ATN que permitirán su seguridad, interfuncionamiento y uso eficiente en todo el mundo, en forma apropiada.

3.4 REQUISITOS A NIVEL DEL SISTEMAGENERALES Nota.— Los requisitos a nivel del sistema son requisitos técnicos de alto nivel obtenidos a partir de los requisitos operacionales, limitaciones tecnológicas y restricciones normativas (administrativas e institucionales). Estos requisitos a nivel del sistema sirven de base para los requisitos funcionales y para los requisitos de los niveles inferiores. 3.4.1 La ATN utilizará las normas de comunicaciones para interconexión de sistemas abiertos (OSI) de la Organización Internacional de Normalización (ISO), o bien las normas de comunicaciones de la Sociedad Internet (ISOC) para el conjunto de protocolos de Internet (IPS). Nota.— El interfuncionamiento entre redes OSI/IPS interconectadas se acordará antes de la implementación. 3.4.2 La ATN proporcionará los medios para facilitar la transición a futuras versiones de las entidades de aplicación o de los servicios de comunicaciones. Nota.— Se tiene por objetivo que la evolución hacia futuras versiones incluya también la compatibilidad hacia atrás. 3.4.32 La cabecera AFTN/AMHS garantizará el interfuncionamiento de las estaciones y redes AFTN y CIDIN con la ATN permitirá que los actuales usuarios y sistemas de la AFTN/CIDIN efectúen la transición hacia la arquitectura ATN. Nota.— La transición de la AFTN o de la CIDIN a la ATNse controla por las cabeceras AFTN/AMHS y CIDIN/ AMHS, respectivamente, que se definen en el Doc 9705, Subvolumen III. 3.4.4 La ATN dispondrá lo necesario para que únicamente la dependencia ATS de control pueda proporcionar instrucciones ATC a las aeronaves que operan en su espacio aéreo.

Nota.— Esto se logra indicando cuál es la autoridad responsable de los datos actuales y siguientes en la entidad de aplicación de las comunicaciones por enlace de datos controlador-piloto (CPDLC). 3.4.53 La ATN permitirá el encaminamientoEl o los trayectos autorizado(s) se definirán sobre la base de criteriosuna política de encaminamiento previamente definidospredefinida. 3.4.4 La ATN transmitirá, retransmitirá y (o) entregará mensajes de acuerdo con las clasificaciones de prioridades y sin discriminación o retraso indebido. 3.4.65 La ATN dispondrá de los medios para definir las comunicaciones de datos que pueden transmitirse únicamente por los trayectos autorizados con respecto al tipo y categoría de tráfico de mensajes especificados por el usuario.

ACP/1-DP/3

A3-14 Apéndice A del informe sobre la cuestión 3 del orden del día 3.4.76 La ATN ofrecerá distintas clases de ATSC conforme a los criterios de la Tabla 3-1.*establecerá las comunicaciones de conformidad con la performance de comunicación requerida (RCP) prescrita. [Véase el Manual sobre la performance de comunicación requerida, (Doc 9869)]. Nota 1.— Cuando se especifique una clase de ATSC en una aplicación ATN, los paquetes se transmitirán por el servicio de comunicaciones interred de la ATN según las posibilidades. Según las posibilidades significa que cuando se disponga de una ruta de la clase de ATSC solicitada, el paquete se transmitirá por dicha ruta. Cuando no se disponga de tal ruta, el paquete se transmitirá por la primera ruta conocida de la clase de ATSC superior a la solicitada, o si tampoco hubiera en este caso ruta disponible, se transmitirá por la primera ruta conocida de la clase de ATSC inferior a la solicitada. Nota 2.— El servicio de comunicaciones ATN no informará a las entidades de aplicación de que no pudo obtenerse la clase de ATSC solicitada. Incumbe a la entidad de aplicación determinar por medios locales cuál ha sido realmente el retardo de tránsito, por ejemplo mediante la marcación del tiempo. 3.4.87 La ATN funcionará de conformidad con las prioridades de comunicaciones definidas en la Tabla 321* y la Tabla 332. 3.4.98 La ATN permitirá el intercambio de información de aplicación para indicar que se dispone de uno o varios trayectos autorizados. 3.4.109 La ATN notificará a los procesos de aplicación apropiados cuando no se disponga de trayecto autorizado. 3.4.11 La ATN dispondrá de los medios para el direccionamiento unívoco y sin ambigüedades respecto de todos los sistemas de extremo e intermedios de la ATN. 3.4.12 La ATN permitirá que el destinatario de un mensaje identifique al originador del mismo. 3.4.13 Los planes de asignación de nombres y direccionamiento ATN permitirán que los Estados y organizaciones asignen las direcciones y nombres dentro de sus propios dominios administrativos. 3.4.14 La ATN apoyará las comunicaciones de datos de los sistemas fijos y móviles. 3.4.15 La ATN incorporará las subredes móviles ATN según lo definido en el presente Anexo. 3.4.1610 La ATN dispondrá de lo necesario para utilizar eficientemente las subredes de anchura de banda limitada. 3.4.1711 Recomendación. La ATN debería permitirá la conexión de un sistema intermedio de aeronave (encaminador) con un sistema intermedio de tierra (encaminador) víaa través de diferentes subredes móviles coexistentes. 3.4.1812 Recomendación. La ATN debería permitirá la conexión de un sistema intermedio de aeronave (encaminador) con múltiplesdiferentes sistemas intermedios de tierra (encaminadores). 3.4.1913 La ATN permitirá el intercambio de información sobre direcciones entre entidades de aplicaciónaplicaciones. 3.4.20 La ATN permitirá la aplicación de gestión de contexto (CM) cuando pueda llevarse a cabo cualquiera de las demás aplicaciones aire-tierra. * Las tablas 3-1 y 3-2 están ubicadas al final de este capítulo.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-15 3.4.21 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par en la aplicación de gestión de contexto (CM). 3.4.22 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par en la aplicación de la vigilancia dependiente automática (ADS). 3.4.23 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par en la aplicación de comunicaciones por enlace de datos controlador-piloto (CPDLC). 3.4.24 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par en la aplicación del servicio automático de información terminal (ATIS). 3.4.25 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones en la aplicación de los servicios de tratamiento de mensajes ATS (ATSMHS). 3.4.26 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par en la aplicación de comunicaciones de datos entre instalaciones ATS (AIDC). 3.4.2714 Cuando se utilice la hora absoluta del día en la ATN, tendrá una exactitud de 1 segundo en relación con el tiempo universal coordinado (UTC). Nota.— UnEl valor de exactitud del tiempo puede dar como resultado errores de sincronización de hasta 2 veces el valor de exactitud establecidodos segundos. 3.4.28 El sistema de extremo dispondrá de lo necesario para asegurar que la probabilidad de que no se detecte un caso de entrega equivocada, de no entrega o de mutilación de un mensaje de 255 octetos por parte del servicio de comunicaciones interred sea inferior o igual a 10-8 por mensaje. Nota. — Se supone que las subredes de la ATN asegurarán una integridad de datos que concuerde con este requisito de nivel del sistema. 3.4.29 Los sistemas de extremo ATN que dan apoyo a los servicios de seguridad ATN tendrán capacidad para autenticar la identidad de los sistemas de extremo pares, autenticar la fuente de mensajes de aplicación y garantizar la integridad de los datos de los mensajes de aplicación. Nota.— Los mensajes de aplicación en este contexto incluyen mensajes relacionados con el ATS, la gestión de sistemas y los servicios de guía. 3.4.30 Los sistemas intermedios limítrofes de tierra y aire tierra ATN que prestan apoyo a los servicios de seguridad ATN tendrán capacidad para autenticar la identidad de los sistemas intermedios limítrofes pares, autenticar la fuente de información de encaminamiento y garantizar la integridad de los datos de la información de encaminamiento. 3.4.31 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones par a par para el intercambio de información de guía. 3.4.32 Los sistemas ATN que sirven de apoyo a la gestión de sistemas ATN facilitarán la continuidad mejorada de las operaciones ATN, incluyendo la vigilancia y el mantenimiento de la calidad del servicio de comunicaciones. 3.4.33 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones para entidades pares para utilizar la gestión de sistemas (SM).

ACP/1-DP/3

A3-16 Apéndice A del informe sobre la cuestión 3 del orden del día 3.4.34 La ATN tendrá capacidad para establecer, mantener, liberar e interrumpir asociaciones entre aplicaciones para entidades pares para utilizar el servicio de informe meteorológico aeronáutico ordinario (METAR).

3.5 REQUISITOS DE LAS APLICACIONES ATN Nota 1.— La implantación de las aplicaciones ATN en los Estados o regiones no supone la implantación de todas las aplicaciones ATN que se definen a continuación. Nota 2.— La implantación de subconjuntos predefinidos de disposiciones técnicas sobre aplicaciones ATN está permitida según se detalla en el Doc 9705.

3.5.1 Aplicaciones del sistema Nota.— Las aplicaciones del sistema proporcionan los servicios necesarios para el funcionamiento de las aplicaciones ATN aire-tierra y tierra-tierra y los servicios de comunicaciones ATN. 3.5.1.1 La ATN dará apoyo a las aplicaciones de Capacidad de iniciación de enlace de datos (DLIC) que figuran en el Manual de aplicaciones de enlace de datos para los servicios de tránsito aéreo (Doc 9694) (Parte I) cuando se implementen los enlaces de datos aire-tierra.

3.5.1.1 APLICACIÓN DE GESTIÓN DE CONTEXTO (CM)

Nota.— La aplicación CM proporciona capacidad para que la aeronave establezca conexión con un sistema ATS de tierra; en algunos casos, el sistema de tierra pedirá a la aeronave que establezca contacto con un determinado sistema de tierra. Después de establecer la conexión apropiada, la CM permite el intercambio de información en cada una de las aplicaciones ATN apoyadas, incluida la dirección de red de cada aplicación, según corresponda. Para los sistemas ATN que apoyan los servicios de seguridad, CM también obtiene e intercambia claves e información referente a dichas claves. CM también proporciona la capacidad necesaria para actualizar la información de conexión y para que un sistema ATS de tierra pueda transmitir información de conexión a otro sistema ATS de tierra. La función de registro de la CM permite compartirla información con otras aplicaciones en tierra o a bordo. 3.5.1.1.1 La ATN tendrá capacidad para dar apoyo a las siguientes funciones de la aplicación CM:

a) conexión; b) contacto; c) actualización; d) consulta al servidor CM; e) actualización del servidor CM; f) retransmisión en tierra; y g) registro.

ACP/1-DP/3

Apéndice A del informe sobre la cuestión 3 del orden del día A3-17 Nota.— Las disposiciones técnicas para la aplicación CM se definen en el Doc 9705, Subvolumen II.

3.5.1.2 SERVICIOS DE DIRECTORIO (DIR) ATN 3.5.1.2.1 Cuando se ponga en funcionamiento el AMHS y/o los protocolos de seguridad, el sistema de extremo La ATN/OSI tendrá capacidad para dará apoyo a las funciones de aplicación DIR siguientes (Véase la serie UIT-T X.500):

a) vinculación al directorio; ba) extracción de información de directorio; y cb) cambiomodificación de información de directorio.

Nota 1.— El servicio de directorio ATN permite que una aplicación o usuario consulte una base de datos de directorio distribuida y extraiga información sobre la capacidad de direccionamiento, seguridad y técnica. El servicio de directorio ofrece a usuarios autorizados especiales la capacidad de añadir, suprimir y modificar partes de la base de datos de directorio de las que sean responsables. La ATN ofrece el servicio de directorio a todas las aplicaciones y todos los usuarios que cumplen con las disposiciones técnicas del Doc 9705, Subvolumen VII. Nota 2.— La vinculación al directorio es la función que establece una asociación entre dos componentes de directorio que prestan apoyo a otras funciones de directorio. La vinculación al directorio proporciona los contextos de aplicación y las conexiones de comunicaciones subyacentes para su utili-zación en otras funciones de directorio.

3.5.1.3 OTRAS APLICACIONES DEL SISTEMA

(por elaborar)

3.5.2 Aplicaciones aire-tierra

Nota.— Los componentes de tierra de las aplicaciones aire-tierra incluyen las funciones necesarias para apoyar la retransmisión del contenido de los mensajes de aire a tierra por trayectos de comunicaciones tierra tierra.

3.5.2.1 APLICACIÓN DE LA VIGILANCIA DEPENDIENTE AUTOMÁTICA (ADS) Nota.— La aplicación ADS comprende un componente de a bordo y un componente de tierra. El componente de a bordo de la aplicación ADS tiene capacidad para proporcionar automáticamente al componente de tierra, vía el servicio de comunicaciones ATN, datos extraídos de los sistemas de navegación de a bordo (por ejemplo, la identificación de la aeronave, su posición en cuatro dimensiones, la intención, y otros datos adicionales, de ser apropiado). La aplicación ADS proporciona servicio basado en contratos establecidos entre sus componentes de a bordo y de tierra (a saber, contrato a pedido, contrato periódico, contrato relacionado con un suceso y contrato de emergencia) y entre dos componentes ADS de tierra (a saber, contrato anticipado).

ACP/1-DP/3

A3-18 Apéndice A del informe sobre la cuestión 3 del orden del día 3.5.2.1.1 La ATN tendrá capacidad para dar apoyo a una o más de las siguientes funciones de la aplicación ADSaplicaciones, de conformidad con las disposiciones del Doc 9694:

a) contratos a solicitudADS-C; b) contratos periódicosCPDLC; y c) contratos relacionados con un suceso FIS (incluidos ATIS y METAR);. d) contratos de emergencia; y e) contratos anticipados.

Nota.— Las disposiciones técnicas para la aplicación ADS se definen en el Doc 9705, Subvolumen II.

3.5.2.2 APLICACIÓN DE COMUNICACIONES POR ENLACE DE DATOS CONTROLADOR PILOTO (CPDLC)

Nota.— La aplicación CPDLC, que comprende un componente de a bordo y un componente de tierra, ofrece capacidad de comunicaciones de enlace de datos entre las dependencias ATS y las aeronaves bajo su control o las aeronaves que van a entrar a su área de control. La aplicación CPDLC tiene capacidad para establecer, gestionar y terminar los diálogos CPDLC de intercambio de mensajes controlador piloto y de retransmisión de mensajes en tierra. 3.5.2.2.1 La ATN tendrá capacidad para dar apoyo a las siguientes funciones de la aplicación CPDLC:

a) intercambio de mensajes controlador-piloto; b) transferencia de autoridad de datos; c) autorización subsiguiente; y d) retransmisión en tierra.

Nota.— Las disposiciones técnicas para la aplicación CPDLC se definen en el Doc 9705, Subvolumen II.

3.5.2.3 APLICACIONES DEL SERVICIO DE INFORMACIÓN DE VUELO (FIS) Nota.— Las aplicaciones FIS proporcionan a los usuarios del espacio aéreo servicios de información de vuelo de los sistemas FIS de tierra.

3.5.2.3.1 APLICACIÓN DEL SERVICIO AUTOMÁTICO DE INFORMACIÓN TERMINAL (ATIS)

3.5.2.3.1.1 La ATN tendrá capacidad para dar apoyo a las siguientes funciones de la aplicación ATIS:

a) contratos a pedido FIS iniciados a bordo;

ACP/1-DP/3


b) contratos de actualización FIS iniciados a bordo; y c) cancelación de contratos FIS iniciados tanto a bordo como en tierra.

Nota.— Las disposiciones técnicas para la aplicación ATIS se definen en el Doc 9705, Subvolumen II.

3.5.2.3.2 APLICACIÓN DEL SERVICIO DE INFORME METEOROLÓGICO AERONÁUTICO ORDINARIO (METAR)

3.5.2.3.2.1 La ATN tendrá capacidad para prestar apoyo a la función de la aplicación METAR para contratos de demanda FIS iniciados a bordo. Nota.— Las disposiciones técnicas para la aplicación METAR se definen en el Doc 9705, Subvolumen II.

3.5.2.3.3 OTRAS APLICACIONES FIS

(por elaborar)

3.5.2.4OTRAS APLICACIONES AIRE-TIERRA

(POR ELABORAR)

3.5.3 Aplicaciones tierra-tierra Nota.— Las aplicaciones tierra-tierra son las aplicaciones ATN que residen en sistemas de tierra y únicamente intercambian información con aplicaciones pares que también residen en sistemas de tierra.

3.5.3.1 COMUNICACIONES ENTRE CENTROS (ICC) Nota.— El conjunto de aplicaciones de comunicaciones entre centros permite el intercambio de información entre dependencias de servicios de tránsito aéreo.

3.5.3.1.1 COMUNICACIÓN DE DATOS ENTRE INSTALACIONES ATS (AIDC) Nota.— AIDC es una aplicación ATN utilizada por dos dependencias del servicio de tránsito aéreo para permitir el intercambio de información ATS sobre vuelos activos con respecto a la notificación del vuelo, coordinación del vuelo, transferencia de control, datos de vigilancia y datos en texto libre (es decir, sin estructurar). 3.5.3.1.1.1 La ATN tendrá capacidad para dar apoyo a las siguientes funciones de la aplicación aplicaciones AIDC que figuran en el Doc 9694 y a la aplicación de servicios de tratamiento de mensajes ATS (ATSMHS). :

a) notificación del vuelo;

ACP/1-DP/3


b) coordinación del vuelo; c) transferencia de control; d) transferencia de comunicaciones; e) transferencia de datos de vigilancia; y f) transferencia de datos generales.

Nota.— Las disposiciones técnicas para la aplicación AIDC se definen en el Doc 9705, Subvolumen III.

3.5.3.2 APLICACIÓN DE SERVICIOS DE TRATAMIENTO DE MENSAJES (ATSMHS) Nota.— La aplicación de servicios de tratamiento de mensajes ATS (ATSMHS) comprende una función principal denominada función de servicio de mensajes ATS. La función de servicio de mensajes ATS permite el intercambio de mensajes ATS entre los usuarios mediante el suministro de un servicio genérico de mensajes. La aplicación ATSMHS incluye la definición de las cabeceras AFTN/ATN y CIDIN/ATN. 3.5.3.2.1 La ATN tendrá capacidad para dar apoyo al servicio de mensajes ATS de la aplicación de servicios de tratamiento de mensajes ATS (ATSMHS). Nota.— Las disposiciones técnicas para la aplicación ATSMHS se definen en el Doc9705, Subvolumen III.

3.5.3.3 OTRAS APLICACIONES TIERRA TIERRA

(POR ELABORAR)

3.6 REQUISITOS DEL SERVICIO DE COMUNICACIONES ATN

Nota.— Los requisitos del servicio de comunicaciones ATN definen los requisitos correspondientes a las capas 3 a 6, así como una parte de la capa 7 del modelo de referencia OSI. Estos servicios utilizan la información producida por una de las distintas aplicaciones ATN y realizan el servicio de comunicaciones extremo a extremo empleando protocolos normalizados. Los requisitos del servicio de comunicaciones se dividen en dos partes: el servicio de comunicaciones de las capas superiores que define las normas para las capas 5 a 7 y el servicio de comunicaciones interred que define las normas para las capas 3 y 4. Los requisitos para las capas 1 y 2 quedan fuera del ámbito de los SARPS ATN.

3.6.1 Servicio de comunicaciones de las capas superiores

3.6.1.1 El servicio de comunicaciones de las capas superiores comprenderá:

a) la capa de sesión;

ACP/1-DP/3


b) la capa de presentación; c) la estructura de la entidad de aplicación; d) el elemento de servicio para control de asociación (ACSE); e) el objeto de servicio de aplicación (ASO) de seguridad, para los servicios de

seguridad que prestan apoyo a los sistemas ATN; y f) la función de control (CF).

Nota 1.— Las disposiciones técnicas para el servicio de comunicaciones de las capas superiores para todas las aplicaciones ATN, con excepción de la función de servicio de mensajes ATS de la aplicación ATSMHS se definen en el Doc9705, Subvolumen IV. Nota 2.— Las disposiciones técnicas para el servicio de comunicaciones de las capas superiores para la función de servicio de mensajes ATS de la aplicación ATSMHS se definen en el Doc 9705, Subvolumen III. 3.6.1 Servicio de comunicaciones de las capas superiores ATN/IPS. 3.6.1.1 Un sistema anfitrión (host) ATN* tendrá la capacidad de dar apoyo a las capas superiores ATN/IPS, incluida una capa de aplicación. 3.6.2 Servicio de comunicaciones de las capas superiores ATN/OSI. 3.6.2.1 Un sistema de extremo ATN/OSI (ES)* tendrá la capacidad de dar apoyo a los servicios de comunicaciones de las capas superiores (ULCS), incluidas las capas de sesión, presentación y aplicación. Nota.— Las especificaciones técnicas detalladas para ULCS OSI figuran en el Doc 9705. 3.6.3 Servicio de comunicaciones por Internet ATN/IPS. 3.6.3.1 Un sistema anfitrión (host) ATN tendrá la capacidad de dar apoyo a las comunicaciones por Internet ATN/IPS, incluidas:

a) la capa de transporte, de conformidad con RFC 793 (TCP) y RFC 768 (UDP); y b) la capa de red, de conformidad con RFC 2460 (IPv6).

3.6.3.2 Un encaminador IPS dará apoyo a la capa de red ATN de conformidad con RFC 2460 (IPv6) y RFC 4271 (BGP), y RFC 2858 (extensiones de multiprotocolo BGP). 3.6.24 Servicio de comunicaciones interredpor Internet de la ATN/OSI. Nota.— Los requisitos del servicio de comunicaciones interred de la ATN se aplican a las entidades funcionales de los sistemas de extremo y de los sistemas intermedios que conjuntamente proporcionan el servicio de comunicaciones interred ATN. El servicio de comunicaciones interred ATN se proporciona al usuario (es decir, las capas superiores) vía la interfaz de servicio de la capa de transporte.

* Un sistema anfitrión (host) ATN es un sistema de extremo ATN en la terminología OSI; un sistema de extremo ATN es un

sistema anfitrión (host) en la terminología IPS.

ACP/1-DP/3

A3-22 Apéndice A del informe sobre la cuestión 3 del orden del día 3.6.24.1 Un sistema de extremo (ES) ATN/OSI tendrá capacidad para dar apoyo a la interred Internet ATN, incluyendo:

a) la capa de transporte de conformidad con ISO/IEC 8073 (TP4) y ISO/IEC 8602 (CLTP); y

b) la capa de red de conformidad con ISO/IEC 8473 (CLNP).

3.6.4.2 Un sistema intermedio (IS) ATN apoyará las disposiciones relativasdará apoyo a la capa de red ATN, en forma apropiada a la clase de IS ATN en cuestiónde conformidad con ISO/IEC 8473 (CLNP) y ISO/IEC 10747 (IDRP). Nota.— Se reseñan diversas clases de sistemas intermedios ATN, a cuyo respecto se definen los perfiles de la capa de red, en el Doc 9705, Subvolumen V.

3.7 REQUISITOS DE ASIGNACIÓN DE NOMBRES Y DIRECCIONAMIENTO ATN

Nota.— El plan de asignación de nombres y direccionamiento ATN se ajusta a los principios de identificación unívoca y sin ambigüedadesinequívoca de objetos de informaciónsistemas intermedios (encaminadotes) y sistemas de extremo (anfitriones) y permite la normalización de direcciones mundiales. 3.7.1 En la ATN se dispondrá lo necesario para asignar nombres de envidadla identificación inequívoca de aplicaciónones. 3.7.2 En la ATN se dispondrá lo necesario para el direccionamiento de red y de transporteinequívoco. Nota.— Las disposiciones técnicas para las asignación de nombres de entidad de aplicación ATN se definen en el Doc9705, Subvolumen IV, las disposiciones para el direccionamiento de red y de transporte se definen en el SubvolumenV, y las disposiciones para los servicios de registro se definen en el Subvolumen IX de ese mismo documento. 3.4.117.3 La ATN dispondrá de los medios para el direccionamiento unívoco y sin ambigüedades inequívoco respecto de todos los sistemas de extremo (anfitriones) e intermedios (encaminadores) de la ATN. 3.4.137.4 Los planes de asignación de nombres y direccionamiento ATN permitirán que los Estados y organizaciones asignen las direcciones y nombres dentro de sus propios dominios administrativos.

3.8 REQUISITOS DE GESTIÓN DEL SISTEMA ATN Nota 1.— La aplicación de gestión de sistemas (SM) ATN proporciona la capacidad necesaria para que el administrador de gestión de sistemas intercambie información con un agente SM u otro administrador SM. Nota 2.— Con respecto a las disposiciones técnicas de los servicios SM de la ATN, es posible que se requiera apoyo a escala estatal o regional. 3.8.1 La ATN tendrá capacidad para dar apoyo a las siguientes funciones de la aplicación de gestión de sistemas:

ACP/1-DP/3


a) gestión de fallas; b) gestión de configuración; c) gestión de contabilidad; d) gestión de rendimiento; y e) gestión de seguridad.

Nota.— Las disposiciones técnicas para la gestión de sistemas ATN se definen en el Doc 9705, Subvolumen VI. 3.8.1.1 Los sistemas de extremo y los sistemas intermedios ATN que sirven de apoyo a la aplicación de gestión de sistemas ATN y los administradores SM proporcionarán acceso a los objetos gestionados. Nota.— Las definiciones de objetos gestionados por la aplicación SM y las disposiciones de acceso se definen en el Doc 9705, Subvolumen VI.

3.98 REQUISITOS DE SEGURIDAD ATN 3.4.48.1 La ATN dispondrá lo necesario para que únicamente la dependencia ATS de control pueda proporcionardar instrucciones ATC a las aeronaves que operan en su espacio aéreo.

Nota.— Esto se logra indicando cuál es la autoridad responsable de los datos actuales y siguientes en la entidad de mediante los aspectos “autoridad de datos vigente” y “autoridad de datos siguiente” de la aplicación de las comunicaciones por enlace de datos controlador-piloto (CPDLC). 3.4.128.2 La ATN permitirá que el destinatario de un mensaje identifique al originador del mismo. 3.4.298.3 Los sistemas de extremo de la ATN que dan apoyo a los servicios de seguridad ATN tendrán la capacidad parade autenticar la identidad de los sistemas de extremo pares, autenticar la fuente de mensajes de aplicación y garantizar la integridad de los datos de los mensajes de aplicación. 3.9.1 La seguridad de la ATN se logrará mediante una combinación de disposiciones técnicas, medidas de seguridad física locales y medidas de seguridad de procedimientos. Nota 1.— Las disposiciones técnicas relativas a seguridad ATN se definen en el Doc 9705, y las medidas físicas y de seguridad de procedimientos se definen en el Anexo 17 y el Manual de seguridad. Nota 2.— Con respecto a las disposiciones técnicas de los servicios de seguridad de la ATN, es posible que se requiera apoyo a escala estatal o regional. 3.9.1.1 Recomendación.— Deberían aplicarse las técnicas físicas y de procedimientos siguientes para proporcionar seguridad a los sistemas de extremo, los sistemas intermedios, los administradores de sistemas, los servidores de guía y las subredes de la ATN:

a) acceso físico restringido a los sistemas de extremo, sistemas intermedios, puestos de trabajo SM, servidores de guía, conmutadores de subred, administradores de la red y otros subsistemas de red esenciales de la ATN;

ACP/1-DP/3


b) acceso de usuarios restringido a los sistemas de extremo, sistemas intermedios,

servidores de guía y puestos de trabajo SM de la ATN, al personal autorizado únicamente; y

c) uso prohibido o restringido del acceso a distancia a los sistemas de extremo de tierra,

sistemas intermedios y puestos de trabajo SM de la ATN.

3.9.2 Política en materia de seguridad ATN Nota.— La vigilancia de las comunicaciones y el análisis de tráfico de terceros no constituyen un riesgo desde el punto de vista de la seguridad y se considera que no son una amenaza para la seguridad de las ATSC. No obstante, es posible que algunos usuarios y aplicaciones ATS o no ATS tengan políticas locales o institucionales según las cuales la vigilancia de las comunicaciones y el análisis de tráfico de terceros se considerarían amenazas para la seguridad teniendo en cuenta otros aspectos, como el económico, por ejemplo. 3.9.2.1 Los mensajes ATS estarán protegidos contra suplantación, modificaciones y repetición. Nota 1.— Esto significa que para los mensajes de datos intercambiados entre entidades ATN habrá un alto grado de seguridad en cuanto a que el mensaje viene de donde dice venir, no ha sido manipulado indebidamente y no se trata de una repetición de un mensaje obsoleto. Nota 2.— El nivel de protección podrá variar según el tipo de amenaza contra la seguridad y el nivel del servicio de seguridad ATN seleccionado por el usuario o proceso de aplicación. 3.9.2.2 Deberán aceptarse las peticiones de protección de los mensajes ATS: Nota.— Se podrá aceptar una petición para no utilizar la protección. Esto significa que el uso de seguridad constituye el valor preestablecido y que la negociación para no utilizarla depende de políticas locales. 3.9.2.38.4 Los servicios ATN que tramitan mensajes hacia y desde las aeronaves estarán protegidos contra ataques de denegación deal servicio hasta un nivel de probabilidad que concuerdeacorde con la disponibilidad los requisitos del servicio de la aplicación requerido, según lo determinen las políticas locales. Nota 1.— El término “denegación de servicio” describe la situación que tiene lugar cuando se obstruye deliberadamente el acceso legítimo a la información o a otros recursos ATN. Nota 2.— Esto puede significar que es necesario contar con trayectos de comunicaciones de alternativa en caso de que un trayecto sea objeto de denegación de servicio.

ACP/1-DP/3


TABLAS DEL CAPÍTULO 3

Tabla 3-1.Retardos de tránsito para las distintas clases de ATSC

Máximo retardo de tránsito extremo a extremo por la ATN en un solo sentido con un 95% de probabilidad (segundos)

Clase de ATSC

Reservado A

4,5 B

7,2 C

13,5 D

18 E

27 F

50 G

100 H

sin valor especificado sin preferencia

Nota 1. El valor de retardo de tránsito de extremo a extremo por la ATN representa aproximadamente el 90% del valor de retardo de tránsito total extremo a extremo entre usuarios finales del sistema.

Nota 2. La probabilidad del 95% se basa en la disponibilidad de una ruta que se ajuste a la clase de ATSC solicitada.

ACP/1-DP/3


Tabla 3-21. Correspondencia de las prioridades de comunicaciones ATN

Categorías de mensajes Aplicación ATN Prioridad del protocolo correspondiente

Prioridad de la capa de transporte

Prioridad de la capade red

Gestión de red/sistemas SM 0 14

Comunicaciones de socorro 1 13

Comunicaciones urgentes 2 12

Mensajes de alta prioridad relativos a la seguridad del vuelo

CPDLC, ADS 3 11

Mensajes de prioridad normal relativos a la seguridad del vuelo

AIDC, ATIS 4 10

Comunicaciones meteorológicas METAR 5 9

Comunicaciones relativas a la regularidad del vuelo

CM, ATSMHS 6 8

Mensajes del servicio de información aeronáutica 7 7

Administración de red/sistemas SM, DIR 8 6

Mensajes aeronáuticos administrativos 9 5

<por asignar> 10 4

Comunicaciones de prioridad urgente administrativas y relativas a la Carta de las Naciones Unidas

11 3

Comunicaciones de alta prioridad administrativas y de los Estados/gobiernos

12 2

Comunicaciones administrativas de prioridad normal

13 1

Comunicaciones administrativas de baja prioridad y comunicaciones aeronáuticas de los pasajeros

14 0

Nota. Las prioridades de la capa de red que figuran en esta tabla se aplican únicamente a la prioridad de red sin conexión y no a la prioridad de la subred.

ACP/1-DP/3


Tabla 3-32.Correspondencia de la prioridad de la red ATN respecto a la prioridad de la subred móvil

Categorías de mensajes Prioridad

de la capa de red ATN

Prioridad correspondiente de la subred móvil (véase la Nota 4)

SMAS VDL Modo 2

VDL Modo 3

VDL Modo 4 (véase la Nota 5)

SSR Modo S

HFDL

Gestión de red/sistemas 14 14 véase la Nota 1 3 alta14 alta 14

Comunicaciones de socorro 13 14 véase la Nota 1 2 alta13 alta 14

Comunicaciones urgentes 12 14 véase la Nota 1 2 alta12 alta 14

Mensajes de alta prioridad relativos a la seguridad del vuelo

11 11 véase la Nota 1 2 alta11 alta 11

Mensajes de prioridad normal relativos a la seguridad del vuelo

10 11 véase la Nota 1 2 alta10 alta 11

Comunicaciones meteorológicas 9 8 véase la Nota 1 1 media9 baja 8

Comunicaciones relativas a la Regularidad del vuelo

8 7 véase la Nota 1 1 media8 baja 7

Mensajes del servicio de información aeronáutica

7 6 véase la Nota 1 0 media7 baja 6

Administración de red/sistemas 6 5 véase la Nota 1 0 media6 baja 5

Mensajes aeronáuticos administrativos

5 5 no permitida no permitida no permitida5 no permitida no permitida

<por asignar> 4 por asignar por asignar por asignar por asignar4 por asignar por asignar

Comunicaciones de prioridad urgente administrativas y relativas a la Carta de las Naciones Unidas


Comunicaciones de alta prioridad administrativas y de los Estados/gobiernos


Comunicaciones administrativas de prioridad normal 1 1 no permitida no permitida no permitida1 no permitida no permitida

Comunicaciones administrativas de baja prioridad y comunicaciones aeronáuticas de los pasajeros


Nota 1. — El VDL en Modo 2 no tiene mecanismos específicos de prioridad de la subred. Nota 2. — En los SARPS SMAS se especifica la correspondencia entre las categorías de mensajes y la prioridad de la subred sin hacer referencia explícita a la prioridad de la capa de red ATN. Nota 3. — La expresión “no permitida” significa que solamente las comunicaciones relativas a la seguridad y regularidad del vuelo están autorizadas a pasar por esta subred, con arreglo a lo definido en los SARPS de la subred. Nota 4. — Se enumeran únicamente las subredes móviles para las cuales existen SARPS relativos a la subred y para las que explícitamente se proporciona apoyo en las disposiciones técnicas del sistema intermedio limítrofe (BIS) ATN. Nota 5. — La subred VDL en Modo 4 apoya las aplicaciones de vigilancia (p. ej., la ADS).

— — — — — — — —

ACP/1-DP/3

Appendix B to the Report on Agenda Item 3 3B-1

ENGLISH ONLY

APPENDIX B

CLEAN VERSION

INTERNATIONAL STANDARDS

AND RECOMMENDED PRACTICES

AERONAUTICAL TELECOMMUNICATIONS

ANNEX 10 TO THE CONVENTION ON INTERNATIONAL CIVIL AVIATION

VOLUME III

(COMMUNICATION SYSTEMS)

PART I — DIGITAL DATA COMMUNICATION SYSTEMS

CHAPTER 1. DEFINITIONS

Note 1.— All references to “Radio Regulations” are to the Radio Regulations published by the International Telecom-munication Union (ITU). Radio Regulations are amended from time to time by the decisions embodied in the Final Acts of World Radiocommunication Conferences held normally every two to three years. Further information on the ITU processes as they relate to aeronautical radio system frequency use is contained in the Handbook on Radio Frequency Spectrum Requirements for Civil Aviation including statement of approved ICAO policies (Doc 9718).

Note 2.— This Part of Annex 10 includes Standards and Recommended Practices for certain forms of equipment for communication systems. While the Contracting State will determine the necessity for specific installations in accordance with the conditions prescribed in the relevant Standard or Recommended Practice, review of the need for specific installation and the formulation of ICAO opinion and recommendations to Contracting States concerned, is carried out periodically by Council, ordinarily on the basis of recommendations of Regional Air Navigation Meetings (Doc 8144, Directives to Regional Air Navigation Meetings and Rules of Procedure for their Conduct).

Note 3.— This chapter contains general definitions relevant to communication systems. Definitions specific to each of the systems included in this volume are contained in the relevant chapters.

Note 4.— Material on secondary power supply and guidance material concerning reliability and availability for communication systems is contained in Annex 10, Volume I, 2.9 and Volume I, Attachment F, respectively. Aeronautical telecommunication network (ATN). A global internetwork architecture that allows ground,

air-ground and avionic data subnetworks to exchange digital data for the safety of air navigation and for the regular, efficient and economic operation of air traffice services.

ACP/1-DP/3

3B-2 Appendix B to the Report on Agenda Item 3

Aeronautical administrative communications (AAC). Communications necessary for the exchange of aeronautical administrative messages (Re. Annex 10, Volume II, paragraph 4.4.1.1.7).

Aeronautical operational control (AOC). Communication required for the exercise of authority over the

initiation, continuation, diversion or termination of flight for safety, regularity and efficiency reasons (Re. Annex 6, Part I, Chapter 1 – Definitions).

Aircraft address. A unique combination of twenty-four bits available for assignment to an aircraft for the

purpose of air-ground communications, navigation and surveillance. Air traffic service. A generic term meaning variously, flight information service, alerting service, air

traffic advisory service, air traffic control service (area control service, approach control service or aerodrome control service) (Re. Annex 11, Chapter 1 – Definitions).

Aircraft earth station (AES). A mobile earth station in the aeronautical mobile-satellite service located on

board an aircraft (see also “GES”). Automatic Dependent Surveillance- Contract (ADS-C). A means by which the terms of an ADS

agreement will be exchanged between the ground system and the aircraft, via a data link, specifying under what condition ADS-C reports would be initiated and what data would be contained in the report. (Re. Annex 11, Chapter 1 – Definitions).

Automatic terminal information service (ATIS). The automatic provision of current, routine information

to arriving and departing aircraft throughout 24 hours or a specified portion thereof. (Re. Annex 11, Chapter 1 – Definitions).

Data link-automatic terminal information service (D-ATIS). The provision of ATIS via data link.

(Re. Annex 11, Chapter 1 – Definitions).

Voice-automatic terminal information service (Voice-ATIS). The provision of ATIS by means of continuous and repetitive voice broadcasts. (Re. Annex 11, Chapter 1 – Definitions).

Bit error rate (BER). The number of bit errors in a sample divided by the total number of bits in the sample, generally averaged over many such samples.

Carrier-to-multipath ratio (C/M). The ratio of the carrier power received directly, i.e. without reflection,

to the multipath power, i.e. carrier power received via reflection. Carrier-to-noise density ratio (C/No). The ratio of the total carrier power to the average noise power in a

1 Hz bandwidth, usually expressed in dBHz. Channel rate. The rate at which bits are transmitted over the RF channel. These bits include those bits

used for framing and error correction, as well as the information bits. For burst transmission, the channel rate refers to the instantaneous burst rate over the period of the burst.

Channel rate accuracy. This is relative accuracy of the clock to which the transmitted channel bits are

synchronized. For example, at a channel rate of 1.2 kbits/s, maximum error of one part in 106 implies the maximum allowed error in the clock is ±1.2 × 10-3 Hz.

ACP/1-DP/3


Circuit mode. A configuration of the communications network which gives the appearance to the application of a dedicated transmission path.

Controller pilot data link communication (CPDLC). A means of communication between controller and

pilot, using data link for ATC communications. (Re. Annex 11, Chapter 1 – Definitions). Data link flight information service (D-FIS). The provision of FIS via data link(Re. Annex 11, Chapter

1 – Definitions). Doppler shift. The frequency shift observed at a receiver due to any relative motion between transmitter

and receiver. End-to-end. Pertaining or relating to an entire communication path, typically from (1) the interface

between the information source and the communication system at the transmitting end to (2) the interface between the communication system and the information user or processor or application at the receiving end.

End-user. An ultimate source and/or consumer of information. Energy per symbol to noise density ratio (Es/No). The ratio of the average energy transmitted per channel

symbol to the average noise power in a 1 Hz bandwidth, usually expressed in dB. For A-BPSK and A-QPSK, one channel symbol refers to one channel bit.

Equivalent isotropically radiated power (e.i.r.p). The product of the power supplied to the antenna and

the antenna gain in a given direction relative to an isotropic antenna (absolute or isotropic gain). Flight information service (FIS). A service provided for the purpose of giving advice and information

useful for the safe and efficient conduct of flights. (Re. Annex 11, Chapter 1 – Definitions). Forward error correction (FEC). The process of adding redundant information to the transmitted signal

in a manner which allows correction, at the receiver, of errors incurred in the transmission. Gain-to-noise temperature ratio. The ratio, usually expressed in dB/K, of the antenna gain to the noise at

the receiver output of the antenna subsystem. The noise is expressed as the temperature that a 1 ohm resistor must be raised to produce the same noise power density.

Ground earth station (GES). An earth station in the fixed satellite service, or, in some cases, in the

aeronautical mobile-satellite service, located at a specified fixed point on land to provide a feeder link for the aeronautical mobile-satellite service.

Note.— This definition is used in the ITU’s Radio Regulations under the term “aeronautical earth

station.” The definition herein as “GES” for use in the SARPs is to clearly distinguish it from an aircraft earth station (AES), which is a mobile station on an aircraft. Mode S subnetwork. A means of performing an interchange of digital data through the use of secondary

surveillance radar (SSR) Mode S interrogators and transponders in accordance with defined protocols.

ACP/1-DP/3


Point-to-point. Pertaining or relating to the interconnection of two devices, particularly end-user instruments. A communication path of service intended to connect two discrete end-users; as distinguished from broadcast or multipoint service.

Slotted aloha. A random access strategy whereby multiple users access the same communications channel

independently, but each communication must be confined to a fixed time slot. The same timing slot structure is known to all users, but there is no other co-ordination between the users.

Time division multiplex (TDM). A channel sharing strategy in which packets of information from the

same source but with different destinations are sequenced in time on the same channel. Time division multiple access (TDMA). A multiple access scheme based on time-shared use of an RF

channel employing: (1) discrete contiguous time slots as the fundamental shared resource; and (2) a set of operating protocols that allows users to interact with a master control station to mediate access to the channel.

Transit delay. In packet data systems, the elapsed time between a request to transmit an assembled data

packet and an indication at the receiving end that the corresponding packet has been received and is ready to be used or forwarded.

VHF digital link (VDL). A constituent mobile subnetwork of the aeronautical telecommunication

network (ATN), operating in the aeronautical mobile VHF frequency band. In addition, the VDL may provide non-ATN functions such as, for instance, digitized voice.

ACP/1-DP/3


CHAPTER 3. AERONAUTICAL TELECOMMUNICATION NETWORK

Note 1.— Detailed technical specifications for ATN/OSI applications are contained in the “Manual of Detailed Technical Specifications for the ATN using ISO/OSI standards and protocols” (Doc 9880).

Note 2.— Detailed technical specifications for ATN/IPS applications are contained in the “Manual of Detailed Technical Specifications for the ATN using IPS standards and protocols” (Doc xxxx) [in preparation].

3.1 DEFINITIONS Application entity (AE). An AE represents a set of OSI communication capabilities of a particular

application process. (Re. ISO Doc. 9545 for further details) ATN security services. A set of information security provisions allowing the receiving end system or

intermediate system to unambiguously identify (i.e. authenticate) the source of the received information and to verify the integrity of that information.

Required communication performance (RCP). A statement of the performance requirements for

operational communication in support of specific ATM functions. Re. Manual on Required Communication Performance (RCP) (Doc. 9869).

ATS interfacility data communication (AIDC). Automated data exchange between air traffic services

units in support of flight notification, flight coordination, transfer of control and transfer of communication.

ATS message handling service (ATSMHS). An ATN application consisting of procedures used to

exchange ATS messages in store-and-forward mode over the ATN such that the conveyance of an ATS message is in general not correlated with the conveyance of another ATS message by the service provider.

ATS message handling system(AMHS). The set of computing and communication resources

implemented by ATS organizations to provide the ATS message handling service. Authorized path. A communication path suitable for a given message category. Data link initiation capability (DLIC). A data link application that provides the ability to exchange

addresses, names and version numbers necessary to initiate data link applications. (Re. Doc. 4444).

3.2 INTRODUCTION

ACP/1-DP/3


The ATN is specifically and exclusively intended to provide digital data communications services to air traffic service provider organizations and aircraft operating agencies in support of:

1) air traffic services communication (ATSC) with aircraft; 2) air traffic services communications between ATS units;

3) aeronautical operational control communications (AOC); and

4) aeronautical administrative communication (AAC).

3.3 GENERAL

Note — The Standards and Recommended Practices in sections 3.4 – 3.8 below define the minimum required protocols and services that will enable the global implementation of the ICAO Aeronautical Telecommunication Network (ATN).

3.3.1 ATN communication services shall support ATN applications.

3.3.2 Requirements for implementation of the ATN shall be made on the basis of regional air navigation agreements. These agreements shall specify the area in which the communication standards for the ATN/OSI or the ATN/IPS are applicable.

3.4 GENERAL REQUIREMENTS

3.4.1 The ATN shall either use International Organization for Standardization (ISO) communication standards for open systems interconnection (OSI) or use the Internet Society (ISOC) communications standards for the Internet Protocol Suite (IPS)

Note.— Interoperability between interconnecting OSI/IPS networks shall be arranged prior to

implementation. 3.4.2 The AFTN/AMHS gateway shall ensure the interoperability of AFTN and CIDIN stations and networks with the ATN.

3.4.3 Authorized path(s) shall be defined on the basis of a pre-defined routing policy. 3.4.4 The ATN shall transmit, relay and (or) deliver messages in accordance with the priority

classifications and without discrimination or undue delay. 3.4.5 The ATN shall provide means to define data communications that can be carried only over authorized paths for the traffic type and category specified by the user.

ACP/1-DP/3


3.4.6 The ATN shall provide communication in accordance with the prescribed required

communication performance (RCP) (Manual on Required Communication Performance (Doc. 9896) refers)

3.4.7 The ATN shall operate in accordance with the communication priorities defined in ∗Table 3-1 and Table 3-2.

3.4.8 The ATN shall enable exchange of application information when one or more authorized paths exist.

3.4.9 The ATN shall notify the appropriate application processes when no authorized path exists.

3.4.10 The ATN shall make provisions for the efficient use of limited bandwidth subnetworks.

3.4.11 Recommendation. The ATN should enable an aircraft intermediate system (router) to connect to a ground intermediate system (router) via different subnetworks.

3.4.12 Recommendation. The ATN shoud enable an aircraft intermediate system (router) to connect to different ground intermediate systems (routers).

3.4.13 The ATN shall enable the exchange of address information between applications.

3.4.14 Where the absolute time of day is used within the ATN, it shall be accurate to within 1 second of coordinated universal time (UTC).

Note.— The time accuracy value results in synchronization errors of up to two seconds.

3.5 ATN APPLICATIONS REQUIREMENTS

3.5.1 System applications Note.— System applications provide services that are necessary for operation of the ATN.

3.5.1.1 The ATN shall support the Data Link Initiation Capability (DLIC) applications as contained in Doc. 9694 (Manual on ATS Data link applications Part I) when air-ground data links are implemented.

3.5.1.2 The ATN/OSI end system shall support the following DIR application functions when AMHS and/or security protocols are implemented (Re. ITU-T X.500 series):

a) directory information retrieval; and

b) directory information modification .

∗ Tables 3-1 and 3-2 are located at the end of this chapter.

ACP/1-DP/3


3.5.2 Air-ground applications

3.5.2.1 The ATN shall be capable of supporting on or more of the following applications, in accordance with the provisions of Doc 9694:

a) ADS-C;

b) CPDLC; and

c) FIS (including ATIS and METAR).

3.5.3 Ground-ground applications

3.5.3.1 The ATN shall be capable of supporting: AIDC applications as contained in Doc. 9694 and ATS message handling services application (ATSMHS).

3.6 ATN COMMUNICATION SERVICE REQUIREMENT

3.6.1 ATN/IPS upper layer communication service.

3.6.1.1 An ATN host∗ shall be capable of supporting the ATN/IPS upper layers including an application layer.

3.6.2 ATN/OSI upper layer communications service.

3.6.2.1 An ATN/OSI end system (ES)∗ shall be capable of supporting the OSI upper layer communications service (ULCS) including session, presentation and application layers.

Note.— The detailed technical specifications for OSI ULCS are defined in Doc. 9705.

3.6.3 ATN/IPS Internet Communication Service.

3.6.3.1 An ATN host shall be capable of supporting the ATN/IPS Internet including the: a) transport layer in accordance with RFC 793 (TCP) and RFC 768 (UDP); and

∗ An ATN host is an ATN end system in OSI terminology; an ATN end-system is an ATN host in IPS terminology.

ACP/1-DP/3


b) network layer in accordance with RFC 2460 (IPv6). 3.6.3.2 An IPS Router shall support the ATN network layer in accordance with RFC 2460 (IPv6)

and RFC 4271 (BGP), and RFC 2858 (BGP multiprotocol extensions). 3.6.4 ATN/OSI Internet communications service. 3.6.4.1 An ATN/OSI end system shall be capable of supporting the ATN Internet including the: a) transport layer in accordance with ISO/IEC 8073 (TP4) and ISO/IEC 8602 (CLTP); and

b) network layer in accordance with ISO/IEC 8473 (CLNP).

3.6.4.2 An ATN intermediate system (IS) shall support the ATN network layer in accordance with

ISO/IEC 8473 (CLNP) and ISO/IEC 10747 (IDRP).

3.7 ATN NAMING AND ADDRESSING REQUIREMENTS

Note.— The ATN naming and addressing scheme supports the principles of unambiguous identification of intermediate systems (routers) and end systems (hosts) and provides global address standardization.

3.7.1 The ATN shall provide provisions for unambiguous application identification.

3.7.2 The ATN shall provide provisions for unambiguous addressing.

3.7.3 The ATN shall provide means to unambiguously address al ATN end systems (hosts) and intermediate systems (routers).

3.7.4 The ATN addressing and naming plans shall allow States and organizations to assign addresses and names within their own administrative domains.

3.8 ATN SECURITY REQUIREMENTS

3.8.1 The ATN shall make provisions whereby only the controlling ATS unit may provide ATC instructions to aircraft operating in its airspace.

Note — This is achieved through the current and next data authority aspects of the

controller-pilot data link communications (CPDLC) application.

3.8.2 The ATN shall enable the recipient of a message to identify the originator of that message.

ACP/1-DP/3


3.8.3 ATN end systems supporting ATN security services shall be capable of authenticating the identity of peer end systems, authenticating the source of messages and ensuring the data integrity of the messages.

Note.— A request for non-use of protection may be honoured. This means that the use of security is the default and negotiation to non-use is based on local policy.

3.8.4 The ATN services shall be protected against service attacks to a level consistent with the application service requirements.

Table 3-1. Mapping of ATN communication priorities

Corresponding protocol priority

Message categories

ATN application

Transport

layer priority

Network layer

priority Network/systems management

SM

0

14

Distress communications

1

13 Urgent communications

2

12

High-priority flight safety messages

CPDLC, ADS

3

11 Normal-priority flight safety messages

AIDC, ATIS

4

10

Meteorological communications

METAR

5

9 Flight regularity communications

CM, ATSMHS

6

8

Aeronautical information service messages

7

7 Network/systems administration

SM, DIR

8

6

Aeronautical administrative messages

9

5 <unassigned>

10

4

Urgent-priority administrative and U.N. Charter communications

11

3

High-priority administrative and State/Government communications

12

2

Normalpriority administrative communications

13

1

Lowpriority administrative communications and aeronautical passenger communications

14

0

Note. The network layer priorities shown in the table apply only to connectionless network priority and do not apply to subnetwork priority.

ACP/1-DP/3


Table 3-2. Mapping of ATN network priority to mobile subnetwork priority

Message categories

ATN network layer priority

Corresponding mobile subnetwork priority (see Note 4)

AMSS

VDL

Mode 2

VDL

Mode 3

VDL

Mode 4 (see Note 5)

SSR

Mode S

HFDL

Network/systems management

14

14

see Note 1

3

14

high

14

Distress communications

13

14

see Note 1

2

13

high

14

Urgent communications

12

14

see Note 1

2

12

high

14

High-priority flight safety messages

11

11

see Note 1

2

11

high

11

Normal-priority flight safety messages

10

11

see Note 1

2

10

high

11

Meteorological communications

9

8

see Note 1

1

9

low

8

Flight regularity communications

8

7

see Note 1

1

8

low

7

Aeronautical information service messages

7

6

see Note 1

0

7

low

6

Network/systems administration

6

5

see Note 1

0

6

low

5

Aeronautical administrative messages

5

5

not allowed

not allowed

not allowed 5

not allowed

not allowed

<unassigned>

4

unassigned

unassigned

unassigned

unassigned 4

unassigned

unassigned

Urgent-priority administrative and U.N. Charter communications

3

3

not allowed

not allowed

not allowed 3

not allowed

not allowed

High-priority administrative and State/Government communications

2

2

not allowed

not allowed

not allowed 2

not allowed

not allowed

Normal-priority administrative communications

1

1

not allowed

not allowed

not allowed 1

not allowed

not allowed

Low-priority administrative communications and aeronautical passenger communications

0

0

not allowed

not allowed

not allowed 0

not allowed

not allowed

Note 1.— VDL Mode 2 has no specific subnetwork priority mechanisms. Note 2.— The AMSS SARPs specify mapping of message categories to subnetwork priority without explicitly referencing ATN network layer priority. Note 3.— The term “not allowed” means that only communications related to safety and regularity of flight are authorized to pass over this subnetwork as defined in the subnetwork SARPs. Note 4.— Only those mobile subnetworks are listed for which subnetwork SARPs exist and for which explicit support is provided by the ATN boundary intermediate system (BIS) technical provisions. Note 5.— The VDL Mode 4 subnetwork provides support for surveillance applications (e.g. ADS).

— — — — — — — —

ACP/1-DP/3

Appendix C to the Report on Agenda Item 3 3C-1

ENGLISH ONLY

APPENDIX C

AERONAUTICAL TELECOMMUNICATION NETWORK (ATN)

MANUAL ON DETAILED TECHNICAL SPECIFICATION FOR THE INTERNET PROTOCOL SUITE (IPS) COMMUNICATION SERVICE

PREPARED BY: ICAO ACP WG-N (N1)

20 APRIL 2007-05-06

VERSION 11

ACP/1-DP/3

3C-2 Appendix C to the Report on Agenda Item 3

FOREWORD

This document defines the requisite data communication protocols and services to be used for implementing the International Civil Aviation Organization (ICAO) Aeronautical Telecommunications Network (ATN) using the Internet Protocol Suite (IPS). The material in this document is to be considered in conjunction with the relevant Standards and Recommended Practices (SARPs) as contained in Annex 10, Volume III, Part I Chapter 3. Editorial practices in this document. The detailed technical specifications in this document that include the operative verb “shall” are essential to be implemented to secure proper operation of the ATN. The detailed technical specifications in this document that include the operative verb “should” are recommended for implementation in the ATN. However, particular implementations may not require this specification to be implemented. The detailed technical specifications in this document that include the operative verb “may” are optional. The use or non use of optional items shall not prevent interoperability between ATN/IPS nodes.

ACP/1-DP/3


1. INTRODUCTION

1.1 General overview

1.1.1 This manual contains the minimum communication protocols and services that will enable implementation of an ICAO Aeronautical Telecommunication Network (ATN) based on the Internet Protocol Suite (IPS) utilizing Internet Protocol version 6 (IPv6).

1.1.2 Implementation of IPv4 in ground subnetworks, for transition to IPv6 (or as a permanent subnetwork) is a regional or local issue, and is not addressed in this manual. IPv6 is to be implemented in air-ground subnetworks. The scope of the manual is on inter-domain routing, although the material in this manual can also be used for intra-domain routing (e.g. within an Administrative Domain).

1.1.3 The IPS in the ATN architecture is illustrated in Figure 1.

AP

TCP/UDP

IP

Media Access

IP

Media Access

TCP/UDP

Application

i.e. LAN/WAN, ... i.e. LAN/WAN, ...

IPv6/BGP4+

AP

Application

IPv6/BGP4+

External Internet Communications

Services

Application Process

ATN Application

TCP/UDP

Inter-Domain Router

Inter-Domain Router

Intra-Domain Intra-Domain

OSI/IPS Convergence

OSI/IPS Convergence

Peer Connections

Peer Connections

Figure 1: IPS Architecture in the ATN

1.1.4 In accordance with Annex 10, Volume III, Part I, paragraph [3.3.3] implementation of the ATN/IPS, including the protocols and services included in this manual, shall take place on the basis of regional air navigation agreements between ICAO contracting States. Regional planning and implementation groups (PIRG’s) are coordinating such agreements.

ACP/1-DP/3


2. REFERENCE DOCUMENTS

2.1 IETF Standards

2.1.1 The following documents form part of this manual to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this manual, the provisions of this manual shall take precedence.

Request for comments (RFCs)

RFC-768 User Datagram Protocol, August 1980. RFC-793 Transmission Control Protocol (TCP), September 1981. RFC-1323 TCP Extensions for High Performance May 1992. RFC-1981 Path Maximum Transmission Unit (MTU) Discovery for IP Version 6, August 1996. RFC-2401 Security Architecture for the Internet Protocol, November 1998. RFC-4302 Internet Protocol (IP) Authentication Header, December 2005. RFC-4303 IP Encapsulating Security Payload (ESP), December 2005. RFC-2410 The NULL Encryption Algorithm and Its Use with IPsec, November 1998. RFC-2460 Internet Protocol, Version 6 (IPv6) Specification, December 1998. RFC-2474 Differential Services Field, December 1998. RFC-2488 Enhancing TCP over Satellite Channels, January 1999. RFC-2858 Border Gateway Protocol (BGP4) Multiprotocol Extensions June 2000. RFC-4271 A Border Gateway Protocol 4 (BGP-4), January 2006. RFC-4291 IP Version 6 Addressing Architecture, February 2006. RFC-4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security

Payload (ESP) and Authentication Header (AH) – (NB proposed standard, obsoletes RFC-2402, RFC-2406), December 2005.

RFC-4306 Internet Key Exchange (IKEv2) Protocol, December 2005. RFC-4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),

December 2005. RFC-4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)

Specification, March 2006.

2.2 Relevant ICAO publication

2.2.1 In the event of a conflict between the manual and the provisions in Annex 10, the provisions of Annex 10 shall take precedence.

ICAO Annex 2 Rules of the Air ICAO Annex 3 Meteorological Service for International Air Navigation ICAO Annex 10 Aeronautical Telecommunications – Volume III, Part I – Digital Data Communication Systems ICAO Annex 11 Air Traffic Services ICAO Doc. 9705-AN/956 Edition 3, Manual of Technical Provisions for the ATN, 2002 ICAO Doc. 9739 Edition 1, Comprehensive ATN Manual (CAMAL), 2000 ICAO Doc. 4444 Procedures for Air Navigation Services – Air Traffic Management 14th Edition, 2001 ICAO Doc. 9694 Manual of Air Traffic Services Data Link Applications

ACP/1-DP/3


ICAO Doc. 9880 Detailed Technical Specifications for the Aeronautical Telecommunication Network (ATN) using ISO/OSI protocols (Doc. 9880 replaces Doc. 9705).

3. ABBREVIATIONS

3.1 The acronyms used in this manual are defined as follows:

AAC Aeronautical Administrative Communications AOC Aeronautical Operational Communications AS Autonomous System AD Administrative Domain AH Authentication Header AINSC Aeronautical Industry Service Communication ATN Aeronautical Telecommunication Network ATSC Air Traffic Services Communication BGP Border Gateway Protocol CL Connection-less CO Connection-oriented ECP Encryption Control Protocol ESP Encapsulating Security Protocol G-G Ground- to- Ground IANA Internet Assigned Numbers Authority ICAO International Civil Aviation Organization ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IKEv2 Internet Key Exchange (version2) IP Internet Protocol IPS Internet Protocol Suite IPv6 Internet Protocol version 6 ISO International Organization for Standardization LAN Local Area Network MTU Maximum Transmission Unit OSI Open System Interconnection QoS Quality of Service RFC Request for Comments TCP Transmission Control Protocol SARPs Standards and Recommended Practices SPI Security Parameter Index UDP User Datagram Protocol WAN Wide Area Network

3.2 Definitions

Note. — Definitions are consistent with IETF terminology.

Autonomous System. A connected group of one or more IP prefixes, run by one or more network operators, which has a single, clearly defined routing policy.

ACP/1-DP/3


Host. A host is a computer connected to the ATN that provides end users with services; in addition,

a host can function as a router. (Note: In OSI terminology, a host is and end system and a router is an intermediate system).

Internet. A worldwide computer communications network that interconnects WANs, LANs, and computers by adopting common interface services and protocols based on the TCP/IP technology.

LAN. A network that interconnects hosts over short distances.

Network. Collection of computers, printers, routers, switches, and other devices that communicate with each other over a common transmission medium.

Node. A device that implements IPv6

Protocol.A set of rules and formats (semantic and syntactic) which determine the communication behavior between peer entities in the performance of functions at that layer.

Router. The communication element that manages the relaying and routing of data while in transit from an originating end system to a destination end system.

Inter-Domain Routing (Exterior Routing Protocol). Protocols for exchanging routing information between ASes. They may in some cases be used between routers within an AS, but they primarily deal with exchanging information between ASes.

Intra-Domain Routing (Interior Routing Protocol). Protocols for exchanging routing information between routers within an AS.

WAN. A computer network that spans a large geographical area.

4. REQUIREMENTS

4.1 ATN/IPS administration

The AtN/IPS Internet

4.1.1 The ATN/IPS internet consists of IPS nodes and networks operating in a multinational environment. The ATN/IPS internet is capable of supporting Air Traffic Service Communication (ATSC) as well as Aeronautical Industry Service Communication (AINSC), such as Aeronautical Administrative Communications (AAC) and Aeronautical Operational Communications (AOC).

4.1.2 There are two types of IPS nodes in the ATN. An IPS Router is an IPS node that forwards Internet Protocol (IP) packets not explicitly addressed to itself. An IPS host is an IPS node that is not a router.

4.1.3 The ATN/IPS internet consists of a set of interconnected Administrative Domains (AD). From a management perspective, an Administrative Domain can be an individual State, or a group of States. From a physical perspective, an Administrative Domain is a group of hosts, routers, and networks

ACP/1-DP/3


operated and managed by a single organization. An Administrative Domain is viewed from the outside, for purposes of routing, as a cohesive entity.

4.2 Administrative domains

4.2.1 Each State participating in the ATN/IPS internet shall operate one or more Administrative Domains or form part of an Administrative Domain containing one or more Inter-domain Routers as required to interconnect with Inter-domain Routers in other ground-based Administrative Domains.

Note. 1— An Administrative Domain consists of one or more Autonomous Systems. Note. 2 — The routing protocol within an Administrative Domain is local matter

determined by the managing organization.

4.3 Physical layer and ink layer requirements

4.3.1 The specification of the physical and link layer characteristics for a node is local to the interfacing nodes.

4.4 Network Layer requirements

IPv6 Networking

4.4.1 IPS nodes in the ATN shall implement IPv6 as specified in RFC-2460.

4.4.2 IPS nodes shall implement IPv6 Maximum Transmission Unit (MTU) path discovery as specified in RFC-1981.

4.4.3 The Flow Label field is not used in the ATN, and shall be set to zero.

Network addressing

4.4.4 Administrative Domains shall use globally scoped IPv6 addresses for IPS nodes.

Note. — ICAO is developing an IPv6 Addressing Plan.

4.4.5 The ATN/IPS shall implement IP Version 6 Addressing Architecture as specified in RFC-4291.

Inter-domain routing

4.4.6 IPS routers in the ATN/IPS which support inter-domain dynamic routing shall implement version 4 of the Border Gateway Protocol (BGP4) as specified in RFC-4271.

4.4.7 IPS routers in the ATN which support inter-domain dynamic routing shall implement the BGP-4 Multiprotocol Extensions as specified in RFC-2858.

ACP/1-DP/3


4.4.8 Administrative Domains shall be assigned AS numbers for ATN/IPS routers that implement BGP-4.

Note. — ICAO is developing an AS numbering plan.

4.4.9 IPS routers in the ATN/IPS which support inter-domain dynamic routing should authenticate routing information exchanged between them.

Error detection and reporting

4.4.10 IPS nodes shall implement Internet Control Message Protocol (ICMPv6) as specified in RFC-4443.

Quality of service (QoS)

4.4.11 The IPS shall provide the required class of service to support the operational requirements.

4.4.12 IPS Routers, which support traffic class, shall implement Differential Services Field as specified in RFC-2474.

4.5 Transport layer requirements

End to end services

4.5.1 The transport layer provides end-to-end service between hosts over the ATN.

Support services

4.5.2 The transport layer supports the following types of services:

— Connection-Oriented (CO), invoking TCP.

— Connection-Less (CL), invoking UDP.

Transmission control protocol (TCP)

4.5.3 IPS host shall implement Transmission Control Protocol (TCP) as specified in RFC-793.

4.5.4 IPS host may implement TCP Extensions for High Performance as specified in RFC-1323.

4.5.5 IPS host may implement RFC-2488 when operating over satellite links.

User datagram protocol (UDP)

4.5.6 IPS host shall implement User Datagram Protocol as specified in RFC-768.

ACP/1-DP/3


5. NETWORK LAYER SECURITY

Note 1.— Support for security is to be based on a system threat and vulnerability analysis.

Note 2.— Network layer security in the ATN/IPS internet is implemented using IPsec.

5.1 Basic architecture

5.1.1 IPS nodes in the ATN which support network layer security shall implement the Security Architecture for the Internet Protocol as specified in RFC-4301.

5.2 Security protocols

5.2.1 IPS nodes in the ATN which support network layer security shall implement the IP Encapsulating Security Protocol (ESP) as specified in RFC-4303.

5.2.2 IPS nodes in the ATN which support network layer security should implement the IP Authentication Header (AH) protocol as specified in RFC-4302.

5.3 Key management methods

5.3.1 IPS nodes in the ATN which support network layer security shall implement manual configuration of the security key and Security Parameters Index (SPI).

5.3.2 IPS nodes in the ATN which support network layer security should implement The Internet Key Exchange (IKEv2) Protocol. as specified in RFC-4306.

5.4 Transforms and algorithms

5.4.1 IPS nodes in the ATN which support network layer security shall implement the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH) as specified in RFC-4305.

5.4.2 IPS nodes in the ATN which support network layer security shall implement The Null Encryption Algorithm and Its Use With IPsec as specified in RFC-4305, but not the Null Authentication Algorithm.

Note. — ESP encryption is optional, but authentication is always performed.

5.4.3 IPS nodes in the ATN which support network layer security shall implement the Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) required algorithms for key exchange as specified in RFC-4307.

Note. — Algorithms of equivalent or greater strength than those identified in RFC-4307 are implemented as a local matter on a bi-lateral basis.

— — — — — — — —

ACP/1-DP/3

Appendix D to the Report on Agenda Item 3 3D-1

ENGLISH ONLY

APPENDIX D

PHYSICAL LAYER AND INK LAYER REQUIREMENTS Editorial Note.— This paper incorporates editorial changes from to the output from Subgroup N1 to

WG-N. Two additional approaches presented in Bangkok 2007 have been included in the document.

ACP/1-DP/3

3D-2 Appendix D to the Report on Agenda Item 3

EXECUTIVE SUMMARY

Considering the dominant position of the Internet Protocol Suite (IPS) in the commercial networking environment, the Air Navigation Commission concluded that consideration should be given to whether it was viable for aeronautical applications to make direct use of IPS in the aeronautical environment and gave the Aeronautical Communications Panel (ACP) WG-N (Networking) the task to, “consider the use of TCP/IP protocols in the provision of aeronautical internetworking”. ACP WG-N produced an initial report which was presented at the June 2005 ACP Working Group of the Whole Meeting. The report concluded that use of the IPS in the ground environment appeared to be straightforward and further consideration was to be given with the aim of development of a minimum set of SARPs and Guidance Material necessary to support global interoperability. However for air-ground communications the report noted that technical issues, mainly related to mobility and security aspects associated with the introduction of the IPS in air-ground data link systems, need to be resolved. This report presents an initial analysis of a number of candidate ATN IPS mobility solutions. A set of candidate solutions was identified at the November Sub-Group N1 meeting held in Montreal in November 2005. The candidate solutions identified were in several areas and included: using IETF mobile networking approaches, applying IETF Inter-domain routing protocols or adapting ISO Inter-domain routing protocols, performing mobility at the transport layer, and performing mobility at the application layer. During the January 2007 Sub-Group N1 meeting, 2 additional options have been identified, All candidate approaches are listed in Table ES-1

Table ES-1 Candidate Approaches

Mobile IPv6 (MIPv6) Network Mobility (NEMO)

Border Gateway Protocol (BGP) Inter-Domain Routing Protocol (IDRP)

Open Shortest Path First (OSPF) Stream Control Transmission Protocol (SCTP)

Instant Messaging (IM) Protocols ATN Application Mobility IPSec Tunnel Movement

Link Layer Mobility During the November 2005 meeting Sub-Group N1 also identified a set of Technical and Implementation Characteristics which are used for analysis of each candidate approach. Note that the characteristics have not been identified to select a particular approach but rather to determine if IPS mobility is feasible generally to support the needs of the aviation community. The IETF approaches to mobility Mobile IPv6 and NEMO appear to hold promise for the long term. However, it should be clear that the extensions to MIPv6 and NEMO are still evolving.

An inter-domain routing approach on its own, using BGP, would undoubtedly work, since the current network uses a similar protocol, but concerns centre on the degree of manual configuration required and its responsiveness following network mobility events.

IDRP would also work; however, the community would still be left with an aviation-specific solution.

ACP/1-DP/3


OSPF applied on a single routing domain perspective could be employed to alleviate the convergence issues but there may be administrative issues since it is expected that the ATN will be operated by multiple service providers and administrations.

SCTP is a standard that was not designed for mobility. Many instances of experimentation have demonstrated that SCTP is capable of supporting mobility, and even has some desirable features not found in network-layer solutions, but this type of use is not directly supported by the standards documents or available vendor implementations.

Neither of the two Instant Messaging approaches: XMPP and SIMPLE is directly designed to provide the type of smooth mobility that is under consideration here, although they could be used to provide an ACARS-like service.

An ATN application based approach to mobility has the advantage of a simplified network layer; however, it does not take advantage of COTS solutions.

The IPSec Tunnel Movement mobility option is a COTS solution. It exploits the fact that IPSec tunnels protect against identified threaths and, at the same time, provide a mobility solution by moving the tunnels.

The Link Layer Mobility mobility option can work and is based on a COTS solution using the 3GPP/UMTS specifications. This report concludes that mobility in an IPS environment is feasible. Candidate approaches have their individual strengths in each of the characteristics identified.

ACP/1-DP/3


TABLE OF CONTENTS

AERONAUTICAL TELECOMMUNICATIONS ................................................................................... 1 ANNEX 10 ................................................................................................................................................... 1 VOLUME III ............................................................................................................................................... 1 NOTES ON THE PRESENTATION OF THE PROPOSED AMENDMENT ..................................... 1 The text of the amendment is arranged to show deleted text with a line through it and new text highlighted with grey shading, as shown below: ............................................................................................................. 1 AERONAUTICAL TELECOMMUNICATIONS ................................................................................... 2 ANNEX 10 ................................................................................................................................................... 2 VOLUME III ............................................................................................................................................... 2 AERONAUTICAL TELECOMMUNICATIONS ................................................................................... 1 ANNEX 10 ................................................................................................................................................... 1 VOLUME III ............................................................................................................................................... 1

2.1 Summary of Candidate Approaches for IPS Mobility ..................................................................... 6 2.2 Technical Implementation Characteristics of Candidate Approaches for IPS Mobility ..................... 6

2.2.1 Technical Characteristics ............................................................................................................. 6 2.2.2 Implementation Characteristics.................................................................................................... 7

3.1 Approach N1 – Mobile IPv6 (MIPv6) ................................................................................................ 8 3.1.2.9 IC1 - Addition of Service Providers (SP) ........................................................................ 20 1.1.1.1 3.5.2.9 IC1 - Addition of Service Providers (SP) ...................................................... 37 1.1.1.2 3.5.2.10 IC2 - Independence of SP or Administration ............................................. 37 1.1.1.3 3.6.2.12 IC4 – Mature and Commercially Available................................................ 40

3.7 Approach A1 – Instant Messaging (IM) Protocols ........................................................................... 41 3.8 Approach A2 – ATN Application Mobility ...................................................................................... 44 3.9 Approach A3 – IP Sec Tunnel Movement ........................................................................................ 46

Communications Initiation.............................................................................................................. 47 3.10 Approach L1 Link Layer Mobility............................................................................................. 54

ACP/1-DP/3


Chapter 1.1 Background Considering the dominant position of the Internet Protocol Suite (IPS) in the commercial networking environment, the Air Navigation Commission concluded that consideration should be given to whether it was viable for aeronautical applications to make direct use of IPS in the aeronautical environment and gave the Aeronautical Communications Panel (ACP) WG-N (Networking) the task to, “consider the use of TCP/IP protocols in the provision of aeronautical internetworking”. ACP WG-N produced an initial report which was presented at the June 2005 ACP Working Group of the Whole Meeting [ICAO-1]. The report concluded that use of the IPS in the ground environment appeared to be straightforward and further consideration was to be given with the aim of development of a minimum set of SARPs and Guidance Material necessary to support global interoperability. However for air-ground communications the report noted that technical issues, mainly related to mobility and security aspects associated with the introduction of the IPS in air-ground data link systems, need to be resolved. This report presents an initial analysis of a number of candidate ATN IPS mobility solutions. An initial set of candidate solutions was identified in a working paper [SG N1 WP 0507] presented at the November Sub-Group N1 meeting held in Montreal in November 2005. The candidate solutions identified were in several areas and included: using IETF mobile networking approaches, applying IETF Inter-domain routing protocols or adapting ISO Inter-domain routing protocols, performing mobility at the transport layer, and performing mobility at the application layer. At the March Sub-Group N1 meeting held in Malmo, Sweden it was proposed that an IETF Intra-Domain routing protocol might be used for mobility at least for ground distribution of routes [SG N1 WP 705]. During the January 2007 Sub-Group N1 meeting, 2 additional options have been identified in [SG N1 IP 12 08]. These documents together with the initial WP 507 forms the candidate set of solutions in this paper. Working paper [SG N1 WP 506] was also presented at the November 2005 meeting. This working paper proposed a set of High Level Requirements and Characteristics to be used in the analysis of the candidate solutions. During the meeting these items were evolved to a set of Technical and Implementation Characteristics [SG N1 WP 0506a]. This set is used in this report. This paper in its current form has been developed over a number of SG N1 meetings since November 2005 by several SG N1 members. The following papers were also used in developing this report:

[SG N1 IP 0701] “Mobile Networking” [SG N1 WP 0707] “Standards and Maturity Guidance on Mobility Techniques” [SG N1 WP 0715] “Migration to IPv6 for ATM Air/Ground data communication” [BOEING-1] “Global IP Network Mobility using Border Gateway Protocol (BGP)” [BOEING-2] “Global_IP_Mobility_IETF62”

ACP/1-DP/3


Chapter 2.2 Introduction

2.1 Summary of Candidate Approaches for IPS Mobility

Table 2.1-1 summarizes the approaches to IPS mobility that are analyzed in this paper. The IETF mobile networking approaches, Mobile IPv6 and Network Mobility, are identified as N1 and N2 respectively. The routing approaches analyzed are the IETF inter-domain routing protocol BGP (R1), the ISO inter-domain routing protocol IDRP (R2) and the IETF intra-domain routing protocol OSPF (R3). SCTP (T1) is analyzed as a possible transport layer approach, There are three application layer approaches. One is to use IETF Instant Messaging protocols (A1); the second is to develop an ATN Application Mobility solution (A2); and the third is based on IPSec Tunnel Movement (A3). There is also a Link Layer Mobility option which is based on the 3GPP/UMTS specifications (L1).

Table 2.1-1 Candidate Approach Summary Identifier Candidate Approach Section

N1 Mobile IPv6 (MIPv6)** 3.1 N2 Network Mobility (NEMO) 3.2 R1 Border Gateway Protocol (BGP) 3.3 R2 Inter-Domain Routing Protocol (IDRP)* 3.4 R3 Open Shortest Path First (OSPF) 3.5 T1 Stream Control Transmission Protocol (SCTP) 3.6 A1 Instant Messaging (IM) Protocols 3.7 A2 ATN Application Mobility 3.8 A3 IPSec Tunnel Movement 3.9 L1 Link Layer Mobility 3.10

*The current ATN IDRP approach is described in Appendix A ** An overview of Mobile IP is provided in Appendix B

2.2 Technical Implementation Characteristics of Candidate Approaches for IPS Mobility

2.2.1 Technical Characteristics TC.1 The approach should provide a means to define data communications that can be carried only over authorized paths for the traffic type and category specified by the user. Note .— Differentiation of traffic types is required because different data traffic may have different access to sub-networks. The ATN has defined traffic type as a means used to distinguish different types of message traffic for the purposes of establishing communication paths to support operational and legal requirements.

TC.2 The approach should enable an aircraft to both roam between and to be simultaneously connected to multiple independent mobile air/ground sub-networks.

Note. - The need to support multiple concurrent mobile air/ground sub-networks is essentially a requirement to support Global Mobility (also known as Macro Mobility) [RFC 3753].

ACP/1-DP/3


TC.3 The approach should minimize latency during establishment of initial paths to an aircraft, during handoff, and during transfer of individual data packets.

TC.4 The approach should have high availability which includes not having a single point of failure.

TC.5 The approach should not negatively impact end-to-end data integrity, for example, by introducing packet loss during path establishment, handoff or data transfer.

TC.6 The approach should be scaleable to accommodate anticipated levels of aircraft equipage.

Note. - It is not required to support mobility of ground users and thus the scalability requirement is less stringent than for general mobility solutions for the public internet.

TC.7 The approach should result in throughput which accommodates anticipated levels of aircraft equipage.

TC.8 The approach should be secure.

2.2.2 Implementation Characteristics

IC.1 The approach should permit the addition of air/ground service providers.

IC.2 The approach should not rely on a particular air/ground service provider or administration for operation.

IC.3 The approach should not be unique to aviation but rather should be based on open industry standards.

Note. - This does not mean that the approach has to operate over the public internet.

IC.4 The approach should have mature and commercially available implementations.

Note. - The motivation for this characteristic is to take advantage of commercial-off-the-shelf products that have passed the experimental stage.

IC.5 The approach should allow the industry to implement a closed network.

IC.6 The approach should allow authentication to be required for systems to join the closed network.

ACP/1-DP/3


Chapter 3.3 Detailed Analysis

3.1 Approach N1 – Mobile IPv6 (MIPv6) 3.1.1 Approach N1 Description 3.1.1.1 Basic Provisions of MIPv6 [RFC 3775] specifies mobility support in IPv6 which allows nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6, packets destined to a mobile node would not be able to reach it while the mobile node is away from its home link. In order to continue communication in spite of its movement, a mobile node could change its IP address each time it moves to a new link, but the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet during the lifetime of IPv6. The protocol defined in RFC 3775, known as Mobile IPv6 (MIPv6), allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. The Mobile IPv6 protocol is just as suitable for mobility across homogeneous media as for mobility across heterogeneous media. For example, Mobile IPv6 facilitates node movement from one Ethernet segment to another as well as it facilitates node movement from an Ethernet segment to a wireless LAN cell, with the mobile node's IP address remaining unchanged in spite of such movement. One can think of the Mobile IPv6 protocol as solving the network- layer mobility management problem. Some mobility management applications -- for example, handover among wireless transceivers, each of which covers only a very small geographic area -- have been solved using link-layer techniques. For example, in many current wireless LAN products, link-layer mobility mechanisms allow a “handover" of a mobile node from one cell to another, re-establishing link-layer connectivity to the node in each new location. The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4), and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, but is integrated into IPv6 and offers many other improvements. The major differences between Mobile IPv4 and Mobile IPv6 are: • There is no need to deploy special routers as "foreign agents", as in Mobile IPv4. Mobile IPv6

operates in any location without any special support required from the local router. • Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of

extensions. • Mobile IPv6 route optimization can operate securely even without pre-arranged security associations.

It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes.

ACP/1-DP/3


• Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering" [26].

• The IPv6 Neighbor Unreachability Detection assures symmetric reachability between the mobile node and its default router in the current location.

• Most packets sent to a mobile node while away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of resulting overhead compared to Mobile IPv4.

• Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbor Discovery [12] instead of ARP. This also improves the robustness of the protocol.

• The use of IPv6 encapsulation (and the routing header) removes the need in Mobile IPv6 to manage "tunnel soft state".

• The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node. The directed broadcast approach used in IPv4 returns separate replies from each home agent.

RFC 3775 defines the base security provisions for Mobile IPv6. These include the protection of Binding Updates both to home agents and correspondent nodes, the protection of mobile prefix discovery, and the protection of the mechanisms that Mobile IPv6 uses for transporting data packets. Mobile Node-Home Agent Protection Binding Updates are protected by the use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key, Kbm, which can be established through the return routability procedure. Mobile prefix discovery is protected through the use of IPsec extension headers. RFC 3775 requires that manual configuration of IPsec security associations be supported. It defines a process using random shared secrets which are unique for different mobile nodes, and which are distributed off-line to the mobile nodes. RFC 3775 specifies that automatic key management with IKE may also be supported. RFC 3776 is a supplement to RFC 3775. RFC 3776 specifically addresses using IPsec to protect Mobile IPv6 signaling between Mobile Nodes and Home Agents in more depth than RFC 3775. It also illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. Mobile Node-Correspondent Node Protection RFC 3775 defines a procedure for protection of Mobile Node-Corresondent Node protection when Route Optimization (RO) is used. The Return Routability Procedure enables the correspondent node to obtain “some reasonable assurance” that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address. This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data which the correspondent node sends to those addresses. It should be noted that the Return Routability Procedure is a weak authentication mechanism. RFC 4225 gives an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design.

ACP/1-DP/3


RFC 4225 states that it should be kept in mind that the MIPv6 RO security design was never intended to be fully secure. Instead the goal was to be roughly as secure as non-mobile IPv4 was known to be at the time of the design. 3.1.1.2 Extensions to MIPv6 3.1.1.2.1 Mobile Nodes And Multiple Interfaces in IPv6 (MONAMI6) The objective of the MONAMI6 WG is to develop standard track specifications to support simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support. Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) have been specified by the IETF to support handoffs for IPv6 mobile hosts and routers, respectively. However, these protocols do not today provide standardized support for simultaneous differentiated use of multiple access technologies. Mobile networks are typically connected by means of wireless links and are less reliable. In addition, there may be a number of nodes behind the MR leading to loss of service. In a Mobile Network environment, loss of connectivity or a failure to connect to the Internet has a greater significant impact than for a single mobile node. Multiple interfaces from the mobile nodes or router offer the following benefits: • Permanent and Ubiquitous Access • Reliability • Load Sharing • Load Balancing/Flow Distribution • Preference Settings • Aggregate Bandwidth The techniques required to support multiple interfaces for mobile nodes are presented in a number of draft documents that are currently deemed as “work in progress”. A summary of these drafts documents is presented below. Mobile IPv6 for multiple interfaces (MMI) draft-montavont-mip6-mmi-02.txt Mobile IPv6 allows a Mobile Node (MN) to maintain its IPv6 communications while moving between subnets. The MMI draft document presents issues that need to be addressed so that a MN can use multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and describes the use of Mobile IPv6 to support multiple interfaces. These extensions focus on the MN’s ability to use a backup interface for communications and to spread flows between the MN’s multiple interfaces. Future MNs will probably have multiple interfaces to connect to Internet. While Mobile IPv6 allows a MN to move between subnets, it does not support capabilities to manage mobility between MN’s several interfaces. Assume a MN with two interfaces and at first, the MN connects to the network using one of the interfaces. Then, as the MN moves away from the coverage area of its current point of attachment the

ACP/1-DP/3


MN’s connection to the network through the first interface is lost. In the mean time, if the MN connects to the network using the second interface, it may want all the data flows using the first interface to be automatically redirected to the second interface. In this case, the MN takes advantage of having multiple interfaces by using one of the multiple interfaces as a backup interface. Another example of the use of multiple interfaces in mobile environment is when a MN is moving across different subnets, it may be able to use alternate interfaces for its flows while it completes the transition. This minimizes the impact of the handover on applications. The MMI draft document describes the specific operations needed to perform vertical handovers. In a vertical handover the MN's network interface to the access network changes and a vertical handover is typically an inter-technology handover. The MMI draft describes the use of Mobile IPv6 to perform vertical handovers. In addition, a per-correspondent node mobility is described, which is the ability for the MN to spread its flows on several interfaces with different CNs. It also details the per-flow mobility and operations the MN need to perform to independently manage each flow. Finally, it describes the load balancing capability in a mobile environment, where the MN uses several CoAs and thus interfaces, for the same flow. Multiple Care-of Addresses Registration draft-wakikawa-mobileip-multiplecoa-04.txt In the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, termed the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access using multiple access media simultaneously, in which case multiple active IPv6 care-of addresses would be assigned to the mobile node. This draft proposes Mobile IPv6 extensions designed to register multiple care-of addresses bound to a single home address instead of the sole primary care-of address. To do so, a new identification number is carried in each binding so that the receiver can distinguish between the bindings corresponding to the same home address. Those extensions are targeted toward NEMO (Network Mobility) Basic Support as well as to Mobile IPv6. With multiple interfaces the following capabilities may be supported in a mobile environment: 1. If a Mobile Node loses its Internet connectivity at one of its interface, the second interface can be

used as a backup interface thereby maintaining Internet connectivity. 2. The Mobile Node can send each communications flow to a distinct network interface. This results in

efficient network bandwidth utilization. 3. Multiple interfaces allow a user to select the most suitable network interface per application. 4. Allows the Correspondent Nodes to re-select a binding of the Mobile Node to recover communication

when one of mobile node's bindings becomes invalid. 5. If a Mobile Node does not have enough bandwidth for communications, it can utilize both bindings to

gain network bandwidth. 6. A Mobile Node may bicast packets of a particular flow through all available network

interfaces. However, according to the Mobile IPv6 specification, a mobile node is not allowed to register multiple care-of addresses bound to a single home address. If a mobile node sends Binding Updates for each care-of address, correspondent nodes would always overwrite the care-of address recorded in the binding

ACP/1-DP/3


cache with the one contained in the latest binding update received. It is thus impossible for a mobile node to register multiple care-of addresses in the Correspondent Node's binding cache. MONAMI6 WG proposes a new identification number called Binding Unique Identification number (BID) for each binding cache entry to accommodate multiple bindings registration and also proposes an extension to the binding cache management to store the BID and a new sub-option field in the binding update message to carry the BID. The BID is assigned to either the interfaces or care-of addresses bound to a single home address of a Mobile Node. The Mobile Node notifies the BID to both its Home Agent and Correspondent Nodes by means of a Binding Update. Correspondent Nodes and the Home Agent record the BID into their binding cache. The home address thus identifies a Mobile Node and the BID identifies each binding registered by a Mobile Node. By using the BID, multiple bindings can then be distinguished. The user of a mobile node may be able to bind some policies to a BID. Then, the policy is used to divide flows onto multiple network interfaces based on flow type, port number, or destination address, etc. Filters for Mobile IPv6 Bindings (NOMADv6) draft-nomadv6-mobileip-filters-03.txt Filters for Mobile IPv6 Bindings (NOMADv6) introduce a set of extensions to the MIPv6 protocol that allows intelligent use of multiple points of attachment simultaneously, by a mobile node. It specifies a set of rules (filters) communicated to the binding agents using binding updates. In turn, the binding agents use this information to determine whether and where to route flows associated with the Mobile Node. In this manner, it is possible for a Mobile Node to distribute flows or packets of a flow among its available points of attachment or to request that such flow be dropped before traversing the Internet fabric, with or without notification to their source. The NOMADv6 document extends Mobile IPv6 protocol by introducing a set of rules (called filters) that are transmitted with binding updates by a Mobile Node. When receiving the binding update with filters, a binding agent (Mobile IPv6 entities that can maintain bindings, Home Agent (HA), Correspondent Node (CN), Mobility Anchor Point (MAP)) forwards flows matching the filters defined by a Mobile Node to the point of attachment associated with the respective filter. In this manner it is possible for the Mobile Nodes to use multiple active points of attachment simultaneously and efficiently. This draft defines a series of different filter modules that can be used independently or combined to form complex filters. Such filters are relayed to binding agents during binding updates and are included in signaling as mobility options. Binding agents capable of maintaining filters are called filtering agents. All filters contained in a binding update are associated with the point of attachment (care-of-address) indicated in the binding update. In this manner, filtering agents become aware of the relationship between certain flows and specific bindings. Flows intercepted by, or originating from a Filtering Agent (HA, CN, MAP) will be filtered and individual flows will be forwarded to the care-of address indicated by the respective binding. This enables Mobile Nodes to distribute flows or to distribute packets of a single flow, among their available points of attachment. Mobile IPv6 does not provide facilities for a mobile node to register multiple care-of-addresses for a single home IP address and this is an important functionality to support the filtering capability. Therefore, this draft introduces the `N´ bit to the binding update message. This bit, when set, informs the filtering

ACP/1-DP/3


agent to hold multiple simultaneous binding for the given home address of the Mobile Node and then manipulate the IP traffic based on the filtering rules based on the forwarded mobility options. 3.1.1.2.2 Fast Handovers for Mobile IPv6 (FMIPv6) FMIPv6 is intended to deal with the issues related to data lost during handoff. It attempts to minimize delay associated with movement detection by allowing Mobile Nodes to anticipate their IP layer mobility. This is especially important in commonly deployed link layers which perform a break-before-make handover. The current ATN Air/Ground sub-networks generally do make-before-break; therefore, this is not an issue. However in the future FMIPv6 techniques may be useful for sub-networks which do not operate with make-before-break. 3.1.1.2.3 Heirarchical Mobile IPv6 (HMIPv6) HMIPv6 attempts to deal with problems associated with updating the home agent. HMIPv6 introduces the concept of a Mobility Anchor Point (MAP) in a network visited by a mobile node. The basic concept is that rather than continuously update the Home Agent in the Mobile Node’s Home Network, the Mobile Node can update a MAP located in the Foreign Network as it moves from Access Router to Access Router. The mobile node updates the MAP with a Local (on-link) Care-of Address (LCoA) associated with an Access Router. Once the mobile node binds with the MAP it also obtains a regional Care-of Address (RCoA) associated with the MAP. The Mobile Node updates its Home Agent with the RCoA so that Correspondent Node traffic sent to the Home Agent is tunnelled to the MAP which in turn tunnels it to the current Access Router. The Mobile Node can also perform a form of route optimization by updating the Correspond Node so that the Correspondent Node sends traffic directly to the MAP and the MAP in turn sends traffic to the correct Access Router based on local updates. In the ATN environment one possible way to implement HMIPv6 would be to have Air/Ground service providers operate a MAP and administrations could operate Home Agents in the Backbone. It should be noted that this only provides basic mobility. It does not provide a mechanism for segregation of traffic types over multiple sub-networks. It should also be noted that at this point in time HMIPv6 is still an internet draft and there have only been experimental implementations. 3.1.1.2.4 Security Extensions to Mobile IPv6 3.1.1.2.4.1 Mobile Node-Home Agent Protection Extensions An Alternative Authentication Protocol for Mobile IPv6

RFC 4285 presents an alternate to the RFC 3775 and 3776 Mobile IPv6 security mechanism. RFC 4285 presents a security mechanism for Mobile IPv6 used in third generation networks. RFC 4285 was developed specifically for the Third Generation Partnership Project 2 (3GPP2), which is a collaborative third generation (3G) telecommunications specifications-setting project.

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home

ACP/1-DP/3


Agent. The base Mobile IPv6 specification [RFC3775] specifies the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile Node (MN) and Home Agent (HA) to be secured by the IPsec Security Associations (IPsec SAs) that are established between these two entities RFC 4284 proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The authentication mechanism proposed in RFC 4284 is similar to the authentication mechanism used in Mobile IPv4 [RFC3344]. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. RFC 4284 proposes a solution for securing the Binding Update and Binding Acknowledgment messages between the Mobile Node and Home Agent using a mobility message authentication option that is included in these messages. Such a mechanism enables IPv6 mobility in a host without having to establish an IPsec SA with its Home Agent. A Mobile Node can implement Mobile IPv6 without having to integrate it with the IPsec module, in which case the Binding Update and Binding Acknowledgement messages (between MN-HA) are secured with the mobility message authentication option. RFC 4284 presents a lightweight mechanism to authenticate the Mobile Node at the Home Agent or at the Authentication, Authorization, and Accounting (AAA) server in Home network (AAAH) based on a shared-key-based mobility security association between the Mobile Node and the respective authenticating entity. This shared-key-based mobility security association (shared-key-based mobility SA) may be statically provisioned or dynamically created. The confidentiality protection of Return Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) is not provided when these options are used for authentication of the Mobile Node to the Home Agent. Thus, unless the network can guarantee such protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option. IKEv2 Mobility and Multihoming Working Group (MOBIKE) There has been some interest in the IPsec working group to add features to IKEv2 (Internet key exchange) to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. This work is being performed by the IKEv2 Mobility and Multihoming Working Group (MOBIKE). The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The MOBIKE working group's goal has produced [RFC 4555] which describes the MOBIKE protocol.

ACP/1-DP/3


3.1.1.2.4.2 Mobile Node-Correspondent Node Protection Extensions Cryptographically Generated Addresses and Credit-Based Authorization The Mobility for IP: Performance, Signaling, and Handoff Optimization (MIPSHOP) group works on improvements to Mobile IP. There have been several proposals to improve upon the Return Routability procedure defined in MIPv6 (RFC 3775), both in terms of the security of the mechanism as well as with respect to its performance. The MIPSHOP group is working on an internet draft [MPSHOP_1] which specifies two techniques for improving security of route optimization as alternatives to the Return Routability Procedure. More specifically [MPSHOP_1] amends the Mobile IPv6 base specification by two optional, optimizations to the return routability procedure. The first optimization enables unidirectional or mutual authentication based on a cryptographically generated home address. This replaces the weaker authentication through pure reachability verification at a home address. The second optimization allows a correspondent node to securely verify a mobile node's reachability at a new care-of address while it already sends data packets to that care-of address. The two optimizations can be applied separately or together. 3.1.2 Approach N1 Analysis 3.1.2.1 TC1 - Support Authorized Traffic Type and Category IPv6 protocol suite supports “Traffic Class” and “Flow Label” capabilities that allow one to distinguish different types of message traffic. Quality-of-Service (QoS) is most easily managed at the mobile source because the source has the greatest knowledge of the available links. Today’s IP routers can do traffic shaping, packet marking, queue management relatively easily. QoS capabilities such as Resource Reservation Protocol (RSVP) and diffServ offer ample opportunity to establish communication paths to support operational and legal requirements. Even though the upper layers support these capabilities, to take advantage of the higher level capabilities the subnetwork need to support similar capabilities. Otherwise one is limited by the services provided by the subnetwork. The Mobile Nodes and Multiple Interfaces in IPv6 (monami6) working group of the IETF is currently working on a protocol extension to Mobile IPv6 and NEMO Basic Support (RFC 3963) to support the registration of multiple Care-of Addresses at a given Home Agent address. In addition, a "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address will be defined. This “flow/binding policy exchange” will enable one to address support of authorized traffic type and category using mipv6 and NEMO. Filters for Mobile IPv6 Bindings (NOMADv6) introduce a set of extensions to the MIPv6 protocol that allows intelligent use of multiple points of attachment simultaneously, by a mobile node. It specifies a set of rules (filters) and the binding agents use this information to determine whether and where to route flows associated with the Mobile Node. In this manner, it is possible for a Mobile Node to distribute flows or packets of a flow among its available points of attachment or to request that such flow be dropped before traversing the Internet fabric, with or without notification to their source. A series of different filter modules are defined that can be used independently or combined to form complex filters.

ACP/1-DP/3


The filters can be used to differentiate traffic types as different data traffic may have different access to sub-networks. In addition, the filter capability will be able to support the ATN has defined traffic type as a means used to distinguish different types of message traffic for the purposes of establishing communication paths to support operational and legal requirements. Note that the filter capabilities are more powerful than the ATN requirements. 3.1.2.2 TC2 - Multiple Independent Air/ground Sub-Networks RFC 3775 specifies that a mobile node may form new non-primary care-of addresses even when it has not switched to a new default router. A mobile node can have only one primary care-of address at a time (which is registered with its home agent), but it may have an additional care-of-address for any or all of the prefixes on its current link. Furthermore, since a wireless network interface may actually allow a mobile node to be reachable on more than one link at a time (i.e., within wireless transmitter range of routers on more than one separate link), a mobile node may have care-of addresses on more than one link at a time. A mobile node may use more than one care-of address at a time. Particularly in the case of many wireless networks, a mobile node effectively might be reachable through multiple links at the same time (e.g., with overlapping wireless cells), on which different on-link subnet prefixes may exist. The mobile node must ensure that its primary care-of address always has a prefix that is advertised by its current default router. After selecting a new primary care-of address, the mobile node must send a Binding Update containing that care-of address to its home agent. The Binding Update must have the Home Registration (H) and Acknowledge (A) bits set its home agent. To assist with smooth handovers, a mobile node should retain its previous primary care-of address as a (non-primary) care-of address, and should still accept packets at this address, even after registering its new primary care-of address with its home agent. This is reasonable, since the mobile node could only receive packets at its previous primary care-of address if it were indeed still connected to that link. If the previous primary care-of address was allocated using stateful Address Autoconfiguration, the mobile node may not wish to release the address immediately upon switching to a new primary care-of address. The objective of the MONAMI6 WG is to develop standards track specifications to support simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support. By adding this capability MONAMI specification supports concurrent mobile air/ground sub-networks and hence support Multi-homing. In addition, MONAMI6 also supports other capabilities over and above the multihoming capability. Mobile IPv6 allows a Mobile Node (MN) to maintain its IPv6 communications while moving between subnets. The MMI draft document presents issues that need to be addressed so that a MN can use multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and describes the use of Mobile IPv6 to support multiple interfaces. These extensions focus on the MN’s ability to use a backup interface for communications and to spread flows between the MN’s multiple interfaces. 3.1.2.3 TC3 - Minimal Latency Specifying latency is more complex for the following reason. In the mobile-ip environment, there are many components one needs to take into account. Three of these are:

ACP/1-DP/3


• The path between Mobile Node to the Home Agent. • The path between the Corresponding Node and the Home Agent • The path between the Mobile Node and the Correspondent Node For mobile-ipv6, route optimization is the normal mode of operation (e.g. direct communication between the Mobile Node and Corresponding Node). As such, latency is not as much of a concern as for the NEMO basic approach where all communication has to transverse the mobile router / home agent path. . In addition, latency is a function of message size, capacity of the link, link utilization and the characteristics of the links that make up the path. To get a handle on the latency one needs to develop a reference architecture and make assumptions about the links to come up with a quantitative result Furthermore, one needs to assess the mobile-ip registration and handover times for given links and architectures. These are highly affected by the internal timer settings. In real-world radio systems, historicise is often implemented to avoid flapping interfaces (where one oscillates between interfaces that appear good and then fade). Such historicise may be on the order of 10s of seconds. Note, such techniques are independent of mobile-ip or even Internet Protocols. A second scenario is when the Mobile router communicates to the Correspondent node. In this environment, a direct path can be established between the Mobile router and Correspondent node using the route optimization technique supported by the Mobile IPv6 protocol. Therefore, the latency in this environment is better than the one address before. 3.1.2.4 TC4 - High Availability Availability is only as good as the availability of the links being used. The ability to use multiple links increases the availability. Mobile IPv6 provides support for multiple home agents, and a limited support for the reconfiguration of the home network. In these cases, the mobile node may not know the IP address of its own home agent and even the home subnet prefixes may change over time. A mechanism, known as "dynamic home agent address discovery" allows a mobile node to dynamically discover the IP address of a home agent on its home link, even when the mobile node is away from home. Mobile nodes can also learn new information about home subnet prefixes through the "mobile prefix discovery" mechanism. IP routers can be configured for dual-hot standby whereby the home agent of access routers can be configured for hot standby redundancy. Availability is a function of a number of parameters such as the air/ground link characteristics, network topology, redundancy and software mean time to failure etc. Therefore, one has to develop a reference model to develop quantitative results. In addition, availability in the mobile environment is dominated by the link characteristic parameters. Another issue in availability are the single point of failure. Single point of failure can be managed by using redundant configuration. NEMO Basic Support protocol allows a Mobile Router to have a unique Home Address through which it is reachable when it is registered with its Home Agent. This Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be

ACP/1-DP/3


either the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router can have more than one Home Address. The capability to support multiple Home Agents increases the availability by reducing the probability of single point of failure. 3.1.2.5 TC5 - End-to-End Data Integrity Network layer protocols in TCP/IP and ATN are not responsible for End-to-end data integrity. This functionality is supported at the TCP or the TP4 level. In addition, additional data integrity functions to increase the end-to-end data integrity can be provided at the application layer. . 3.1.2.6 TC6 – Scaleable Mobile-ipv6 was design to be able to be used by the mobile phone industry as well as any other mobile node applications. As such, scalability is not an issue. NEMO Basic Support protocol allows the Mobile Router to support gateway function to all the nodes in the Mobile Network to communicate to the rest of the world. In this scenario, all the communications takes place through the Mobile Router’s Home Agent. Hence, all the complexity associated with mobility is in the Home Agent. Therefore, scalability is not a limitation. In the second scenario, the Mobile Router can communicate to a Correspondent Node directly bypassing the Home Agent by using the Route Optimization technique. Again, this communication is similar to the regular IP based communication and therefore, scalability is not an issue. 3.1.2.7 TC7 - Throughput Mobile-ipv6 adds very little overhead to the system and should not limit throughput. From throughput and latency point of view, the critical communication path is the one between the Mobile Router and the Home Agent (See section TC3 - Minimal Latency). This path travels over the air/ground link and hence the throughput to some extend is a function of the capacity of this bandwidth limited air/ground link. It is our understanding that the NEMO Basic Support protocol should not limit the throughput. 3.1.2.8 TC8 – Secure One of the reasons why the basic mobile-ipv6 specification went through numerous iterations and an additional 12 to 24 months before consensus was reached on the specification was due to the numerous security issues that were investigated and resolved. RFC 3775 provides a number of security features. These include the protection of Binding Updates both to home agents and correspondent nodes, the protection of mobile prefix discovery, and the protection of the mechanisms that Mobile IPv6 uses for transporting data packets. Binding Updates are protected by the use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key which can be established through the return routability procedure. Mobile prefix discovery is protected through the use of IPsec extension headers. Mechanisms related to transporting payload packets - such as the Home Address

ACP/1-DP/3


destination option and type 2 routing header - have been specified in a manner which restricts their use in attacks. Before decapsulating the tunneled packet, the Mobile Router has to check to see the Source address on the outer IPv6 header is the Home Agent’s address. This check is not necessary if IPsec protects the packet in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it is not, it should drop the packet. All the signaling messages between the Mobile Router and the Home Agent must be authenticated by IPsec. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification. The signaling messages described in this document extend Mobile IPv6 messages and do not require any changes to what is described in RFC 3776, The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular, the Mobile Router should check that the IP source addresses in the packets received belong to the Mobile Network Prefix and are not the same as one of the addresses used by the Mobile Router. If the Mobile Router receives an IP-in-IP tunneled packet from a node in the Mobile Network and it has to forward the decapsulated packet, it should perform the above-mentioned checks on the source address of the inner packet. The Home Agent has to verify that packets received through the bi-directional tunnel belong to the Mobile Network. This check is necessary to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header must be set to the Mobile Router’s current Care-of Address. The source address of the inner IPv6 header must be topologically correct with respect to the IPv6 prefixes used in the Mobile Network. If the Mobile Router sends a Binding Update with a one or more Mobile Network Prefix options, the Home Agent must be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes. When the Mobile Router runs a dynamic routing protocol, it injects routing update messages into the Home Link. As the routing protocol message could contain information about the internal routing structure of the home network, these messages require confidentiality protection. The Mobile Router should use confidentiality protection through IPsec Encapsulating Security Payload (ESP). If the bi-directional tunnel between the Mobile Router and the Home Agent is protected by ESP in tunnel mode for all IP traffic, then no additional confidentiality protection specific to the routing protocol is required. Home Agents and Mobile Routers may use IPsec ESP to protect payload packets tunneled between them. This is useful to protect communications against attackers on the path of the tunnel. Please refer to the Mobile IPv6 specification for security considerations when the Mobile Router operates as a Mobile Host. The security mechanisms for Mobile IPv6 are still evolving. There seems to be considerable work to be done for Route Optimization security. However, it is not clear at this point that Route Optimization would be employed in the aviation environment considering that the ground-based (correspondent nodes) could at any time be communicating with a relatively large number of aircraft. For securing Mobile Node to Home Agent interactions, manual configuration of IPsec security associations would not be preferred and automatic key management would incur significant overhead in terms of delay and bandwidth even

ACP/1-DP/3


with improvements like MOBIKE. This would certainly not be usable in the current VDL-2 environment and may not be optimal for future air-ground communication systems. 3.1.2.9 IC1 - Addition of Service Providers (SP) Mobile-ipv6 protocol as specified in RFC 3775 is capable of supporting multiple air/ground service providers. MONAMI6 protocol supports multiple air/ground service providers. 3.1.2.10 IC2 - Independence of SP or Administration Mobile-ipv6 protocol as specified in RFC 3775 is independent of the type of air/ground subnetwork, service provider, or administration. MONAMI6 protocol is independent of the type of air/ground subnetwork, service provider, or administration. 3.1.2.11 IC3 - Open Industry Standard Mobile-ipv6 protocol as specified in RFC 3775 is based on the open industry standard TCP/IP protocol architecture. MONAMI6 protocol is in an IETF draft document. 3.1.2.12 IC4 - Mature and Commercially Available Mobile-ipv4 is currently deployed by some mobile phone service providers. Mobile-ipv6 will soon be deployed (and may already have been deployed in some networks). Some of the reasons to move to mobile-ipv6 are increased address space and no need for network address translation (NAT). NAT requires the mobile to send keep-alive packets in order to maintain address and this causes battery drain which is a major issue for small handsets. A number of enhancements to basic IPv6 mobility were identified during the development of the base specification. These enhancements will be taken up in a phased manner depending on the priority identified with each. Below are listed the work items to be taken up by the WG: • A bootstrap mechanism for setting up security associations between the Mobile Node (MN) and

Home Agent (HA) that would enable easier deployment of Mobile IPv6. This bootstrap mechanism is intended to be used when the device is turned on the very first time and activates MIPv6. The WG should investigate and define the scope before solving the problem.

• Improving home agent reliability: in the event of a home agent crashing, this would allow another

home agent to continue providing service to a given mobile node. - Support for a Mobile Node changing its home address, either because of renumbering in its home network or because it periodically changes addresses (perhaps via RFC3041)

• Route optimization will require security mechanisms for trusting and updating the binding

information. Return-routability is the basic mechanism for route-optimization.

ACP/1-DP/3


o Mechanisms using a shared secret Key/Security Association will be considered. o Methods for establishing a security association between the mobile node and the

correspondent node are out of the scope of the WG. • The working group will also document problem statements associated with deploying Mobile IPv6 in

the following areas: o Mobile IPv6 issues in the presence of firewalls o Mobile IPv6 deployment and transition issues in the presence of IPv4/IPv6 networks o Multicast issues

It should be noted that there are potential optimizations that might make mobile IP more attractive for use by certain applications (e.g., making handovers "faster"). The latter category of optimizations is explicitly out-of-scope of the mobile-ipv6 working group at this time. MONAMI6 protocol is draft document and is work in progress. WIDE project at Keio University and Nokia Laboratories are testing the MONAMI6 protocols. The standards track work is expected to be complete for release in the late 2007 timeframe. 3.1.2.13 IC5 - Permit Closed Network Not only will mobile-ip permit use in a closed network. Mobile-ip permits use in other network. Thus mobile-ip, be it mobile-ipv4, mobile-ipv6 or nemo, allows one to connect to another’s network infrastructure. Thus, one does not have to own and control the entire network. The ability to share network infrastructure is economically extremely attractive. This is one distinct and major advantage the mobile-ip implementations have over routing implementations with regard to mobility. MONAMI6 protocol is based on IPv6 infrastructure and therefore will be able to support closed network functionality. 3.1.2.14 IC6 - Authentication to Join Network Mobile-ipv6 protocol as specified in RFC 3775 is capable of supporting mobile nodes (only). Authentication to connect RF systems is independent of mobile-ipv6. The IETF has specified another protocol called Authentication, Authorization, and Accounting (AAA) that can be used to support authentication capabilities. In addition, the Protocol for carrying Authentication for Network Access (pana) working group in the IETF is working on authentication for network access. In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks. MONAMI6 protocol is capable of supporting Mobile Networks and authentication may not be part of the MONAMI6 protocol. The IETF has specified another protocol called Authentication, Authorization, and Accounting (AAA) that can be used to support authentication capabilities.

ACP/1-DP/3


3.2 Approach N2 - Network Mobility (NEMO) 3.2.1 Approach N2 Description Network Mobility (NEMO) Basic Support protocol is an extension of Mobile IPv6 that enables Mobile Networks to attach to different points in the Internet. These extensions are backward compatible with Mobile IPv6 and in particular, a NEMO- compliant Home Agent can operate as a Mobile IPv6 Home Agent. The NEMO Basic Support ensures session continuity for all the nodes in the Mobile Network, even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the Mobile Network as it moves. A Mobile Router extends the capabilities of a Mobile IPv6 Mobile Node, by adding routing capability between its point of attachment and a subnet that moves with the Mobile Router. A Mobile Network is a network segment or subnet that can move and attach to arbitrary points in the routing infrastructure. It can only be accessed via specific gateways called Mobile Routers that manage its movement and has at least one Mobile Router serving them. The Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network). Instead, it maintains a bi-directional tunnel to a Home Agent that advertises an aggregation of Mobile Networks to the infrastructure. In addition, the Mobile Router is the default gateway for the Mobile Network. A Mobile Network can also comprise multiple and nested subnets. A router without mobility support may be permanently attached to a Mobile Network for local distribution. Also, Mobile Routers may be attached to Mobile Networks owned by different Mobile Routers. With Basic NEMO support, a Mobile Router is attached to other Mobile Network using a single interface. A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router can have more than one Home Address. When a Mobile Router moves away from the home link and attaches to a new access router, it acquires a Care-of Address from the visited link. The Mobile Router can at any time act either as a Mobile Host or as a Mobile Router. It acts as a Mobile Host for sessions it originates and provides connectivity to the Mobile Network. As soon as the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent. When the Home Agent receives this Binding Update, it creates a cache entry binding the Mobile Router’s Home Address to its Care-of Address at the current point of attachment. The Mobile node informs the Home Agent when it acts as a Mobile Router by setting the flag (R) in the Binding Update message. It may also include information about the Mobile Network Prefix in the Binding Update by using the implicit or explicit mode of operation so that the Home Agent can forward packets meant for nodes in the Mobile Network to the Mobile Router. A Mobile Router must implement at least one mode of operation and may implement both. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all of these prefixes, it includes multiple prefix information options in a single Binding Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router’s Care-of Address.

ACP/1-DP/3


The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement to the Mobile Router. A positive acknowledgement with the Mobile Router Flag (R) set means that the Home Agent has set up forwarding for the Mobile Network. Once the binding process finishes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are the Mobile Router’s Care-of Address and the Home Agent’s address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent. This reverse-tunneling uses IP-in-IP encapsulation. The Home Agent decapsulates this packet and forwards it to the Correspondent Node. Any traffic originated by the Mobile Router can use either the reverse tunneling or route optimization. When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet is routed to the Home Agent that currently has the binding for the Mobile Router. The Home Agent aggregates the Mobile Router’s network prefix and advertises the resulting aggregation. Alternatively, the Home Agent may receive the data packets destined to the Mobile Network by advertising routes to the Mobile Network Prefix. When the Home Agent receives a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router’s current Care-of Address. The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected. Before decapsulating the tunneled packet, the Mobile Router has to check to see the Source address on the outer IPv6 header is the Home Agent’s address. This check is not necessary if IPsec protects the packet in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it is not, it should drop the packet. The Mobile Router need not include prefix information in the Binding Update when the Mobile Router and the Home Agent run a routing protocol through the bi-directional tunnel. Instead, the Home Agent uses the routing protocol updates to set up forwarding for the Mobile Network. When the routing protocol is running, the bi-directional tunnel must be treated as a tunnel interface. The tunnel interface is included in the list of interfaces on which routing protocol is active. In addition, the Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link. The Network Mobility (NEMO) basic support protocol [RFC 3963] assumes the same IPsec provisions in [RFC 3776] for interaction with the home agent. Other security considerations in the basic support protocol include a requirement for the Mobile Router to perform ingress filtering on packets received from the mobile network and for the Home Agent to verify that packets received through the bidirectional tunnel belong to the mobile network. 3.2.2 Approach N2 Analysis 3.2.2.1 TC1 - Support Authorized Traffic Type and Category IPv6 protocol suite supports “Traffic Class” and “Flow Label” capabilities that allow one to distinguish different types of message traffic. In addition, the QoS capabilities such as RSVP and diffServ offers ample opportunity to establish communication paths to support operational and legal requirements. Even though the upper layers support these capabilities, to take advantage of the higher level capabilities the subnetwork need to support similar capabilities. Otherwise one is limited by the services provided by the subnetwork. 3.2.2.2 TC2 - Multiple Independent Air/ground Sub-Networks

ACP/1-DP/3


NEMO Basic Support protocol supports mobility between independent multiple air/ground subnetworks. NEMO Basic Support protocol does not support concurrent connectivity to multiple subnetworks simultaneously. 3.2.2.3 TC3 - Minimal Latency Specifying latency is a more complex for the following reason. In the NEMO environment, there are three components one needs to take into account. They are: • The path from a node in the Mobile network to the Mobile router • The path from the Mobile router to the Home Agent • The path from the Home Agent to the Correspondent Node In addition latency is a function of message size, capacity of the link and the characteristics of the links that make up the path. To get a handle on the latency one needs to develop a reference architecture and make assumptions about the links to come up with a quantitative result. A change now being considered is to establish a direct path between the Mobile router and Correspondent node using the route optimization technique supported by the Mobile IPv6 protocol. Therefore, the latency in this environment is better than the case just described. 3.2.2.4 TC4 - High Availability Availability is a function of a number of parameters such as the air/ground link characteristics, network topology, redundancy and software mean time to failure etc. Therefore, one has to develop a reference model to develop quantitative results. Availability in the mobile environment is dominated by the link characteristics parameters. Another issue in availability is the single point of failure. Single point of failure can be managed by using redundant configuration. NEMO Basic Support protocol allows a Mobile Router to have an unique Home Address through which it is reachable when it is registered with its Home Agent. This Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. A future change is now being considered to allow the Mobile Router to have more than one Home Address. The capability to support multiple Home Agents increases the availability by reducing the probability of single point of failure. 3.2.2.5 TC5 - End-to-End Data Integrity Network layer protocols in TCP/IP and ATN are not responsible for End-to-end data integrity. This functionality is supported at the TCP or the TP4 level. In addition, additional data integrity functions to increase the end-to-end data integrity can be provided at the application layer. 3.2.2.6 TC6 – Scaleable NEMO Basic Support protocol allows the Mobile Router to support gateway function to all the nodes in the Mobile Network to communicate to the rest of the world. In this scenario, all the communications

ACP/1-DP/3


takes place through the Mobile Router’s Home Agent. Hence, all the complexity associated with mobility is in the Home Agent. Therefore, scalability is not a limitation. A change is now being considered to allow the Mobile Router to communicate to a Correspondent Node and thus directly bypassing the Home Agent by using the Route Optimization technique. Again, this communication is similar to the regular IP based communication and therefore, scalability is not an issue. 3.2.2.7 TC7 - Throughput From throughput and latency point of view, the critical communication path is the one between the Mobile Router and the Home Agent (See section TC3 - Minimal Latency). This path travels over the air/ground link and hence the throughput to some extend is a function of the capacity of this bandwidth limited air/ground link. It is our understanding that the NEMO Basic Support protocol should not limit the throughput. 3.2.2.8 TC8 - Secure Security provision for Network Mobility (NEMO) can be expected to follow the work on Mobile IPv6. Before decapsulating the tunneled packet, the Mobile Router has to check to see the Source address on the outer IPv6 header is the Home Agent’s address. This check is not necessary if IPsec protects the packet in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it is not, it should drop the packet. All signaling messages between the Mobile Router and the Home Agent must be authenticated by IPsec. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification. The signaling messages described in this document extend Mobile IPv6 messages and do not require any changes to what is described in RFC 3776, The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular, the Mobile Router should check that the IP source addresses in the packets received belong to the Mobile Network Prefix and are not the same as one of the addresses used by the Mobile Router. If the Mobile Router receives an IP-in-IP tunneled packet from a node in the Mobile Network and it has to forward the decapsulated packet, it should perform the above-mentioned checks on the source address of the inner packet. The Home Agent has to verify that packets received through the bi-directional tunnel belong to the Mobile Network. This check is necessary to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header must be set to the Mobile Router’s current Care-of Address. The source address of the inner IPv6 header must be topologically correct with respect to the IPv6 prefixes used in the Mobile Network. If the Mobile Router sends a Binding Update with one or more Mobile Network Prefix options, the Home Agent must be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes. When the Mobile Router runs a dynamic routing protocol, it injects routing update messages into the Home Link. As the routing protocol message could contain information about the internal routing

ACP/1-DP/3


structure of the home network, these messages require confidentiality protection. The Mobile Router should use confidentiality protection through IPsec ESP. If the bi-directional tunnel between the Mobile Router and the Home Agent is protected by ESP in tunnel mode for all IP traffic, then no additional confidentiality protection specific to the routing protocol is required. Home Agents and Mobile Routers may use IPsec ESP to protect payload packets tunneled between them. This is useful to protect communications against attackers on the path of the tunnel. Please refer to the Mobile IPv6 specification for security considerations when the Mobile Router operates as a Mobile Host. 3.2.2.9 IC1 - Addition of Service Providers (SP) NEMO Basic Support protocol is capable of supporting multiple air/ground service providers. 3.2.2.10 IC2 - Independence of SP or Administration NEMO Basic Support protocol is independent of the type of air/ground subnetwork, service provider, or administration. 3.2.2.11 IC3 - Open Industry Standard NEMO Basic Support protocol is based on the open industry standard TCP/IP protocol architecture. 3.2.2.12 IC4 - Mature and Commercially Available NEMO Basic Support is a standard RFC and it has been implemented and tested in test environment as part of the approval process. 3.2.2.13 IC5 - Permit Closed Network NEMO Basic Support is based on IPv6 infrastructure and therefore will be able to support closed network functionality. 3.2.2.14 IC6 - Authentication to Join Network NEMO Basic Support is capable of supporting Mobile Networks and authentication may not be part of the NEMO Basic Support protocol. The IETF has specified another protocol called Authentication, Authorization, and Accounting (AAA) that can be used to support authentication capabilities.

ACP/1-DP/3


3.3 Approach R1 – Border Gateway Protocol (BGP) 3.3.1 Approach R1 Description The basic concept involved in supporting mobility is maintaining reachability with an aircraft. The MIP and NEMO approaches to mobility are centralized approaches in that reachability information is sent back to the home agent. Any (correspondent) node wishing to communicate with a mobile node can do so through the home agent. This is possible because the home agent maintains a database of reachability information. An alternative to the MIP/NEMO approaches is to use a distributed approach by employing a routing protocol. On a fundamental level, routing protocols operate as distributed database systems. Routers propagate information about the topology of the network to other routers within the network. Each router in the network then uses this distributed database to determine one or more paths through the network to reach any given destination. A further difference between the MIP/NEMO approach and a routing protocol approach is that routing protocols also carry path information. Carrying path information permits different policies to be established. Policies can limit the amount and type of traffic which carried over various parts of the network. There are essentially two types of routing protocols which differ in the way they distribute reachability and path information through the network. With the first type, a router distributes the state of the links which are attached to it to all other routers in the network. The originating router floods this information to all other routers even if the other routers are not directly connected to the originating router. Every router in turn re-computes the paths for all destinations. The link state technique is generally applied within a routing domain or autonomous system. This technique converges rapidly so long as it is within a limited area. However, it is clearly not a candidate for world-wide mobility since every router would have to adapt to every change in connectivity for all aircraft. With the other type, a router distributes a vector containing the destination and information about the path to that destination. This approach minimizes the amount of information which is exchanged between routers in incremental updates. The vector is only distributed to adjacent routers which in turn will update their forwarding databases and forward the route based on policy. Using this approach to support mobility, routes to an aircraft would be propagated independent of other aircraft. Policies regarding traffic types and aggregation can reduce the number of updates which actually propagate through the entire network. When there is a single “distance” attribute associated with the path to a destination, this technique is termed “distance vector”. When there are multiple path attributes the technique is termed “path vector”. The ATN currently uses the IDRP path vector routing protocol to support mobility. IDRP is the OSI Inter-Domain Routing Protocol. In the IPS environment there is a comparable protocol called Border Gateway Protocol (BGP). BGP was originally intended for inter-domain routing in the Internet. However it has subsequently evolved so that it is not restricted to distributing IPv4 or IPv6 routes. Its application is not just to inter-domain routing. BGP supports applications such as BGP/MPLS IP VPNs and BGP-bases Virtual Private LAN Services. BGP has not been advocated in the Internet as a general mobility solution primarily because of concerns with scaling. It is anticipated that there may be millions of mobile nodes. This would overwhelm the Internet backbone. However, in the aviation community the numbers are more on the order of tens of thousands and furthermore even an IPS based ATN would likely be a closed network. The scaling issue

ACP/1-DP/3


should not be a problem considering that BGP supports inter-domain routing in the Internet with more than 120,000 IPv4 routes. There are two primary points where BGP may be secured; the data payload of the protocol and the data semantics of the protocol. [BGP-1] The session between two BGP speakers can be secured such that the BGP data received by the BGP speakers can be cryptographically verified to have been transmitted by the peer BGP speaker and not a replay of previously transmitted legitimate data. The most widely used mechanism to secure BGP sessions is [RFC 2385]. There are several existing IETF standards to choose from to ensure that this system functions with greater effectiveness than the current system. [BGP-2] describes the use of IPsec to secure BGP sessions. Another alternative is to use the Generalized TTL Security Mechanism described in [RFC 3682]. Rather than secure the session, routing information within BGP may be secured. Secure Origin BGP (soBGP) has been proposed in the form of several draft IETF standards. SoBGP proposes a system where the origin of any advertisement within BGP can be verified and authenticated using Certificates. SoBGP would preventing the advertisement of prefix blocks by unauthorized networks, and verifying that the final destination in the path is actually within the autonomous system to which the packets are being routed. Another proposal to secure routing information is Secure BGP (S-BGP). S-BGP secures the information carried in BGP through the use of private key signatures created at each edge between autonomous systems. The signatures can be verified using the public key of each autonomous system. 3.3.2 Approach R1 Analysis 3.3.2.1 TC1 - Support Authorized Traffic Type and Category BGP could signal traffic type and category in at least two possible ways. One is to simply define a distinct address for each traffic type. Another possible approach would be to use the Flow Label field in the IPv6 header for selection and to follow RFC 3107, “Carrying Label Information in BPG-4” to advertise distinct traffic types. Although this approach is meant to support MPLS flows it may be possible to adapt it to ATN traffic types. 3.3.2.2 TC2 - Multiple Independent Air/ground Sub-Networks BGP could advertise routes over multiple independent air/ground sub-networks. A pre-configured (static) preference policy could be established on the ground to effectively select a preferred air/ground service provider or a convention for TC1 could be adopted. 3.3.2.3 TC3 - Minimal Latency A distributed adaptive routing approach to mobility using BGP would permit rapid convergence of routing tables with each aircraft being treated independently.

ACP/1-DP/3


3.3.2.4 TC4 - High Availability High availability can be achieved with multiple routers supporting multiple paths to an aircraft. Failure of a single router will only affect those aircraft directly connected to that router. It is anticipated that redundant backbone routers will be implemented. It is also possible to have ground stations attached to multiple routers in the air-ground portion of the network 3.3.2.5 TC5 - End-to-End Data Integrity A make-before-break approach could be followed using BGP as is in the current ATN IDRP approach. 3.3.2.6 TC6 – Scaleable Being scaleable is what drives the IPS mobility solutions to be centralized. However, if BGP is configured to only support the anticipated number of aircraft, this should not be an issue 3.3.2.7 TC7 - Throughput Because it is distributed there should not be a single place where there is a bottleneck. 3.3.2.8 TC8 - Secure The BGP security mechanisms are based on running BGP in a Ground-Ground environment. At this point it is not clear whether BGP would be run in its native environment using TCP when operating over an Air-Ground link. If used in its native environment then any of the described mechanisms might be used. Alternatively the IDRP security provisions developed for the ATN could be applied to BGP over the Air-Ground link. IDRP security has been defined for air/ground routers to authenticate airborne routers and for ground/ground routers to authenticate their adjacent routers. In the ground/ground environment BGP could also be run over IPsec. 3.3.2.9 IC1 - Addition of Service Providers (SP) Service providers can readily be added due to the distributed nature of a routing approach A service provider needs to operate at least one air/ground router. 3.3.2.10 IC2 - Independence of SP or Administration BGP’s distributed nature also makes it independent of a particular Service Provider or Administration. 3.3.2.11 IC3 - Open Industry Standard BGP is an open industry standard widely used for inter-domain routing in the internet. 3.3.2.12 IC4 - Mature and Commercially Available BGP was first defined in 1989. It has gone through 4 iterations and is available with all commercial routers. It is also available as open source as one of the protocols in the Zebra package. It is included in the most recent LINUX distributions.

ACP/1-DP/3


Connexion by Boeing [BOEING-1] has implemented a global IP network mobility solution using BGP. 3.3.2.13 IC5 - Permit Closed Network It is possible to operate a network of BGP routers as a closed network. 3.3.2.14 IC6 - Authentication to Join Network The IDRP provisions to authenticate airborne routers could be adopted for BGP.

ACP/1-DP/3


3.4 Approach R2 – Inter-Domain Routing Protocol (IDRP) 3.4.1 Approach R2 Description The ATN currently uses IDRP as the basis for mobility. See Appendix A. The method by which IDRP populates the routing tables (and effectively provides mobility support) is by executing a distributed adaptive routing protocol. Any change in connectivity is propagated or “advertised” to affected ATN routers throughout the network. IDRP routing updates consist of a vector containing Network Layer Reachability Information (NLRI) and Path Information. NLRI may be an individual address of a destination or an aggregated address. Path Information is a set of attributes associated with the path being advertised to a particular or aggregate destination. In the ATN the path attribute indicates the type of traffic to be carried over the advertised path as well as the air/ground subnetwork used to reach the advertised address. Thus as an aircraft moves from one air/ground router to another one or more new path(s) with traffic type and air/ground subnetwork characteristics is (are) advertised through the network and the old route(s) withdrawn. The forwarding protocol for the ATN is CLNP. On a network-wide basis, CLNP performs packet forwarding hop-by-hop using routing tables, which have been populated by IDRP. Hop-by-hop forwarding operates by the CLNP function in each router examining the packet header, indexing the routing table to determine the next hop, i.e., the next router, and then forwarding the packet to the next hop. This continues until the last router in the chain is reached and the packet is forwarded to the destination end system. CLNP uses the destination address and the security parameter in the packet header to index the appropriate path when performing hop-by-hop forwarding. IDRP may also be used to support mobility in an IPS environment. That is, IDRP may be used with IPv4 or IPv6 as the forwarding protocol. This is possible because the NLRI field in route updates allows non-CLNP routes to be advertised. The NLRI format is such that the identity of the protocol associated with address information is signaled. 3.4.2 Approach R2 Analysis 3.4.2.1 TC1 - Support Authorized Traffic Type and Category IDRP signals Traffic Type and Category in the Security Attribute of route updates. CLNP uses the Security Parameter to index routing tables populated by IDRP. IPv4 and IPv6 do not have the Security Parameter; therefore, an alternative method would be required. For IPv6 an alternative would be to adopt the convention that different traffic types/categories have distinct addresses. This is possible because of the large address space of IPv6. For IPv4 this may be a problem due to the limited address space. 3.4.2.2 TC2 - Multiple Independent Air/ground Sub-Networks IDRP inherently provides separate and (in the presence of multiple air/ground subnetworks) redundant paths to an aircraft. This should also be possible with IP as the forwarding protocol. 3.4.2.3 TC3 - Minimal Latency The IDRP distributed approach to mobility permits rapid convergence of routing tables with each aircraft being treated independently.

ACP/1-DP/3


3.4.2.4 TC4 - High Availability As noted for the BGP approach, high availability can be achieved with multiple routers supporting multiple paths to an aircraft. 3.4.2.5 TC5 - End-to-End Data Integrity The current ATN IDRP approach permits make-before-break operation across Air/Ground routers. This approach can be carried forward with IP as the forwarding protocol. 3.4.2.6 TC6 – Scaleable IDRP is scaleable to the anticipated number of aircraft. 3.4.2.7 TC7 - Throughput Because it is distributed there should not be a single place where there is a bottleneck. 3.4.2.8 TC8 - Secure IDRP security has been defined for air/ground routers to authenticate airborne routers and for ground/ground routers to authenticate their adjacent routers. 3.4.2.9 IC1 - Addition of Service Providers (SP) Service providers can readily be added due to the distributed nature of a routing approach. A service provider needs to operate at least one air/ground router. 3.4.2.10 IC2 - Independence of SP or Administration IDRP’s distributed nature also makes it independent of a particular Service Provider or Administration. 3.4.2.11 IC3 - Open Industry Standard IDRP is defined as an ISO/ITU standard; however, the convention of using the Security Attribute/Parameter is unique to ATN. 3.4.2.12 IC4 - Mature and Commercially Available ATN Routers are only available from a limited number of vendors. Therefore, a consideration with this approach is that it does not permit evolution to commercial-off-the-shelf (COTS) routers. Instead the ATN would continue to use aviation-specific ATN routers. In order to address this issue an alternative to combine the IDRP and BGP-4 has been proposed. [SG N4 IP 0201] The combined alternative uses IDRP just over the air/ground link (i.e. for airborne and air/ground routers) but uses BGP-4 for ground-ground routing. This is accomplished with a gateway in the air/ground routers which maps IDRP routes to BGP routes and vice versa. The rational for this approach is that the air/ground routers in any case will be unique to aviation, that is, COTS routers will not likely have the ATN mobile SNDCF and aviation-unique sub-network access protocols such as VDL-2.

ACP/1-DP/3


3.4.2.13 IC5 - Permit Closed Network It is possible to operate a network of IDRP routers as a closed network. 3.4.2.14 IC6 - Authentication to Join Network IDRP has provisions to authenticate airborne routers.

ACP/1-DP/3


3.5 Approach R3 OSPF in a Single Routing Domain

3.5.1 Approach R3 Description The ground network is organized as one routing domain. This is possible under the assumption that the ground network is used for ATC and AOC communication only without any routing over the global Internet. The ground network may, of course, have a connection to the global Internet, just as the ground network may have some of its links established as tunnels over the global Internet, but the ground network must not be part of the global Internet. The reason having the ground network as one routing domain is the expected size of the ground network. Looking at the current implementation of ATN at most one hundred ATN routers are in use; and even with a tenfold increase in the number of routers, a network with one thousand routers can be handled in one routing domain. For administrative reasons one might want to divide up the ground network in smaller domains; each domain corresponding to a geographical region, and then OSPF is the obvious choice. The ground network is considered a dedicated network. When doing so several operators can be part of this network. The normal mind set with operators is that the interior of their network shall be invisible to the outside, and therefore operators use BGP to connect their routing domain to their neighboring routing domains. This is a misconception because the ground network should be seen as a collaborative effort on air traffic management, and the more openness the better. The OSPF routing protocol is a so-called link state database protocol. This means that the information exchanged between OSPF routers has the purpose of synchronizing the link state databases of all the routers. From the link state database the OSPF router will derive the routing information. The OSPF link state database consists of three types of information: (1) routing information from the OSPF area to which the router belongs and this information is very detailed, (2) routing information from the other OSPF areas and this information is not so detailed and is often aggregated, and so the information in addition to being not so detailed it is not so abundant, (3) external routing information which means information coming from outside the routing domain. The external routing information has some interesting properties relevant to aircraft mobility: (a) external routing information is spread in the entire routing domain, (b) external routing information is not aggregated, (c) each prefix of external routing information is one entry in the link state database, (d) modification of the link state database by one entry of external routing information leads to a simple routing calculation. The external prefixes are the prefixes from the aircraft. The OSPF routers in the ground network can learn of this prefix in several ways. One way is to use BGP on the air ground link; another way would be if the aircraft prefix could be constructed such that the 24-bit ICAO callsign can be part of the prefix. One particular concern is which metric to associate to an aircraft prefix. This concern is relevant if two or more connections are established to the aircraft at the same time. Because the aircraft is not part of the OSPF routing domain (as this requires too much data to be exchanged on the air ground link), the air/ground router injecting the prefix in the OSPF routing domain must develop an algorithm for assigning the metric to the prefix. The OSPF routing protocol is spreading the routing information in the entire routing domain at a fast pace, typically less than one seconds for passing on an update to the link state database, and typically recalculate information to the routing table within a couple of seconds.

ACP/1-DP/3


Should it happen that the ground network becomes really large, one may rearrange the network in a more traditional way with different providers having different routing domains and using BGP between the routing domains. But again, the prefixes learned from the aircrafts are spread in all directions and will be known in the entire ground network. This approach makes no use of mobility solutions. The motivation for mobility solutions is that such mobility solutions will make the core of the routing domain seem to be stable by isolating the dynamics to the home agents and the foreign agents. This approach makes no assumption about use of IPv4 or IPv6. OSPF for IPv4 (OSPFv2) is specified in [RFC 2328] and is a well-established protocol by most router vendors. OSPF for IPv6 (OSPFv3) is specified in [RFC 2740] and is well-established for those (fewer) router vendors supporting IPv6. OSPFv2 defines fields AuType and Authentication in its protocol header in order to provide security. In OSPFv3, both of the authentication fields were removed from OSPF headers. OSPFv3 relies on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to provide integrity, authentication and/or confidentiality [RFC 4552]. 3.5.2 Approach R3 Analysis 3.5.2.1 TC1 - Support Authorized Traffic Type and Category The idea that traffic of different types for the same destination must take different paths through the network is a feature of an ATN network. This feature is not part of IP networking. IP networks can treat different types of traffic in different ways, but such traffic will always be routed the same way. 3.5.2.2 TC2 - Multiple Independent Air/ground Sub-Networks When the aircraft has two connections to the ground, the two OSPF routers on the ground will inject the same aircraft prefix into the OSPF routing domain. If the aircraft wants to decide which of the two links should be preferred, the aircraft must influence the metric the OSPF routers (the air/ground routers) attach to the prefix when injecting it in the ground routing domain. However, if the same aircraft prefix is advertised for both links, the aircraft cannot decide that some traffic uses one of the air/ground links while other traffic takes the other air/ground link. It is important that the airborne router having two air/ground link are configured with access control lists prevention IP traffic arriving on one of the air/ground links to be routed back over the other air/ground link. 3.5.2.3 TC3 - Minimal Latency For the first-time advertisement of the prefix, the prefix is advertised over the air/ground link. No mechanism is specified here, only mentioned two possibilities. When the prefix has reached the OSPF router at the air/ground router, about one second should be enough for the generation of a new entry to the

ACP/1-DP/3


link state database, then about one second for each hop taken by the link state database entry, and then say five seconds for OSPF to start the routing calculation and updating the routing table. Handoff from the current air/ground router to the next air/ground router can for example be done this way: the current air/ground router readvertises the prefix with an increased metric, while the next air/ground router advertises the route with a low metric. This way existing routes will continue to be in use until superseded by the new route. 3.5.2.4 TC4 - High Availability Single points of failure are unavoidable: after all there is just one aircraft. With two links to the aircraft and suitable redundancy in the network, a backup route should always be possible. There are no special concerns to be taken using the OSPF approach, as OSPF is one of the most reliable protocols to detect and route around failure. Using OSPF in the ground network calls for standard setup of an IP network. 3.5.2.5 TC5 - End-to-End Data Integrity The IP network layer is not responsible for end-to-end data integrity. 3.5.2.6 TC6 – Scaleable A pure OSPF approach as suggested here will probably get some performance problems when the ground network consists of more than 3000 routers. Also it should be considered how many aircraft prefixes will be used. Suppose the average length of time for a trip with an aircraft is three hours and a new OSPF router is visited every 15 minutes, then an aircraft prefix will be injected from 12 different routers. Also, if say 2000 aircrafts are in motion at any time, then 2000 entries are seen in the link state database. If the ground network is stable, this number of updates to the link state database is not uncommon. Should the ground network grow beyond 3000 routers, it is still possible to divide the ground network up in a more traditional way using OSPF inside routing domains and BGP between routing domains. Should the number of aircrafts in motion increase beyond 4000, then the amount of routing information to be handled must be reconsidered. 3.5.2.7 TC7 - Throughput Throughput on any given link is reduced by the amount of bandwidth consumed for example by routing protocols. On the ground network this is not a problem as bandwidth is not a limiting factor. The limiting factor is the air/ground link. On the air/ground link no mechanism for sending routing updates is specified, but certainly OSPF is not used. This is partly because of use of bandwidth for the OSPF router and the OSPF router in the aircraft to have their link-state databases synchronized, partly because the ground network only needs to inject a default route to the router in the aircraft, and partly because the OSPF router in the aircraft must know the OSPF area identifier to used. Instead use BGP, because the bandwidth use is small. 3.5.2.8 TC8 - Secure

ACP/1-DP/3


This OSPF approach presupposes an enterprise network, ie a network with no access from outside users. If the perimeter can be protected, attacks on the network stem from malfunctioning software or hardware rather than intentionally ill-will. It is, of course, possible to use IPsec to authenticate OSPF information. OSPF for IPv4 has an authentication mechanism specified in RFC 2328; OSPF for IPv6 will use IPsec, for which a draft is available. OSPF is not being proposed for operation over the Air-Ground link. If used Ground-Ground to propagate mobile routes IPsec can be used. 1.1.1.1 3.5.2.9 IC1 - Addition of Service Providers (SP) The job of the air/ground service providers is to set up one or more air/ground routers and ground/ground routers running OSPF with its neighbors. A service provider will connect using OSPF to other service providers’ routers. Such a setup is perhaps not uncommon: just think of how large corporations with many sites arrange their routed network. Each air/ground routers will inject OSPF link state database entries into the ground network. 1.1.1.2 3.5.2.10 IC2 - Independence of SP or Administration This OSPF approach makes no assumptions on the air/ground service providers or their operation. 3.5.2.11 IC3 - Open Industry Standard OSPF for IPv4 is specified in RFC 2327 while OSPF for IPv6 is specified in RFC 2788. The OSPF protocol has been in use for ten years, and is the recommended protocol for a routing domain. 3.5.2.12 IC4 - Mature and Commercially Available The OSPF protocol, both for IPv4 and for IPv6, is supported by almost all vendors of routers. 3.5.2.13 IC5 - Permit Closed Network The OSPF approach described here can be supported only in an enterprise network, ie a closed network. This is because the amount of updates to the routing tables as the aircrafts moves will not be tolerated in the global Internet. 3.5.2.14 IC6 - Authentication to Join Network The OSPF protocol can be authenticated. OSPF for IPv4 has a built-in authentication mechanism while OSPF for IPv6 will have to rely on an IPsec solution.

3.6 Approach T1 – Stream Control Transmission Protocol (SCTP) 3.6.1 Approach T1 Description

ACP/1-DP/3


Complexities associated with mobility at the network layer have led some researchers to fundamentally question whether mobility should be at the network layer or if mobility should be handled on an end-to-end basis [SCTP-1]. One method of moving mobility to the end system is to adapt the Stream Control Transmission Protocol (SCTP) [RFC 2960]. SCTP is generally advocated for mobility because of its multi-homing capability which permits a single SCTP end point to have multiple IP addresses for a single association [SCTP-2], [SCTP-3], [MCNA]. SCTP supports carrying data over multiple IP address through a path management function, which performs path selection and monitoring. This function selects a “primary” data transmission path and tests the connectivity of the transmission path. SCTP manages paths over IP addresses which have been statically defined. To support mobility, SCTP requires an extension to dynamically add IP addresses as they are detected by the mobile end system [SCTP-4]. An SCTP implementation with the ADDIP extension is called mobile SCTP (mSCTP). mSCTP has been defined for use in a client-server environment where the mobile end system initiates the connection. In a peer-to-peer environment where the non-mobile (or another mobile) end system initiates the connection a location management function is needed [SCTP-5]. The location management function could be Mobile IP. When operating with Mobile IP only the binding update messages to the home agent (to change its CoA) are needed. Handover management is then performed via mSCTP rather than by Mobile IP. In Mobile IP, the Low Latency or Fast handover schemes have been designed for handover management. These schemes rely on the tunneling between old and new access routers for soft handover. Using mSCTP for handover management provides inherent route optimization (triangle routes never occur). Other potential location management functions which could be used with mSCTP include the Session Initiation Protocol (SIP), or Dynamic DNS. Note that a location management capability would be would be needed for ATN mobility for ground initiated services so that other ground systems (data authorities) can initiate new connections with aircraft. [RFC 3554] describes the use of Stream Control Transmission Protocol (SCTP) with IPsec. SCTP is a reliable transport protocol operating on top of a connection-less packet network such as IP. SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications. When SCTP is used over IP networks, it may utilize the IPsec for integrity and confidentiality. To dynamically establish IPsec Security Associations (SAs), a key negotiation protocol such as IKE may be used. RFC 3554 describes functional requirements for IPsec and IKE to facilitate their use in securing SCTP traffic. RFC 3554 identifies a new ID type in IKE and implementation choices in the IPsec processing to accommodate for the multiplicity of source and destination addresses associated with a single SCTP association. 3.6.2 Approach T1 Analysis 3.6.2.1 TC1 – Support Authorized Traffic Type and Category The mSCTP approach does not inherently support segregation of Traffic Type and Category.

ACP/1-DP/3


The path management function would most likely need to be extended to accommodate flow labels or classes of addresses. This would further complicate mSCTP. 3.6.2.2 TC2 – Multiple Independent Air/ground Sub-Networks Inherently, SCTP supports multi-homed end hosts with more than one IP address allocated to it. 3.6.2.3 TC3 – Minimal Latency Latency is minimal because communication is direct between the end systems. 3.6.2.4 TC4 – High Availability Multi-homing is the ability for a single SCTP endpoint to support multiple IP addresses. The benefit of multi-homing is potentially greater survivability of the session in the presence of network failures. 3.6.2.5 TC5 – End-to-End Data Integrity SCTP is connection oriented; message based reliable transport protocol and sets up an end-to-end connection. SCTP is reliable, so that any data transferred must be acknowledged. If the data is not acknowledged, it is retransmitted. 3.6.2.6 TC6 – Scaleable From a network perspective mSCTP is scaleable. 3.6.2.7 TC7 – Throughput SCTP separates the reliable transfer from the delivery mechanism. This makes it possible to adapt delivery to the needs of the applications using SCTP. 3.6.2.8 TC8 – Secure SCTP uses a four-way handshake to establish a connection. This additional effort enables security mechanisms which make SCTP robust against blind attacks, i.e. attacks where the attacker is not able to intercept Protocol Data Units (PDUs) but tries to interfere by sending malicious PDUs to one or more SCTP nodes. In SCTP, resource allocation during association setup is delayed until the client’s identity can be verified using a cookie exchange mechanism, thus reducing the possibility of Denial of Service attacks. In addition to the verification tag and cookie mechanisms, SCTP specifies the use of IPSec if strong security and integrity protection is required. The SCTP specification does not itself define any new security protocols or procedures. 3.6.2.9 IC1 – Addition of Service Providers (SP)

ACP/1-DP/3


Because mSCTP is end-to-end, it is independent of air/ground service providers; however, as noted above mSCTP is not a complete solution and the location management function may be that of a service provider. 3.6.2.10 IC2 – Independence of SP or Administration Operation of the location management function must be performed in the SP or administrations network. 3.6.2.11 IC3 – Open Industry Standard SCTP is an IETF RFC. The ADDIP extension and use with various location management schemes are still evolving drafts. 1.1.1.3 3.6.2.12 IC4 – Mature and Commercially Available SCTP has been used for some time. mSCTP has been prototyped. 3.6.2.13 IC5 – Permit Closed Network mSCTP can be used in a closed network. 3.6.2.14 IC6 – Authentication to Join Network SCTP associations are established following a four-way handshake that includes authentication.

ACP/1-DP/3


3.7 Approach A1 – Instant Messaging (IM) Protocols Rather than support mobility transparently in the internet communications service, mobility can be managed through message level routing. A well known example of this in the aviation community is the ACARS system. ACARS messages from aircraft are sent to a communications server which forwards them to the appropriate ground system based on the address in the message header. The server keeps track of which ground station(s) are communicating with particular aircraft and accordingly can route messages to an aircraft to the correct ground station. Since the ACARS approach has been proven in the aviation community, a logical alternative to support message level routing in an IPS environment would be use an Instant Messaging (IM) approach. Although there are many well-known IM systems (e.g., MSN, AOL, ICQ, and Yahoo!) the aviation community needs be based on standards and this leads to consideration of IM using IETF-based RFCs. Recognizing the diverse set of IM approaches, the IETF formed the IM and Presence Protocol Working Group (IMPPWG) to define a standard so that independently developed IM and/or presence applications can interoperate. RFC 2779, defines the requirements for a general Instant Messaging/Presence Protocol. The IMPPWG has defined a Common Profile for IM (CPIM) that describes a general architecture and addresses server-to-server interoperability in an environment with multiple IM protocols. Extensible Messaging and Presence Protocol (XMPP) One set of IETF IM standards that is supported by a large number of implementations is the Extensible Messaging and Presence Protocol (XMPP). XMPP basic IM functionality is defined by the XMPP core (RFC 3920) and XMPP IM (RFC 3921) specifications. RFC 3920 defines core features of XMPP as a protocol for streaming Extensible Markup Language (XML) elements. XMPP is generically a protocol for near-real-time messaging, presence, and request-response services. RFC 3921 describes extensions the core features of XMPP to provide the basic IM and presence functionality defined in RFC 2779. There are two other key RFCs related to XMPP. RFC 3922 describes a mapping between the XMPP and the CPIM specifications. RFC 3923 defines methods of end-to-end signing and object encryption for XMPP. The methods described enable a sender to sign and/or encrypt an instant message sent to a specific recipient and to sign and/or encrypt presence information or an arbitrary XMPP stanza directed to a specific user. Once the XMPP RFCs were published, the IETF announced conclusion of the XMPP Working Group. XMPP extensions are being produced by the Jabber Software Foundation (JSF). The Jabber community has produced open-source software to implement XMPP and JSF extensions. The architecture of Jabber IM is similar to e-mail. Unlike e-mail however, Jabber data streams are defined using XML. Jabber clients connect to a distributed network of servers and exchange (usually small) “stanzas” of XML. Jabber servers send the XML stanzas to the destination client. Session Initiation Protocol for IM and Presence Leveraging Extensions (SIMPLE) Another significant IM standard has evolved from the Session Initiation Protocol (SIP) [RFC 3261], which is popular in the Internet community for as the signalling protocol to establish Voice Over IP (VoIP) sessions. The IETF has established a working group called Session Initiation Protocol for IM and Presence Leveraging Extensions (SIMPLE) to develop instant messaging and presence using SIP. Some industry experts expect it to gain support because it is backed by Mirrosoft, IBM, Sun, Novell and other industry leaders.

ACP/1-DP/3


RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) specifies methods which enable a sender to sign and/or encrypt an instant message sent to a specific recipient, sign and/or encrypt presence information directed to a specific user, and sign and/or encrypt any XMPP stanza directed to a specific user. Several approaches to SIP security are identified in [RFC 3261]. RFC 3261 notes that SIP may be secured at the Transport or Network layer using TLS or IPsec or SIP may be secured using HTTP authentication or S/MIME. 3.7.2 Approach A1 Analysis 3.7.2.1 TC1 – Support Authorized Traffic Type and Category The IM approach does not support segregation of Traffic Type and Category. 3.7.2.2 TC2 – Multiple Independent Air/ground Sub-Networks Because the IM approach is above the network layer, it could in principle support multiple independent air/ground sub-networks. 3.7.2.3 TC3 – Minimal Latency Latency using the SIMPLE approach is minimal because communication is direct between the end systems. The XMPP approach could introduce latency because of all messages go through the server. 3.7.2.4 TC4 – High Availability High availability can be achieved with either the SIMPLE or XMPP approach using redundant servers. 3.7.2.5 TC5 – End-to-End Data Integrity The IM protocols themselves do not support End-to-End Data Integrity. 3.7.2.6 TC6 – Scaleable Both XMPP and SIMPLE are scaleable. 3.7.2.7 TC7 – Throughput The servers, especially for XMPP, need to handle the expected throuput. 3.7.2.8 TC8 – Secure Both IM approaches have associated security provisions. 3.7.2.9 IC1 – Addition of Service Providers (SP)

ACP/1-DP/3


Operation of the servers would need to be coordinated among service providers. 3.7.2.10 IC2 – Independence of SP or Administration Operation of the server for presence must be performed in the SP or administrations network. 3.7.2.11 IC3 – Open Industry Standard Although XMPP is based on IETF RFCs, the recent enhancements are all coming from the JSF. SIMPLE RFCs are still evolving. 3.7.2.12 IC4 – Mature and Commercially Available Jabber is widely used. 3.7.2.13 IC5 – Permit Closed Network The IM approach can be used in a closed network. 3.7.2.14 IC6 – Authentication to Join Network Both IM methods have associated authentication procedures.

ACP/1-DP/3


3.8 Approach A2 – ATN Application Mobility Note. - The following section is from [SG N1 WP 0715]

The current ATN mobility solution relies on network-level routing exchanges and hides mobility from the end user. ATN applications do not need any special functionality to enable them to operate in a dynamic mobile environment.

An alternative strategy being considered for a future IP-based ATN is to make the ATN applications mobile-aware instead. This would remove much complexity from the network layer, but at the cost of introducing additional complexity to applications instead.

One possible method would be to use some kind of central communications server, to which all messages were routed initially, which had knowledge of which aircraft were reachable from each ground/air router. This would not only lead to inefficiency through overly-long data paths, but would introduce a single point of failure.

All new applications would need the extra functionality but existing ATN applications would require modification too. The main disadvantage with this is that it requires far more development effort and would result in multiple bespoke mechanisms being built into applications to handle mobility. It would not be impossible to do especially for applications that have not been written yet, but it goes against the desire to strive for the greater use of open standards and adoption of COTS products.

One possibility, which would remove the need to change the functionality of applications, would be to simply use Dynamic DNS to inform the rest of the network of address changes when a host or network changes its address. It is probably unlikely that the update mechanism would work fast enough throughout the network to enable the end to end application latency requirements to be met, but may be worth further investigation before being discounted totally.

3.8.2 Approach A1 Analysis

3.8.2.1 TC1 – Support Authorized Traffic Type and Category

An airborne application could decide which ground station to route a particular traffic type via to the central application server. Similarly the application server could decide which ground stations to send particular traffic types via to reach the aircraft where multiple connections are available to reach it. 3.8.2.2 TC2 – Multiple Independent Air/ground Sub-Networks

The application approach to mobility would not preclude or assist the use of multiple air/ground connections. Handoff between networks would need to be signalled to the central application server within the ground network. 3.8.2.3 TC3 – Minimal Latency

Latency during path establishment or data transfer would be higher in some cases than a network layer approach as all traffic will need to be routed via a central server, resulting in much longer path lengths. Handoff performance would need to be determined but would be expected to result in similar delays to a network approach, since both involve end to end signalling.

ACP/1-DP/3


3.8.2.4 TC4 – High Availability

The use of a central application server with this approach represents a single point of failure. 3.8.2.5 TC5 – End-to-End Data Integrity

An application mobility approach may require integrity checking to be performed within the application, depending on what is provided by the underlying bearers themselves. This is applicable to all applications regardless of the mobility approach. It should be possible to minimise or eliminate packet loss during handover by preventing the application server sending messages out during handover and buffering them. This may require some kind of handshaking process for every message though which would add further to the latency described in TC3. 3.8.2.6 TC6 – Scaleable

There is likely be a heavy load placed on any central application server which would need to be carefully assessed. The need for bespoke application mobility mechanisms goes against the desire for COTS equipment, and the economies of scale this provides, which is likely to make an application approach more costly. 3.8.2.7 TC7 – Throughput

Throughput on links to and from the central application server is likely to be an issue when a high number of airborne clients are in operation. 3.8.2.8 TC8 – Secure

Availability - An application approach should be able to maintain multiple links from the aircraft to different ground stations to provide a degree of redundancy. The main concern is the central application server which represents a single point of failure. Integrity - As mentioned in TC5 integrity checking may need to be built in to applications themselves. This would be possible since bespoke applications will need to be written. The use of IPsec or SSL could be built into the applications to provide application level authentication and integrity. The usual CRC integrity checks with UDP data are unaffected and will require additional mechanisms to provide resend capability for corrupt packets as with any UDP traffic. TCP traffic has this built-in. Confidentiality - IPsec or SSL could be used by the application to ensure application confidentiality. Authentication - Application level authentication would be easily incorporated into a bespoke application.

The ATN application security solution could be applied directly under this approach. The implementation could be in the form of a security sub-layer (the “security shim” approach). SGN4 has recommended that the key establishment process be separated from CM if the ATN application security solution is used in an IPS environment. The ATN Key Establishment process could be defined as a separate application or alternatively an IPS key establishment process could be used. Preliminary analysis [SG N4 WP0804] indicates that IKEv2 would not be appropriate at least with the current bandwidth-constrained air-ground links.

ACP/1-DP/3


3.8.2.9 IC1 – Addition of Service Providers (SP)

Operation of the central application server(s) would need to be coordinated among service providers. 3.8.2.10 IC2 – Independence of SP or Administration

Because there is a need for one or more central application servers, the approach is dependent on a SP or administrations. 3.8.2.11 IC3 – Open Industry Standard

The approach itself would be unique to aviation; however, it would potentially simplify the underlying layers enabling them to be based on open industry standards. 3.8.2.12 IC4 – Mature and Commercially Available

The approach is not mature and because it is unique to aviation would not be commercially available. 3.8.2.13 IC5 – Permit Closed Network

The approach is independent of the network technology; however, the set of applications could be limited. 3.8.2.14 IC6 – Authentication to Join Network

Application level authentication could be applied using existing ATN end-to-end authentication provisions.

3.9 Approach A3 – IP Sec Tunnel Movement Note. - The following section is from [SG N1 IP 12 08] 3.9.1 Approach A3 Description

The starting point for this approach is the assumption that an end-to-end IPsec tunnel must be created between an aircraft and each ATSU (Air Traffic Service Unit ) that it needs to communicate with. This is to meet the security requirements. Furthermore, it is assumed that these tunnels are all air-initiated. It is the aircraft’s responsibility to initiate the tunnel creation with the ATSUs.

This latter assumption is important for justifying this approach. The assumption carries forward the operational concept contained in Doc 9694, whereby an aircraft must “login to ATC” and identify which Flight it is before it can be put under data link control.

Once an aircraft has logged into one ATSU, its contact details can be passed to other ATSUs in the region. Hence, this model of communications does not restrict these ATSUs from contacting the aircraft directly.

The importance of this assumption is that it means that the aircraft does not have to provide a means by which any ground system can contact it prior to tunnel establishment. This allows a simple approach.

ACP/1-DP/3


IPsec standards are currently in transition from “version 1” to “version 2”. Version 2 of the IKE is particularly significant as version 1 suffered from a process of rapid evolution and correction. IKEv2 is believed to correct these problems and version 2 of the IKE and IPsec are assumed here (RFC 4301).

Communications Initiation

Aircraft Ground System

Pilot Login (e.g. to EDYY)

NetworkLogin

DNS Lookup(Optional)

Use IKETo create

Host to Host Tunnel

• Aircraft authenticated by X.509 certificate verification

• Note: Aircraft authenticated – not Flight• Ground System

authenticated by X.509 certificate verification

CM LoginRequest

CM LoginResponse

Use IKETo create

Subnet to Subnet Tunnel

• Flight ID/24-bit Address/IPAddressBinding Established

• Flight Plan located and verified• Aircraft Compliance Level Determined• Verify Aircraft DNS Entries

Login ConfirmedTo Pilot

• Ground Subnet IP Address Range Learnt

Figure Error! No text of specified style in document.-2 Communications Initiation Process

The Route Initiation Process is shown in Figure Error! No text of specified style in document.-2. The process starts with a network login, the details of which will vary between Air/Ground Communication Networks. Once the pilot knows that the aircraft has an active Data Link, a login to a specific ATSU (e.g. EDYY – UAC Maastricht) may be requested.

In order to perform the login:

1. A DNS lookup may need to be performed in order to resolve the IP Address for the ATSU. This can be avoided if the IP Address has already been cached.

2. The airborne systems use the IKE to establish a tunnel mode SA pair whose end-points are the aircraft’s IP Address on the Air/Ground network and the ATSU’s IP Addrress. The procedures for creating this tunnel follow the typical “road warrior” scenario with authentication performed using X.509 certificates. Four messages are exchanged in order to complete the authentication

ACP/1-DP/3


and create the tunnel between the communications gateway on the aircraft and the communications gateway on the ground.

3. The Logon Message is now sent by the aircraft to the ground IP Address. This reports the binding between the Flight ID, the Airframe Identifier (ICAO 24-bit aircraft address) and the IP Address range for the airborne subnet. It may also report the IP Addresses assigned to the hosts for different services on the aircraft. It is sent using the tunnel established above.

4. The Logon Response is returned to the aircraft over the tunnel. This reports the IP Address range for the ATSU’s ground subnet. It may also report the IP Addresses assigned to the hosts for different services that the ATSU provides.

5. The airborne systems now use the IKE to establish a second tunnel whose end-points are the aircraft’s IP Address on the Air/Ground network and the ATSU’s IP Address, but which is used to forward IP packets between the airborne and ground subnets. Two further messages are exchanged for this purpose.

6. Communication is now possible between host computers on the airborme and ground subnets. It may be useful at this point for the aircraft to send a communications advisory message to the ATSU to report that the tunnels have now been established and are available for operational communications.

Change of Air/Ground Network

The next three figures illustrate how end-to-end communications via IPsec tunnels can be maintained whilst an aircraft moves from one Air/ground Network to another.

GroundInternet

CommsG/W

CommsG/W

Subnet to SubnetTunnel 10.0.0.0/24

80.10.32.250

80. 0.20.120

TerrestrialWideband

192.168.3.0/24

Figure Error! No text of specified style in document.-3 Air/Ground Communication via a Terrestrial

Wideband Network Figure Error! No text of specified style in document.-3 illustrates the starting point. The aircraft has successfully logged into an ATSU, and has established Air/Ground communications via a terrestrial wideband network between its own IP Address (80.10.32.250) and the ATSU’s Communications Gateway (80.0.20.120). This tunnel is for the transfer of packets between the Aircraft’s subnet (192.168.3.0/24) and the ATSU’s subnet (10.0.0.0/24).

ACP/1-DP/3


GroundInternet

CommsG/W

CommsG/W

Subnet to SubnetTunnel

192.168.3.0/24

10.0.0.0/24

80.10.32.250

80. 0.20.120

172.16.1.65

TerrestrialWideband

SATCOM

Figure Error! No text of specified style in document.-4 Completion of Successful Logon to SATCOM

GroundInternet

CommsG/W

CommsG/W

Subnet to SubnetTunnel

192.168.3.0/24

10.0.0.0/24

80. 0.20.120

172.16.1.65

TerrestrialWideband

SATCOM

Figure Error! No text of specified style in document.-5 After Logoff from Terrestrial Wideband

At some point later in flight, the Aircraft logs on to a new Air/ground Network (SATCOM) and is allocated an IP Address on that subnetwork (172.16.1.65). This is shown in Figure Error! No text of specified style in document.-4. A local policy rule determines that the tunnels with the current ATSU must be moved to the new Air/Ground Network.

The airborne systems now use the IKE to create a tunnel between aircraft’s IP Address on the SATCOM Air/Ground Network (172.16.1.65) and the ATSU IP Address (80.0.20.120). As a new IP Address is used, the aircraft and ATSU must re-authenticate each other. Four messages are thus exchanged and at the

ACP/1-DP/3


end of which a tunnel is now created between 172.16.1.65 amd 80.0.20.120 for the transfer of packets between the Aircraft’s subnet (192.168.3.0/24) and the ATSU’s subnet (10.0.0.0/24).

Two parallel tunnels now exist between the communications gateways. The information that determines whether or not a tunnel is used for a given packet is held in the Security Policy Database (SPD). The SPD will now have two entries for the two tunnels, each with the same packet selection criteria. It is thus not predictable as to which tunnel will be used for a given packet.

However, it is possible to set more detailed selection criteria and this could be used to support policy-based differential routing, selecting different groups of packets to be routed via different tunnels and hence via different Air/Ground Networks.

In most cases, the two parallel tunnels will only exist for a short period of time. Assuming the aircraft is going out of range of the terrestrial network it will either explicitly log off from that network or will lose contact. Either way, the tunnel via 80.10.32.250 will be deleted and the result will be the configuration shown in Figure Error! No text of specified style in document.-5. Only a single tunnel between the aircraft and the ground now exists, via 172.16.1.65. All traffic between the aircraft subnet and the ground subnet will be routed via this tunnel.

From the point of view of applications running on hosts on either subnet, there has been no change to the connectivity. The transfer has been seamless. The only visible impact may be a change in the round-trip delay.

The main issue with this approach is that there is an unnecessary re-authentication when the new Air/Ground Network becomes available and this is entirely due to a limitation in the existing IKE protocol. However, a recent extension called MOBIKE (RFC 4555) removes this limitation and allows for tunnel movement with no more than an exchange of two messages.

Transfer of Communications

Transfer of Communications takes place when control of an aircraft passes from one ATSU to another. The communications path between the aircraft and the Receiving ATSU (R-ATSU) must be set up before control is transferred from the Current ATSU (C-ATSU).

Figure Error! No text of specified style in document.-6 illustrates this case:

1. Following current practice, the C-ATSU informs the R-ATSU about the aircraft by a ground-based exchange. The R-ATSU is provided with the current IP Address of the aircraft and the IP Address range for the aircraft subnet.

2. The R-ATSU is nominated as the Next Data Authority (NDA) by the C-ATSU sending the aircraft an NDA message identifying the R-ATSU.

3. The R-ATSU uses the information received from the C-ATSU to create a tunnel between its IP Address and the aircraft’s IP Address, for the transfer of packets between its subnet and the aircraft’s subnet. As the R-ATSU must authenticate itself to the aircraft, an exchange of four packets is needed. The communication path is now open. When the transfer of communications is completed, the aircraft will send a Current Data Authority (CDA) message to the R-ATSU, following current practice.

4. .If the C-ATSU should ever withdraw the NDA nomination, the aircraft must delete the tunnels.

ACP/1-DP/3


Aircraft C-ATSU R-ATSU

NDA

IKE used toEstablish

Subnet-to-subnettunnel

Aircraft preparesTo accept subnet-to-subnet

Tunnel from R-ATSU

Figure Error! No text of specified style in document.-6 Transfer of Communications

This approach exploits the fact that IPsec tunnels need to be used end-to-end in order to protect against various identified.threats. As IPsec tunnel end-point addresses are independent of tunnel selection criteria, it is possible to move a tunnel without affecting applications other than those on the communications gateway itself. This gives the basis of a mobility solution.

The operational scenario also means that the aircraft behaves like a true “road warrior”. That is until it makes contact, communication does not take place. There is no requirement for an aircraft to be available for communication initiated by “anyone”. The aircraft is aware of whom it should be in contact with and will initiate communication at the appropriate time.

3.9.2 Approach A3 Analysis

3.9.2.1 TC1 - Support Authorized Traffic Type and Category

Traffic Types and categories were originally introduced to permit separate routing criteria for AOC and ATS communications and to permit ATS Communications to be routed over approved routes only. As a general point, it is difficult to support this category in any approach and to be a truly COTS solution as this functionality is not required outside of ICAO. It is also not used by current ATN deployments.

Nevertheless, the tunnel movement strategy does:

a) Separate out AOC and ATS traffic into different tunnels. These tunnels can be via different Air/Ground Networks and can have different differential service attributes.

b) Permit packet filters by IP Address and Port numbers, and other packet header information, to separate different ATS data streams and map them on to different tunnels. As above, these tunnels can be via different Air/Ground Networks and have different differential service attributes.

3.9.2.2 TC2 - Multiple Independent Air/ground Sub-Networks

ACP/1-DP/3


As IPsec tunnels are tied to an IP Address, it is possible to have different tunnels open simultaneously via different Air/Ground Networks.

3.9.2.3 TC3 - Minimal Latency

Latency should always be minimal under this approach. This is because the tunnel end-point is the real IP Address of the node on the network. The underlying IP network can then be relied upon to use the most direct route between the two tunnel end-points.

Tunnel movement should be achievable with only the exchange of two messages (with MOBIKE) allowing a rapid transfer with minimum latency. Tunnel movement does not invalidate any packets “in a tunnel” when it is moved. Therefore no data loss should be experienced on tunnel movement.

3.9.2.4 TC4 - High Availability

Availability is only as good as the availability of the links being used. The ability to use multiple links increases the availability.

This approach makes direct use of the IP Network and thus permits the full availability of the IP Network to be realized.

3.9.2.5 TC5 - End-to-End Data Integrity

A by-product of IPsec is that it provides a strong proof of data integrity between the tunnel end-points.

3.9.2.6 TC6 – Scaleable

The main scaling issue is the number of IPsec tunnel end-points that the ATSU Communications Gateway will have to support. This is largely a sizing issue. Commercial routers can support upto 5,000 VPN users and 1,000 site to site tunnels. Such a capacity should be sufficient for most ATSUs.

3.9.2.7 TC7 – Throughput

IPsec tunnels do add an overhead to each packet and hence do reduce throughput. The actual impact depends upon the mean packet size and can be more significant when the packet is encrypted rather than protected for integrity and authentication only.

However, all approaches must incur this overhead as the security requirements demand IPsec end-to-end – assuming that the security requirements are implemented by using COTS products.

3.9.2.8 TC8 – Secure

IPsec is believed to offer a high degree of security. Tunnel movement does not negatively impact the IPsec security mechanisms.

3.9.2.9 IC1 - Addition of Service Providers (SP)

IPsec and tunnel movement do not impose a limitation on the number of Multiple Air/Ground Service Providers.

3.9.2.10 IC2 - Independence of SP or Administration

IPsec and tunnel movement are independent of any Service Provider or Administration.

3.9.2.11 IC3 - Open Industry Standard

IPsec standards are published as RFCs and are open industry standards. However, while most encryption and authentication algorithms available for use with IPsec are in the public domain, there are some for which commercial licensing conditions are attached, and a careful choice must be made before a final specification can be published by ICAO.

ACP/1-DP/3


3.9.2.12 IC4 - Mature and Commercially Available

IPsec (version 1) is mature and commercially available. IPsec (version 2) products are starting to become available and should mature within the next two years.

3.9.2.13 IC5 - Permit Closed Network

This is essentially a VPN style solution and enforces a closed network approach.

3.9.2.14 IC6 - Authentication to Join Network

Authentication is required by the Security Requirements and provided through use of IPsec.

ACP/1-DP/3


3.10 Approach L1 Link Layer Mobility Note. - The following section is from [SG N1 IP 12 08]. 3.10.1 Approach L1 Description The idea of using Link Layer mobility (or Network Layer mobility for that matter) is to take the burden from any dedicated aeronautical application – or even from aeronautical use of standard IP applications (e.g. FTP) – when it comes to mobility. By having mobility implemented in the Link Layer all applications will behave as if they were implemented in a host not exposed to mobility. Especially for standard IP applications this is important, as it will allow the future aeronautical use of these well-proven COTS parts, either as parts of or in support to dedicated aeronautical applications.

Throughout this description it is expected that an aircraft will hold several IP hosts, each capable of running one or more applications. Each of these application sessions may have counterpart applications running in different hosts in the ground-based Aeronautical Network or in other aircraft also connected to the Aeronautical Network. In the aircraft these hosts are expected to be interconnected in a subnetwork which is connected to an aircraft-located IP router. This IP router is the default route for all aircraft-located hosts and is the only connection from these hosts to off-board hosts.

At least for resiliency purposes, it is envisioned that an aircraft will need multiple connections to the ground network – i.e. the onboard IP router will have at least two connections to ground (e.g. a satellite link and a ground radio link).

The Aeronautical Network is expected to be an overlay enterprise-like (VPN) network running on top the public internet through use of VPN connections. It is still not sure if the Aeronautical Network will be implemented as an overlay VPN, but if for some reason – despite the economic consequences – the Aeronautical Network should end up being a global proprietary network implemented and run by the aeronautical community, a 3GPP network could still be implemented as an access network.

The description uses the 3GPP (UMTS) as the example approach for discussions on how Link Layer mobility would work if deployed as the basis for an Aeronautical Network supporting IP connectivity. The packet mode part of 3GPP is based on an evolution of the GPRS standard and is already widely deployed. The GPRS standard is initially seen as a basis for connecting IP hosts to an IP network, but as will be shown it can also be used in the case where the node of attachment is an IP router.

The case for IPv4 and IPv6 will be different in the ways that IP addressing is deployed and utilized. Both approachs are covered.

As a prerequisite it is anticipated that the aircraft-based IP router is equipped with a Physical Layer interface (NIC) supporting connection to the ground-located 3GPP system.

ACP/1-DP/3


MS: Mobile Station

UTRAN: UMTS Terrestrial Radio Access Network

BGW: Billing Gateway

SGSN: Serving GPRS Support Node

GGSN: Gateway GPRS Support Node

MSC/VLR: Mobile Switching Centre/Visitor Location Register

HLR: Home Location Register

Figure Error! No text of specified style in document.-7 Basic 3GPP network GPRS part 3GPP as access network for aircraft

The 3GPP network in this approach is utilized by aircraft as an access network (see Figure Error! No text of specified style in document.-7). The 3GPP standard provides two different modes of attachment for a mobile node – either transparent or non-transparent.

Transparent mode refers to the operation of the Gateway GPRS Support Node (GGSN) node to which the aircraft-located IP router is attached. It means that the aircraft-located IP router is granted access to the attached IP network without any authentication or authorization. This implies that in transparent mode it is the responsibility of the attached IP network to ensure authentication of attaching aircraft router. Transparent mode is typically used when accessing the public internet.

In non-transparent mode the GGSN will authenticate the aircraft-located router before it is allowed to set up VPN tunnels to the attached IP network. Non-transparent mode is typically use when directly accessing an enterprise network

Aircraft attaching to the 3GPP network

Backbone Network

Enterprise Network2

ISP Network

SGSN GGSN

MSC/VLR

MS

BGW

HLR UTRAN

Enterprise Network1

ACP/1-DP/3


During attachment to the 3GPP network the aircraft-based IP router will obtain an IP address. This IP address will remain static throughout the connection to the ground-based 3GPP network irrespective of movement, as long the aircraft is within reach of the home 3GPP network or any other 3GPP Operator/Service Provider with whom a roaming agreement exits.

Non-transparent mode attachment An aircraft-based IP router attaching to the GPRS network in non- transparent mode will become authenticated and will also obtain a private IP address from the GGSN. This private address will be part of the address space allocated to the Aeronautical Network. In this case the Aeronautical Network is of “Enterprise network2” type in Figure Error! No text of specified style in document.-7.

This attachment is represented as a Packet Data Protocol (PDP) Context, which is a shared state between the aircraft-based router, the SGSN and the GGSN. The aircraft-based router expresses the choice of remote network – which in this case is the Aeronautical Network – as an Access Point Name (APN). When the aircraft-based router sends an Activate PDP Context Request to the SGSN, the SGSN then uses the APN to look up which GGSN provides connectivity to the Aeronautical Network. The GGSN in turn then establishes the desired PDP context with the aircraft-based router.

Transparent mode attachment An aircraft-based IP router attaching to the GPRS network in transparent mode will not become authenticated by the GGSN but will only get a public IP address and become connected to the ISP which is responsible for connection to the Aeronautical Network. In this case the APN will request the connection to the ISP. The Aeronautical Network is of “Enterprise network1” type in Figure Error! No text of specified style in document.-7.

Having become attached to the ISP, it is then the responsibility of the aircraft-based IP router to become authenticated and authorized on the Aeronautical Network reached via the ISP network. This could be done by use of the IKE protocol, for example. Being authorized and authenticated, the aircraft router will be able to establish a VPN connection (IPsec tunnel) covering the full path from the aircraft-based router to the edge router/security gateway of the Aeronautical Network. Within this secure tunnel a private IP address obtained from a DHCP server located within the Aeronautical Network will be used.

The transparent mode of attachment is used if the 3GPP network is mistrusted or if the 3GPP operator does not support Security Gateway functionality at the Gi interface to make direct attachment to the Aeronautical Network.

Addressing of aircraft-based subnets

Concerning the allocation of IP addresses for the aircraft-based subnetwork (router plus hosts), this approach is dependant on whether an IPv4 or IPv6 network is considered.

Airborne IPv4 subnetwork addressing In the case of an IPv4 network the IP address allocated during the attachment phase will be assigned to the airborne router 3GPP interface, whereas the hosts located behind the router will have their addresses as private addresses, allocated from the aircraft router’s built-in DHCP functionality. For applications located on the airborne host to access ground applications, the airborne router will also need to support Network Address Port Translation (NAPT). Port-based NAT is required due to the fact that in the IPv4 approach it is only feasible to have one public IP address for each aircraft. By using NAPT, all airborne hosts will use the same source IPv4 address and will only be differentiated by the port number in UDP/TCP connections. In this approach the aircraft’s IP address will appear as one single point of

ACP/1-DP/3


attachment in the Aeronautical Network, even though it will represent all of the airborne hosts located behind the NAPT.

The drawback of this solution is the need for NAPT and DHCP functionality in the airborne router, although the DHCP functionality would probably be needed in any case in an IPv4-based subnetwork.

Airborne IPv6 subnetwork addressing In the case of an IPv6-based network the IP address can be instantiated by utilizing the IPv6 autoconfiguration approach, which can be either stateless or stateful. The stateless approach is commonly used due to the fact that involvement of DHCPv6 functionality can be omitted.

To make the aircraft appear as a single point of attachment the IP address required in the Activate PDP Context will be an IPv6 prefix instead of a full IPv6 address. From use of the normal stateless IPv6 autoconfiguration procedures the airborne hosts and the airborne router will all achieve globally-unique IPv6 addresses by concatenating the applied prefix with interface identifiers.

Unlike the IPv4 approach, the IPv6 approach will identify each airborne host by a unique IP address allowing host applications to access the Aeronautical Network without the use of NAT functionality whilst still being treated as a single prefix in the 3GPP network.

The general benefit of IPv6 not needing DHCP functionality in the access stage is preserved. The approach of having the aircraft presence as a single point of contact will also, beside internal 3GPP routing efficiency, imply that the radiolink keep-alive sequences will be limited to only care about the airborne router not taking into account all the airborne hosts.

Aircraft connection to the ground Aeronautical Network

An aircraft, having obtained connection to the 3GPP network, must set up a secure VPN tunnel between the aircraft-based part of the Aeronautical Network and the ground-based Aeronautical Network. The tunnel must also, beside security, care for any QoS profile needed to provide the bandwidth required to support airborne applications running on the aircraft. QoS parameters are part of the PDP Context for the 3GPP part of the connection, but for the ground-based part QoS is part of the Service Level Agreements (SLAs) on which the Aeronautical Network is founded through contract with servicing ISPs.

In the non-transparent type of attachment, a secure VPN tunnel between aircraft and the Aeronautical Network relies on the GGSN offering a Security Gateway functionality that enables wireless subscribers to establish VPN tunnels from the GGSN (Gi interface) to the aeronautical ground network, assuming also that the Aeronautical Network entry points are customer-edge routers including Security Gateway functionality. In this case IP packets carried internally in the 3GPP network are terminated at the GGSN before being tunnelled through a secure VPN tunnel towards the aeronautical Security Gateway. This case anticipates that the 3GPP network is a trusted domain.

If the 3GPP network is mistrusted or if the 3GPP operator does not support Security Gateway functionality at the Gi interface, the transparent type of attachment is used. In this case, a VPN connection covering the full path from Aircraft-based router to the ground-based Aeronautical Network Security Gateway is established. This approach requires that the aircraft IP implementation supports IPsec and IKE. It also affects radio link utilization as all IP packets traversing the radiolink will have to be IPsec tunnelled.

It is important to highlight that all IP functionalities required in this solution are IETF-standardized solutions and are already deployed and tested in live networks and as such fulfil the COTS approach.

Whether the transparent or non-transparent mode should be used is for further study and is dependent on the capabilities offered by selected operators/service providers.

ACP/1-DP/3


3.10.2 Approach L1 Analysis

3.10.2.1 TC1 - Support Authorized Traffic Type and Category

The approach is based on a single network login at any one time and there is no concept of allowing for differential service, whether by traffic type or by other means, that could permit a choice between different Air/Ground Networks.

3.10.2.2 TC2 - Multiple Independent Air/ground Sub-Networks

The approach is based on a single network login at any one time. Multiple independent Air/Ground Sub-networks can only be supported if it is accepted that the aircraft has different IP Addresses on each such network. The mobility thus breaks down when multiple independent Air/ground Sub-Networks are introduced.

3.10.2.3 TC3 - Minimal Latency

As packets are always routed via a “home” service provider, packet routing in the ground network may be sub-optimal.

Transfer from one network to another requires the establishment of a new PDP context with the new service provider. There may be a short interruption of service and occasional packet loss during the transition.

3.10.2.4 TC4 - High Availability

Overall availability is very much dependent on the availability of the GGSN and SGSN in addition to the availability of the Air/Ground Network components. The GGSN and SGSN have the potential to be single points of failure.

Existing GGSN and SGSN implementations are providing an operational service and are believed to be specified to 99.999% availability.

3.10.2.5 TC5 - End-to-End Data Integrity

The approach provides normal internet levels of reliability. The occasional packet may be lost due to congestion or during transitions.

3.10.2.6 TC6 – Scaleable

In mobile telephony, roaming is still the exception rather than the norm. However, the numbers of roaming mobiles is still large compared with the numbers of aircraft that are expected to use the service. While SGSN and GGSN sizing will limit the number of aircraft that can be accommodated at any one time, this is primarily an issue of appropriate network capacity planning rather than a hard limit on growth.

3.10.2.7 TC7 – Throughput

The approach adds no additional overhead to internet communications. Whether or not the throughput requirement is met depends primarily on whether the Air/Ground network is appropriate for the use made of it.

3.10.2.8 TC8 – Secure

Assuming end-to-end communication is protected by an end-to-end IPsec tunnel, the following vulnerabilities against Denial of Service Attacks have been identified.

ACP/1-DP/3


1. Masquerade of Aircraft to SGSN/GGSN

2. Masquerade of SGSN/GGSN to aircraft

3. Network Saturation.

It is recommended that the Aircraft communicates with the SGSN/GGSN through an IPsec tunnel in order to protect against the masquerade attacks.

In order to protect against Network Saturation, the ground IP Network supporting Air/Ground Communications should not be connected to the public internet.

3.10.2.9 IC1 - Addition of Service Providers (SP)

The whole basis of the approach is to permit roaming between different Service Providers (SPs).

3.10.2.10 IC2 - Independence of SP or Administration

The approach relies totally on the Service Providers implementing a compatible system and co-ordinating the transfer of mobiles from one Service Provider to another. A Mobile always relies on its “home” service provider to be operational and cannot communicate unless that service provider is functioning. The “home” service provider is effectively a single point of failure. This implementation characteristic is thus not met.

3.10.2.11 IC3 - Open Industry Standard

The 3GPP standards are open industry standards. The 3GPP website lists large number of patents that are claimed to apply to various parts of the 3G system. Without detailed investigation, including testing the validity of the claims, it is not possible say whether IPR issues may apply to the use of these standards for aeronautical communications.

3.10.2.12 IC4 - Mature and Commercially Available

The 3G infrastructure is already deployed in support of mobile telephony. However, work needs to be done to apply the technology to aeronautical communications.

3.10.2.13 IC5 - Permit Closed Network

A closed network can be achieved by using VPN techniques.

3.10.2.14 IC6 - Authentication to Join Network

The PDP process includes authentication of the Mobile user.

ACP/1-DP/3


Chapter 4.4 Summary This report has examined several approaches to mobility in an IPS environment. Note however that the motivation has been not to select a particular approach but rather to determine if IPS mobility is feasible generally to support the needs of the aviation community. The IETF approaches to mobility appear to hold promise for the long term. This report has looked at Mobile IPv6 (MIPv6) which provides host mobility, NEMO which provides network mobility, and extensions to MIPv6 and NEMO. As it stands at this point Mobile IPv6 would appear to provide a host mobility solution; however, the ATN is generally intended to support multiple applications and thus network mobility may be more appropriate as a global solution. The NEMO extensions required to support network mobility are less mature at present than the basic MIPv6 standard, but there is currently a large amount of IETF work in progress in this area. Additionally the extensions to MIPv6 and NEMO being developed by the IETF MONAMI6 working group should hopefully provide the necessary multi-homing and QoS support for mobile nodes and networks in the next couple of years.

This report examined approaches to mobility using inter- and intra-domain routing. An inter-domain routing approach on its own, using BGP, would undoubtedly work, since the current network uses a similar protocol, but concerns centre on the degree of manual configuration required and its responsiveness following network mobility events. IDRP would also work; however, the community would still be left with an aviation-specific solution. OSPF applied on a single routing domain perspective could be employed to alleviate the convergence issues but there may be administrative issues since it is expected that the ATN will be operated by multiple service providers and administrations.

This report examined SCTP as an approach to mobility. SCTP is a standard that was not designed for mobility. Many instances of experimentation have demonstrated that SCTP is capable of supporting mobility, and even has some desirable features not found in network-layer solutions, but this type of use is not directly supported by the standards documents or available vendor implementations.

This report examined two Instant Messaging approaches: XMPP and SIMPLE. Neither of these protocols is directly designed to provide the type of smooth mobility that is under consideration here, although they could be used to provide an ACARS-like service.

This report examined application level mobility. An application based approach to mobility has the advantage of a simplified network layer; however, it does not take advantage of COTS solutions.

The IPSec Tunnel Movement mobility approach is a COTS solution. It exploits the fact that IPSec tunnels protect against identified threaths and, at the same time, provide a mobility solution by moving the tunnels.

The Link Layer Mobility mobility option can work and is based on a COTS solution using the 3GPP/UMTS specifications.

Chapter 5.5 Conclusion

Mobility in an IPS environment is feasible. Candidate approaches have their individual strengths in each of the characteristics identified.

ACP/1-DP/3


Chapter 6.6 References

6.1 ICAO Aeronautical Communications Panel (ACP) References

[ICAO-1] – ICAO Aeronautical Communications Panel (ACP) Working Group of the Whole (WGW) Meeting, June 2005, Agenda Item 2, ATN Issues, Appendix H, “Use of Internet Protocols Suite (IPS) as a Provision for Aeronautical Internetworking” [ICAO-2] - ICAO Doc 9705, “Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)”, Ed. 3, 2002 [SG N1 WP 0506] FAA, “High Level Requirements and Characteristics for an ATN IPS Mobility Solution” [SG N1 WP 0506a] FAA, “Technical and Implementation Characteristics for an ATN IPS Mobility Solution” [SG N1 IP 0701] W. Ivancic Presentation, “Mobile Networking” [SG N1 WP 0507] FAA, “Candidate Approaches For an ATN IPS Mobility Solution” [SG N1 WP 0705] C. Dhas (ERICCSON), “Aircraft Mobility” [SG N1 WP 0707] W. Eddy (NASA), “Standards and Maturity Guidance on Mobility Techniques” [SG N1 WP 0715] EUROCONTROL, “Migration to IPv6 for ATM Air/Ground data communication” [SG N4 IP 0201] FAA, “A Common Mobility Solution for ATN OSI and Internet Protocol Stacks” [SG N4 WP 0804] FAA, “Use of Internet Key Exchange Version 2 in the ATN” [SG N1 IP 12 08] EUROCONTROL, “Mobility and security in the FCS”

6.2 Internet Engineering Task Force (IETF) References [BGP-1] R. Christian, T.Tauber, “BGP Security Requirements” (draft-ietf-rpsec-bgpsecrec-06), April 2006 [BGP-2] D. Ward, “Securing BGPv4 using IPsec” (draft-ward-bgp-ipsec-00), January 2002 [HMIPv6] Hierarchical Mobile IPv6 mobility management (HMIPv6), <draft-ietf-mobileip-hmipv6-08.txt>, IETF, June, 2003 [MIPSHOP_1] J. Arkko, C. Vogt, W. Haddad, “Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6” (draft-arkko-misphop-cga-cba-04.txt), June 2006 [RFC 2328] J. Moy, “OSPF Version 2”, April 1998

ACP/1-DP/3


[RFC 2385] Heffernan, “Protection of BGP Sessions via the TCP MD5 Signature Option", August 1998 [RFC 2740] R. Coultun, D. Ferguson, J. Moy, “OSPF for IPv6”, December, 1999 [RFC 2960] ”Stream Control Transmission Protocol”, October, 2000 [RFC 3107] “Carrying Label Information in BPG-4”, May 2001 [RFC 3261] “SIP: Session Initiation Protocol”, June 2002 [RFC 3290] “Extensible Messaging and Presence Protocol (CMPP): Core”, October, 2004 [RFC 3291] “Extensible Messaging and Presence Protocol (CMPP): Instant Messaging and Presence”, October, 2004 [RFC 3554] S. Bellovin, J. Ionnaindis, A. Keromytis, R. Stewart, “On the use of Stream Control Transmission Protocol (SCTP) with IPsec”, July 2003 [RFC 3682] V. Gill, J. Heasley, D. Meyer, “The Generalized TTL Security Mechanism (GTSM)”, February 2004 [RFC3753] J. Manner, J. Kojo, "Mobility Related Terminology", June 2004 [RFC3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", June 2004 [RFC 3776] J. Arkko, V. Devarapalli, F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, June 2004 [RFC 3923] P. Saint-Andre, “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)”, October 2004 [RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005 [RFC4068] R. Koodli, Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005 [RFC 4225] P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark, “Mobile IP Version 6 Route Optimization Security Design Background”, December 2005 [RFC4283] A. Patel, K. Leung, M. Khalil, H. Akhtar and K. Chowdhury, "Mobile Node Identifier Option for MIPv6", RFC 4283, November 2005 [RFC4285] A. Patel, K. Leung, M. Khalil, H. Akhtar and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006 [RFC 4552] M. Gupta, N. Melam, “Authentication/Confidentiality for OSPFv3”, June2006 [RFC 4555] E. Eronen, Ed., “IKE2 Mobility and Multihoming Protocol”, June 2006

ACP/1-DP/3


6.3 Other References [BOEING-1] A. Dul, “Global IP Network Mobility using Border Gateway Protocol (BGP)”, March 2006 [BOEING-2] Boeing Presentation, “Global_IP_Mobility_IETF62”, Spring 2005 [MCNA] Mobile Communications Network Architecture (MCNA) Architecture Report, Prepared by Boeing Phantom Works for GCNSS Contract, June 2005 [SCTP-1] Wesley M. Eddy, NASA GRC/Verizon FNS. “At What Layer Does Mobility Belong?” [SCTP-2] Riegel, M. and Tuexen M., “Mobile SCTP”, draft-riegel-tuexen-mobile-sctp-05, July 2005. [SCTP-3] Wei Xing, Holger Karl, Adam Wolisz, and Harold Mueller. M-SCTP: Design and Prototypical Implementation of an End-to-End Mobility Concept [SCTP-4] Stewart, R., “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration”, draft-ietf-tsvwg-addip-sctp-12, June 2005. [SCTP-5] Seok J. Koh, Qiaobing Xie, Soohong Daniel Park, Mobile SCTP (mSCTP) for IP Handover Support, <draft-sjkoh-msctp-01.txt>, October 2005.

ACP/1-DP/3


APPENDIX A – ATN Inter-Domain Routing Approach to Mobility The ATN currently uses inter-domain routing as the basis for mobility at the inter-network level. The fundamental concept is that as an aircraft moves and connects to different air-ground routers along its path, routing updates are propagated through the network to maintain reachability with the aircraft. Figure A-1 depicts the process.

A/GRtr

A/GRtr

Air/GroundNetwork

Route to Aircraft

AirborneRtr

AirborneRtr

Route to Aircraft

Route to Aircraft Route to Aircraft

G/GRtr

G/GRtr

G/GRtr

G/GRtr

G/GRtr

GroundEnd

System

GroundEnd

System



ATNBackboneNetwork

time

Figure A-1 - ATN Use of Inter-domain routing for Mobility The ATN routing protocol is the ISO Inter-Domain Routing Protocol (IDRP). It is essentially an enhanced distance vector protocol sometimes referred to as a “path vector” routing protocol. The principle of distance vector routing is that specific changes in connectivity are propagated (i.e., advertised) to affected routers throughout the network. In its simplest form an advertised route is a vector containing a destination address and a distance metric, which is generically a measure of the cost associated with the path being advertised to a particular destination. An IDRP router advertises routes

ACP/1-DP/3


with two components: network layer reachability information (NLRI) and path information. NLRI may be individual network addresses or aggregated addresses. Path information consists of a list of routing domains along the path to a destination identified by the NLRI and other path attributes, which are the unique characteristics of the path. For aircraft the NLRI is an address prefix which uniquely identifies the aircraft and there is a particular path attribute, the security attribute, which is used to signal the traffic type/category, and optionally an indication of subnetwork preference. Figure A-2 is an example use of the security attribute to segregate ATSC traffic from AOC traffic. In this example an aircraft with ATSC and AOC applications that has connectivity over both a Service Provider (SP) Air-Ground Network (e.g. VDL-2) and an Air/Ground Network owned and operated by a CAA. In this example the aircraft might advertise a route to the ATSC and AOC applications over SP Subnetwork and a route to ATSC applications over the CAA Subnetwork. These routes are propagated through the network to the routing domains of the ground applications. With this general conceptual view of the process we can now see how mobility in the ATN is accomplished. As the aircraft moves into the coverage of a new Air/Ground router and out of the coverage of its current Air/Ground router, a new route with the appropriate security attribute (signaling traffic type and subnetwork type) is propagated through the network and the old route is withdrawn. When it comes time to forward packets of information over these routes the following occurs. The forwarding protocol in a router indexes the routing database using the destination address and the traffic type that is signaled in the security parameter of the packet header. Once it finds a route matching the address and traffic type, it sends the packet to the next router, i.e., the one from which it received the route. This process continues until the packet reaches the destination.

ACP/1-DP/3


AirborneRtr

A/GRtr

A/GRtr

A/GRtr

A/GRtr

A/GRtr

A/GRtr

G/GRtr

G/GRtr

G/GRtr

G/GRtr

ATSCCenter

AOCCenter

SPAir/Ground

Network

CAAAir/Ground

Network

G/GRtr

G/GRtr

AOC, ATSC Route

AOC,ATSCRoute AOC, ATSC Route

ATSC Route

ATSC Route

ATSC Route

ATNBackboneNetwork

Figure A-2 - Segregation of Traffic Types over Different Air/Ground Sub-Networks

APPENDIX B – Mobile IP The IP-level mobility support protocol for host mobility is Mobile IPv6 and is specified in [RFC 3775]. The current version, Mobile IPv6, has evolved from the IPv4 version. Figure B-1 depicts the generic environment for Mobile IPv6.

ACP/1-DP/3


Mobile Node'sHome Network

CorrespondentNode

HomeAgent

MobileNode

ForeignNetwork

CorrespondentNode's

Network

AccessRtr

Rtr

AccessRtr

MobileNode time

(1)

(2)

(2)

(3)

Figure B-1 - Mobile IP Operation

The basic operation is that a Mobile Node moves from its Home Network to a Foreign Network. When this occurs the Mobile Node interacts with its Home Agent (HA), which has its permanent Home Address (HoA), to provide it with its new address, called a Care-Of Address (CoA) associated with an Access Router, on a Foreign Network. The interaction (1) occurs with a Binding Update and Binding Acknowledgement Exchange. At this point a Correspondent Node (CN) can communicate with the Mobile Node through the Home Agent, essentially by tunneling traffic through the Home Agent (2). One this has occurred, IPv6 has a feature called route optimization such that the Binding Update and Binding Acknowledgement may be exchanged between the Mobile Node and the Correspondent Node to enable direct communications (3) between the Correspondent Node and Mobile Node rather than tunneling.

— END —

grupo de expertos sobre comunicaciones …±ol/acp_1_dp... · proyecto de sarps sobre el conjunto...

Documents