DOC. 9896 Manual para Implantar La Red (ATN) Utilizando Norma y Protocolos de La Familia de Internet Es

Organizacin de Aviacin Civil Internacional
Aprobado por el Secretario General

y publicado bajo su responsabilidad
Manual para implantar la red
de telecomunicaciones
aeronuticas (ATN) utilizando
normas y protocolos de la familia
de protocolos de Internet (IPS)
Primera edicin 2010
Doc 9896
AN/469

Doc 9896
AN/469

aeronauticas {ATN} utilizando
de protocolos de nternet {P8}

Aprobado por eI Secretario GeneraI
y pubIicado bajo su responsabiIidad

Primera edicin - 2010

Organizacin de Aviacin CiviI InternacionaI

Publicado por separado en espaol, francs, ingls y ruso, por la
ORGANZACN DE AVACN CVL NTERNACONAL
999 University Street, Montral, Quebec, Canada H3C 5H7

La informacin sobre pedidos y una lista completa de los agentes
de ventas y libreros pueden obtenerse en el sitio web de la OAC:
www.icao.int

Primera edicin, 2010

Doc 9896, Manual para implantar la red de telecomunicaciones
aeronuticas (ATN) utilizando normas y protocolos de la familia

Nm. de pedido: 9896
SBN 978-92-9231-736-2

OAC 2011

Reservados todos los derechos. No est permitida la reproduccin de ninguna
parte de esta publicacin, ni su tratamiento informtico, ni su transmisin, de
ninguna forma ni por ningn medio, sin la autorizacin previa y por escrito de la
Organizacin de Aviacin Civil nternacional.

(iii)
ENMIENDAS

La publicacion de enmiendas se anuncia periodicamente en los suplementos
del Catalogo de publicaciones de la OACI; el Catalogo y sus suplementos
pueden consultarse en el sitio web de la OACI: www.icao.int. Las casillas en
blanco Iacilitan la anotacion de estas enmiendas.

REGISTRO DE ENMIENDAS Y CORRIGENDOS

ENMIENDAS CORRIGENDOS
Num. Fecha Anotada por Num. Fecha Anotado por

(v)
PREMBULO

En este documento se definen los protocolos y servicios de comunicaciones de datos que han de utilizarse para
implantar la red de telecomunicaciones aeronuticas (ATN) de la Organizacin de Aviacin Civil nternacional (OAC)
utilizando la familia de protocolos de nternet (PS). El texto de este documento complementa las normas y mtodos
recomendados (SARPS) de la OAC que figuran en el Anexo 10 Telecomunicaciones aeronuticas, Volumen ,
Parte , Captulo 3.

Los criterios editoriales aplicados en este documento son:

Las especificaciones tcnicas detalladas que contienen el tiempo verbal futuro del indicativo son de implantacin
fundamental para asegurar el adecuado funcionamiento de la ATN.

Las especificaciones tcnicas detalladas que incluyen el modo condicional ("debera) son de implantacin
recomendada en la ATN. No obstante, para algunas aplicaciones particulares puede no exigirse que se implante esta
especificacin.

Las especificaciones tcnicas detalladas que comprenden la forma verbal "puede/pueden son opcionales. La utilizacin
o no utilizacin de elementos opcionales no impedir el interfuncionamiento entre nodos ATN/PS.

Este manual se divide en las partes siguientes:

Parte I - Especificaciones tcnicas detaIIadas:

Esta parte contiene una descripcin general de la ATN/PS. Abarca los requisitos de red, transporte y seguridad para la
ATN/PS.

Parte II - ApIicaciones de Ia famiIia de protocoIos de Internet (IPS):

Esta parte contiene una descripcin de las aplicaciones apoyadas por la ATN/PS. Comprende mecanismos de
convergencia y servicios de aplicacin que permiten que las aplicaciones heredadas/pre-existentes de la
ATN/interconexin de sistemas abiertos (OS) puedan funcionar en la capa de transporte ATN/PS.

Parte III - Textos de orientacin:

Esta parte contiene textos de orientacin sobre comunicaciones ATN/PS incluyendo informacin sobre su arquitectura,
as como informacin general para apoyar la implantacin de la ATN/PS.

______________________

(vii)
NDICE

Pgina

Abreviaturas y trminos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (ix)

PARTE I. ESPECIFICACIONES TCNICAS DETALLADAS

CaptuIo 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1
1.1 Resea general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-1

CaptuIo 2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1
2.1 Administracin de la ATN/PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-1
2.2 Requisitos de la capa de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-2
2.3 Requisitos de la capa nternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-2
2.4 Requisitos de la capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-4
2.5 Requisitos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-5
2.6 Actuacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-7

Apndice de la Parte . Plan de numeracin de sistemas autnomos (AS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -AP-1

PARTE II. APLICACIONES DE LA FAMILIA DE PROTOCOLOS DE INTERNET (IPS)

CaptuIo 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-1
1.2 Aplicaciones ATN heredadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-1
1.3 Aplicaciones terrestres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-1
1.4 Aplicaciones aire-tierra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-2
1.5 Capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-21
1.6 Tablas de estado del servicio de dilogo (DS) de PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-27

PARTE III. TEXTO DE ORIENTACIN

CaptuIo 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III-1-1
1.1 Resea general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-1
1.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-2
1.3 Orientacin general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-2
1.4 Pilas de protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-7
1.5 Calidad de servicio (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-16
1.6 Orientacin sobre movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-19
1.7 Orientacin de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-22
1.8 Voz por protocolo nternet (VoP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-29
1.9 mplantaciones PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-31

Apndice de la Parte . Documentos de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -AP-1

______________________

(ix)
ABREVIATURAS Y TRMINOS

Las abreviaturas empleadas en este manual se definen como sigue:

AAC Comunicaciones aeronuticas administrativas
AF Reenvo asegurado
AH Cabecera de autenticacin
ADC Comunicaciones de datos entre instalaciones ATS
ANSC Comunicaciones de servicio de la industria aeronutica
AMHS Sistema de tratamiento de mensajes ATS
ANSP Proveedor de servicios de navegacin area
AOC Comunicaciones aeronuticas operacionales
AS Sistema autnomo
ATC Control del trnsito areo
ATM Gestin del trnsito areo
ATN Red de telecomunicaciones aeronuticas
ATS Servicios de trnsito areo
ATSC Comunicacin de los servicios de trnsito areo
ATSMHS Servicios de tratamiento de mensajes ATS
ATSU Dependencia ATS
BGP Protocolo de pasarela frontera
CN Nodo corresponsal
CRL Lista de revocacin de certificados
DiffServ Servicios diferenciados
ECC Criptografa de curva elptica
ECP Protocolo de control de cifrado
EF Reenvo acelerado
ESP Encapsulado de seguridad de la carga til
FR Regin de informacin de vuelo
FMTP Protocolo de transferencia de gestin de vuelo
HA Agente domstico
HC Control de traspaso
HMAC Cdigo de autenticacin de mensaje condensado (hash)
ANA Autoridad de nmeros asignados de nternet
CMP Protocolo de mensaje de control nternet
CV Valor de verificacin de integridad
ETF Grupo especial sobre ingeniera de nternet
KEv2 ntercambio de claves nternet versin 2
P Protocolo de nternet
PS Familia de protocolos de nternet
Psec Seguridad de protocolos de nternet
Pv4 Protocolo de nternet versin 4
Pv6 Protocolo de nternet versin 6
SO Organizacin nternacional de Normalizacin
LR Registro nternet local
LM Gestin de emplazamiento
MM Gestin de movilidad
MN Nodo mvil

(x) Manual para implantar la ATN utilizando normas y protocolos IPS

MoA Memorando de acuerdo
MSP Proveedor de servicios de movilidad
MTU Unidad de transmisin mxima
OLD ntercambio de datos en lnea
OS nterconexin de sistemas abiertos
PHB Comportamiento por salto
PPP Protocolo punto a punto
QoS Calidad de servicio
RFC Peticin de comentarios
RR Registro nternet regional
ROHC Compresin robusta de cabeceras
RTP Protocolo de transporte en tiempo real
SARPS Normas y mtodos recomendados
TCP Protocolo de control de transmisin
TLS Seguridad de la capa de transporte
TOS Tipo de servicio
UDP Protocolo de datagramas de usuario

Las definiciones siguientes se ajustan a la terminologa del Grupo especial sobre ingeniera de nternet (ETF):

Anfitrin (host). Un host es un nodo que no es un encaminador. Un host es una computadora conectada a la ATN/PS
que proporciona servicios a los usuarios finales.

ControI de traspaso. La funcin de control de traspaso (HC) se utiliza para proporcionar la "continuidad de sesin
para la sesin "en curso del nodo mvil.

Dominio administrativo. Una entidad administrativa en la ATN/PS. Un dominio administrativo puede ser un Estado
individual, un grupo de Estados, una organizacin de la industria aeronutica (p. ej., un proveedor de servicios
aire-tierra), o un proveedor de servicios de navegacin area (ANSP) que gestione recursos y servicios de la
red ATN/PS. Desde una perspectiva de encaminamiento, un dominio administrativo comprende uno o ms
sistemas autnomos.

Encaminador. Un encaminador es un nodo que reenva paquetes de protocolo de nternet (P) no explcitamente
dirigidos a l mismo. Un encaminador gestiona la retransmisin y encaminamiento de datos en trnsito de un
sistema de extremo de origen a un sistema de extremo de destino.

Encaminamiento interdominio (protocoIo de encaminamiento exterior). Protocolos para intercambiar informacin
de encaminamiento entre sistemas autnomos. En algunos casos, pueden utilizarse entre encaminadores
dentro de un sistema autnomo, pero principalmente se aplican al intercambio de informacin entre sistemas
autnomos.

Encaminamiento intradominio (protocoIo de encaminamiento interior). Protocolos para intercambiar informacin
de encaminamiento entre encaminadores dentro de un sistema autnomo.

Gestin de empIazamiento. La funcin de gestin de emplazamiento (LM) se utiliza para hacer el seguimiento del
movimiento de un nodo mvil y ubicar dicho nodo mvil para entrega de datos.

Gestin de moviIidad basada en anfitrin. Un plan de gestin de movilidad (MM) en el cual la sealizacin MM es
ejecutada por el nodo mvil.

Abreviaturas y trminos (xi)

Gestin de moviIidad basada en red. Un plan de gestin de movilidad (MM) en el cual la sealizacin MM es
ejecutada por las entidades de la red en nombre del nodo mvil.

Interred ATN/IPS. La interred ATN/PS consiste en nodos y redes PS que funcionan en un entorno multinacional.

MoviIidad gIobaI. Movilidad a travs de redes de acceso.

MoviIidad IocaI. La movilidad local es la movilidad de la capa de red dentro de una red de acceso.

Nodo. Un dispositivo que implanta Pv6.

Nodo mviI IPS. Un nodo PS que utiliza los servicios de uno o ms proveedores de servicios de movilidad (MSP).

Proveedor de servicios de moviIidad (MSP). Un proveedor de servicios que proporciona servicio mvil Pv6 (es decir
agentes domsticos), dentro de la ATN/PS. Un MSP es un caso de dominio administrativo (AD) que puede ser
un proveedor de servicios de comunicaciones areas (ACSP), un proveedor de servicios de navegacin area
(ANSP), una lnea area, una autoridad aeroportuaria, una organizacin gubernamental, etc.

Red de acceso. Una red caracterizada por una tecnologa de acceso especfica.

Sistema autnomo. Un grupo conectado de uno o ms prefijos P, operado por uno o ms explotadores de redes, que
tiene una poltica de encaminamiento nica y claramente definida.

______________________

Parte I

Especificaciones tcnicas detaIIadas

I-1-1
CaptuIo 1
INTRODUCCIN

1.1 RESEA GENERAL

1.1.1 Este manual contiene las normas y protocolos de comunicacin mnimos que permitirn la
implantacin de una red de telecomunicaciones aeronuticas (ATN) de la OAC basada en la familia de protocolos de
nternet (PS), conocida como ATN/PS. El mbito de este manual se refiere al interfuncionamiento a travs de dominios
administrativos en la interred ATN/PS, aunque el texto tambin puede utilizarse dentro de un dominio administrativo. La
implantacin de la ATN/PS, incluyendo las normas y protocolos que figuran en este manual, se concretar mediante
acuerdos regionales de navegacin area entre los Estados contratantes de la OAC con arreglo al Anexo 10,
Volumen , Parte , Captulo 3, 3.3.2. Los grupos regionales de planificacin y ejecucin (PRG) coordinan dichos
acuerdos.

1.1.2 La arquitectura del protocolo ATN/PS se ilustra en la Figura -1-1. La ATN/PS ha adoptado el mismo
modelo de cuatro capas definido en la norma nternet STD003 de la Sociedad nternet (SOC).

Nota. La STD003 es una combinacin de la RFC 1122 y la RFC 1123 del Grupo especial sobre
ingeniera de Internet (IETF).

1.1.3 Este modelo tiene cuatro capas de abstraccin denominadas capa de enlace, capa nternet o de
protocolo de nternet (P), capa de transporte y capa de aplicacin.

1.1.4 Segn se muestra en la Figura -1-1, este manual no adopta ningn protocolo de capa de enlace
especfico dado que esto constituye un aspecto local o bilateral que no afecta el interfuncionamiento general.

1.1.5 En este manual se adopta la versin 6 (Pv6) del protocolo de nternet para el interfuncionamiento de
la capa de nternet. La implantacin de Pv4 en redes terrestres, para la transicin a Pv6 (o como red permanente) no
se trata en este manual. La Pv6 ha de implantarse en las redes aire-tierra. Para el encaminamiento interdominios se
adopta el protocolo de pasarela frontera 4 (BGP-4) con extensiones.

1.1.6 El protocolo de control de transmisin (TCP) y el protocolo de datagramas de usuario (UDP) se
adopta para los servicios orientados a conexin y sin conexin en la capa de transporte.

1.1.7 En la Parte de este documento figuran mecanismos de convergencia y servicios de aplicacin que
permiten el funcionamiento de aplicaciones heredadas/preexistentes ATN/interconexin de sistemas abiertos (OS) en
la capa de transporte ATN/PS.

1.1.8 En la Parte de este documento figura texto de orientacin para apoyar la implantacin de la
ATN/PS.

I-1-2 Manual para implantar la ATN utilizando normas y protocolos IPS

Figura I-1-1. Arquitectura deI protocoIo ATN/IPS

______________________

Capa de l(arspo(le
|TCP. u0P)
Capa de l(arspo(le
|TCP. u0P)
Capa de
ap||cac|r
Capa de
ap||cac|r
Corve(derc|a
03l/lP3
Corve(derc|a
03l/lP3
C
P
lrle(rel
|l v)
apa
C apa lrle(rel
|l v. 80P-1) P
C apa lrle(rel
|l v. 80P1) P
C apa lrle(rel
|l v) P
C apa de enlace
3uo(ed |oca|
o |rl(ador|r|o
3uo(ed |oca|
o |rl(ador|r|o
3uo(ed
|rl(ador|r|o
C apa de enlace
C apa de enlace
Encaminador
interdominio
Conexiones entre entidades pares
Encaminador
interdominio
C apa de enlace

I-2-1
CaptuIo 2
REQUISITOS

2.1 ADMINISTRACIN DE LA ATN/IPS

La ATN/IPS

2.1.1 La interred ATN/PS consiste en nodos y redes PS que funcionan en un entorno multinacional para
apoyar las comunicaciones de los servicios de trnsito areo (ATSC) as como las comunicaciones de servicio de la
industria aeronutica (ANSC), como las comunicaciones aeronuticas administrativas (AAC) y las comunicaciones
aeronuticas operacionales (AOC).

2.1.2 En este manual, un nodo PS es un dispositivo que aplica Pv6. Existen dos tipos de nodos PS:

un encaminador PS es un nodo PS que reenva paquetes del protocolo de nternet (P) no
explcitamente dirigidos a l mismo; y

un anfitrin PS es un nodo PS que no es un encaminador.

2.1.3 Desde una perspectiva administrativa, la interred ATN/PS est integrada por varios dominios
administrativos interconectados. Un dominio administrativo puede ser un Estado individual, un grupo de Estados (p. ej.,
una regin de la OAC), un proveedor de servicios de comunicaciones areas (ACSP), un proveedor de servicios de
navegacin area (ANSP), o cualquier otra entidad que gestione recursos y servicios de la red ATN/PS.

2.1.4 Cada dominio administrativo que participa en la interred ATN/PS operar uno o ms encaminadores
PS que ejecutan el protocolo de encaminamiento interdominio especificado en este manual.

2.1.5 Desde una perspectiva de encaminamiento, los protocolos de encaminamiento interdominio se
utilizan para intercambiar informacin de encaminamiento entre sistemas autnomos (AS), donde un AS es un grupo
conectado de uno o ms prefijos de direcciones P. La informacin de encaminamiento intercambiada comprende
prefijos de direccin P de diferentes longitudes. Por ejemplo, un prefijo de direccin P intercambiado entre regiones de
la OAC puede ser de menor longitud que un prefijo de direccin P intercambiado entre Estados individuales dentro de
una regin particular.

2.1.6 Los dominios administrativos deberan coordinar sus polticas para transportar el trfico de trnsito
con sus contrapartes.

MoviIidad de Ia ATN/IPS

2.1.7 La movilidad de la ATN/PS se basa en las normas de movilidad Pv6, aplicadas por los proveedores
de servicios de movilidad (MSP).

Nota. Un MSP en la ATN/IPS es un caso de dominio administrativo que puede tratarse de una
ACSP, una ANSP, una lnea area, una autoridad aeroportuaria, un gobierno u otra organizacin aeronutica.


2.1.8 Los MSP de la ATN/PS operarn uno o ms agentes domsticos (HA).

2.2 REQUISITOS DE LA CAPA DE ENLACE

La especificacin de las caractersticas de la capa de enlace para un nodo PS constituye una cuestin local.

2.3 REQUISITOS DE LA CAPA INTERNET

Funcionamiento entre redes generaI de IPv6

2.3.1 Los nodos PS implantarn Pv6 segn se especifica en RFC 2460.

2.3.2 Los nodos PS implantarn la trayectoria de la unidad de transmisin mxima (MTU) de Pv6 segn
se especifica en RFC 1981.

2.3.3 Los nodos PS pondrn en cero el campo de etiqueta de flujo de la cabecera Pv6, dado que no se
utiliza en la ATN/PS.

IPv6 mviI

2.3.4 Los nodos mviles (MN) de PS implantarn Pv6 mvil segn se especifica en RFC 3775.

2.3.5 Los HA de PS implantarn Pv6 mvil segn se especifica en RFC 3775.

2.3.6 Los MN y HA de PS pueden implantar extensiones del Pv6 mvil para permitir el apoyo a la
movilidad de red segn se especifica en RFC 3963.

2.3.7 Los nodos PS que implanten optimizacin de rutas del Pv6 mvil deberan permitir que la
optimizacin de rutas sea activada o desactivada administrativamente, siendo la condicin de desactivada el estado por
defecto.

Nota. El uso de la optimizacin de rutas del IPv6 mvil no es obligatorio por esta especificacin
hasta que el IETF haya elaborado otras RFC normalizadas.

Direccionamiento en Ia red

2.3.8 Los nodos PS implantarn la arquitectura de direccionamiento Pv6 segn se especifica en
RFC 4291.

2.3.9 Los nodos PS utilizarn direcciones Pv6 de carcter global cuando se comuniquen por la ATN/PS.

2.3.10 Los dominios administrativos obtendrn asignaciones de prefijos de direcciones Pv6 de su registro
nternet local (LR) o registro nternet regional (RR).

2.3.11 Los MSP obtendrn una asignacin de prefijo de direccin Pv6 de 32 bits para uso excluso de los
nodos mviles PS o de las redes mviles.

2.3.12 Los MSP deberan utilizar la estructura de direcciones de Pv6 para asignaciones (vase la
Figura -2-1).
Parte I Especificaciones tcnicas detalladas
Captulo 2 Requisitos I-2-3

Figura I-2-1

Nota 1. Con esta estructura, cada aeronave constituye un sitio de extremo IPv6 /56, basado en la
direccin de aeronave de 24 bits de la OACI definida en el Anexo 10, Volumen III, Parte I, Apndice del Captulo 9.

Nota 2. Para servicios de a bordo (ATS, AOC, AAC, etc.), la aeronave puede tener varias subredes
interconectadas a un encaminador mvil, mltiples MSP o una combinacin de ambos.

2.3.13 Los MSP anunciarn a la ATN/PS su prefijo agregado /32.

Encaminamiento interdominio

Nota 1. Los protocolos de encaminamiento interdominio se utilizan para intercambiar informacin
de encaminamiento entre AS.

Nota 2. Para fines de encaminamiento, una AS tiene un identificador nico denominado
nmero AS.

Nota 3. Un dominio administrativo nico puede ser responsable de la gestin de varios AS.

Nota 4. El protocolo de encaminamiento dentro de un AS es un asunto local determinado por la
organizacin de gestin.

2.3.14 Los encaminadores PS que apoyan el encaminamiento dinmico interdominio implantarn la BGP-4
segn se especifica en RFC 4271.

2.3.15 Los encaminadores PS que apoyan el encaminamiento dinmico interdominio implantarn las
extensiones mltiprotocolo de BGP-4 segn se especifica en RFC 2858.

2.3.16 Los dominios administrativos utilizarn los nmeros AS para los encaminadores ATN/PS que
implanten BGP-4.

2.3.17 Los dominios administrativos que utilicen nmeros AS privados se ajustarn al plan de numeracin
AS descrito en el Apndice de la Parte de este documento.

Nota. Los dominios administrativos que exijan nmeros AS privados adicionales deberan coordinar
con la OACI.

2.3.18 Los encaminadores PS que apoyan el encaminamiento dinmico interdominio deberan autenticar los
intercambios de informacin de encaminamiento segn se especifica en RFC 2385.

Deteccin y notificacin de errores

2.3.19 Los nodos PS implantarn el protocolo de mensajes de control de internet (CMPv6) segn se
especifica en RFC 4443.

P(oveedo( de se(v|c|o
de rov|||dad
RlR/LlR
l0
de suo(ed
l0 de |rle(laz
0|(ecc|r de ae(orave
de |a 0ACl
32 o|ls 21 o|ls 8 o|ls 1 o|ls


CaIidad de servicio (QoS)

2.3.20 Los dominios administrativos utilizarn servicios diferenciados (DiffServ) segn se especifica en
RFC 2475 como medio de proporcionar Calidad de servicio (QoS) a las aplicaciones y servicios ATN/PS.

2.3.21 Los dominios administrativos habilitarn las clases de servicio DiffServ de ATN/PS para satisfacer los
requisitos operacionales y de aplicaciones.

2.3.22 Los dominios administrativos que apoyan los servicios vocales de P asignarn dichos servicios al
comportamiento por salto (PHB) de reenvo acelerado (EF) segn se especifica en RFC 3246.

2.3.23 Los dominios administrativos asignarn el trfico de aplicaciones ATN al PHB de reenvo asegurado
(AF) segn se especifica en RFC 2597.

Nota. El reenvo asegurado permite al explotador de ATN/IPS proporcionar seguridades de entrega
en la medida en que el trfico no supere la velocidad suscrita. El exceso de trfico tiene una mayor probabilidad de no
ser tratado si ocurre congestin.

2.3.24 Los dominios administrativos que aplican medidas de prioridad a los PHB AF asignarn medidas
relativas basadas en la correspondencia de prioridades ATN definida en el Anexo 10, Volumen , Parte , Captulo 3,
Tabla 3-1.

Transicin de versiones IP

2.3.25 Los dominios administrativos deberan utilizar el mecanismo de capas P dobles para la
compatibilidad entre Pv6 e Pv4 segn se describe en RFC 4213.

Nota. Esta disposicin asegura que los anfitriones de ATN/IPS tambin apoyan a IPv4 para
retrocompatibilidad con las aplicaciones IPv4 locales.

2.4 REQUISITOS DE LA CAPA DE TRANSPORTE

ProtocoIo de controI de transmisin (TCP)

2.4.1 Los nodos PS implantarn el protocolo de control de transmisin (TCP) segn se especifica en
RFC 793.

2.4.2 Los nodos PS pueden implantar extensiones TCP para lograr una mayor actuacin segn se
especifica en RFC 1323.

ProtocoIo de datagramas de usuario (UDP)

2.4.3 Los anfitriones PS implantarn el protocolo de datagramas de usuario segn se especifica en
RFC 768.


Nmeros de puerto deI protocoIo de transporte

2.4.4 Los nodos PS apoyarn y utilizarn los nmeros de puerto de TCP o UDP que se definen en la
Parte , 2.1.1.2, 2.1.2.3 y 2.3.2 de este documento.

2.5 REQUISITOS DE SEGURIDAD

Nota. El uso de los siguientes requisitos de seguridad para las comunicaciones en la ATN/IPS
debera basarse en un anlisis de amenazas y vulnerabilidad del sistema.

2.5.1 En esta seccin se definen los requisitos de capacidades de seguridad de los nodos PS pero no se
impone su uso para las comunicaciones en ATN/PS.

Seguridad tierra-tierra

Nota. La seguridad de la capa IP en la interred ATN/IPS tierra-tierra se implanta utilizando la
seguridad del protocolo de Internet (IPsec) y el protocolo de la versin 2 del intercambio de planes de Internet (IKEv2).

IPsec/IKEv2 tierra-tierra

2.5.2 Los nodos PS en el entorno tierra-tierra se ajustarn a la arquitectura de seguridad del protocolo de
nternet segn se especifica en RFC 4301.

2.5.3 Los nodos PS en el entorno tierra-tierra implantarn el protocolo de encapsulado de seguridad de la
carga til (ESP) de P segn se especifica en RFC 4303.

2.5.4 Los nodos PS en el entorno tierra-tierra pueden implantar el protocolo de cabecera de autenticacin
(AH) de P segn se especifica en RFC 4302.

2.5.5 Los nodos PS en el entorno tierra-tierra implantarn el protocolo de la versin de intercambio de
claves nternet (KEv2) segn se especifica en RFC 4306.

2.5.6 Los nodos PS en el entorno tierra-tierra implantarn los requisitos de implantacin del algoritmo
criptogrfico para el ESP y AH, si AH se implanta segn se especifica en RFC 4835.

2.5.7 Los nodos PS en el entorno tierra-tierra implantarn el algoritmo de cifrado nulo segn se especifica
en RFC 4835, pero no el algoritmo de autenticacin nulo, al establecer asociaciones de seguridad del protocolo de
nternet (Psec).

2.5.8 Los nodos PS en el entorno tierra-tierra implantarn los algoritmos criptogrficos para utilizar en el
KEv2 segn se especifica en RFC 4307, al negociar algoritmos para intercambio de claves.

2.5.9 Los nodos PS en el entorno tierra-tierra deberan utilizar el perfil de certificado de infraestructura de
claves pblicas X.509 de nternet y la lista de revocacin de certificados (CRL) segn se especifica en RFC 5280,
cuando se utilicen firmas digitales como mtodo de autenticacin de KEv2.

2.5.10 Los nodos PS en el entorno tierra-tierra deberan utilizar el marco de polticas y prcticas de la
infraestructura de claves pblicas X.509 de nternet segn se especifica en RFC 3647, cuando se utilicen firmas
digitales como mtodo de autenticacin de KEv2.


Nota. El Grupo de trabajo sobre seguridad digital (DSWG) de la Air Transport Association (ATA) ha
elaborado una poltica de certificados (Especificacin 42 de ATA) para uso de la comunidad aeronutica. La
Especificacin 42 de ATA incluye perfiles de certificado y CRL que se adecuan a aplicaciones aeronuticas y al
interfuncionamiento con un puente de infraestructura de claves pblicas (PKI) de la industria aeroespacial. Estos
perfiles proporcionan mayor especificidad que el RFC 5280 pero no se oponen a la misma.

Seguridad aire-tierra

Seguridad de la red de acceso aire-tierra

2.5.11 Los nodos mviles PS implantarn las disposiciones de seguridad de la red de acceso para brindar
seguridad a la misma.

Nota. Por ejemplo, las redes de acceso WiMAX, 3GPP, y 3GPP2 tienen disposiciones de
autenticacin y autorizacin.

IPsec/IKEv2 aire-tierra

2.5.12 Los nodos PS en el entorno aire-tierra se ajustarn a la arquitectura de seguridad del protocolo de
internet segn se especifica en RFC 4301.

2.5.13 Los nodos PS en el entorno aire-tierra implantarn el protocolo ESP de P segn se especifica en
RFC 4303.

2.5.14 Los nodos PS en el entorno aire-tierra implantarn AUTH_HMAC_SHA2_256-128 como algoritmo de
integridad para la autenticacin ESP segn se especifica en RFC 4868, al establecer asociaciones de seguridad Psec.

2.5.15 Los nodos PS en el entorno aire-tierra que implanten cifrado implantarn AES-GCM con un valor de
verificacin de la integridad (CV) de 8 octetos y con un atributo de longitud de clave de 128 bits para el cifrado y
autenticacin ESP segn se especifica en RFC 4106.

2.5.16 Los nodos PS en el entorno aire-tierra implantarn el protocolo KEv2 segn se especifica en
RFC 4306.

2.5.17 Los nodos PS en el entorno aire-tierra implantarn KEv2 con las transformaciones siguientes:

a) PRF_HMAC_SHA_256 como funcin pseudo-aleatoria, segn se especifica en RFC 4868.

b) el grupo de protocolos de control de cifrado (ECP) aleatorio de 256 bits para valores de
intercambio de claves Diffie-Hellman, segn se especifica en RFC 4753.

c) ECDSA con SHA-256 en la curva P-256 como mtodo de autenticacin, segn se especifica en
RFC 4754.

d) AES-CBC con claves de 128 bits como transformaciones de cifrado KEv2, segn se especifica
en RFC 3602.

e) HMAC_SHA_256-128 como transformacin de integridad KEv2, segn se especifica en
RFC 4868.

2.5.18 Los nodos PS en el entorno aire-tierra deberan utilizar el perfil de certificados y la lista de revocacin
de certificados (CRL) de la infraestructura de claves pblicas X.509 de nternet, segn se especifica en RFC 5280,
cuando se utilicen firmas digitales como mtodo de autenticacin KEv2.

2.5.19 Los nodos PS en el entorno aire-tierra deberan utilizar el marco de polticas y prcticas de
certificados de la infraestructura de claves pblicas X.509 de nternet segn se especifica en RFC 3647, cuando se
utilicen firmas digitales como mtodo de autenticacin de KEv2.

Nota. El Grupo de trabajo sobre seguridad digital (DSWG) de la Air Transport Association (ATA) ha
elaborado una poltica de certificados (Especificacin 42 de ATA) para uso de la comunidad aeronutica. La
Especificacin 42 de ATA incluye perfiles de certificado y CRL que se adecuan a aplicaciones aeronuticas y al
interfuncionamiento con un puente de infraestructura de claves pblicas (PKI) de la industria aeroespacial. Estos
perfiles proporcionan mayor especificidad que el RFC 5280 pero no se oponen a la misma.

2.5.20 Los nodos PS en el entorno aire-tierra implantarn el funcionamiento de Pv6 mvil con KEv2 y la
arquitectura Psec revisada, segn se especifica en RFC 4877.

Seguridad de la capa de transporte aire-tierra

2.5.21 Los nodos mviles PS y nodos corresponsales pueden implantar el protocolo de seguridad de la
capa de transporte (TLS), segn se especifica en RFC 5246.

2.5.22 Los nodos mviles PS y nodos corresponsales implantarn la familia de cdigos TLS_ECDH_
ECDSA_WTH_AES_128_CBC_SHA, segn se especifica en RFC 4492, cuando utilicen TLS.

Seguridad de la capa de aplicaciones aire-tierra

2.5.23 Los nodos mviles PS y nodos corresponsales pueden implantar la seguridad de la capa de
aplicaciones en el lmite del servicio de dilogo PS, como se especifica en la Parte , 1.4, de este documento.

2.5.24 Los nodos mviles PS y nodos corresponsales anexarn un cdigo de autenticacin de mensaje
condensado (HMAC) cifrado segn se especifica en RFC 2104 utilizando SHA-256 como funcin de condensacin
criptogrfica, cuando se utiliza la seguridad de la capa de aplicaciones.

2.5.25 Una etiqueta HMAC truncada a 32 bits se computar sobre los datos de usuario concatenados con un
nmero de secuencia de envo de 32 bits para proteccin de la reproduccin, cuando se utilice la seguridad de la capa
de aplicacin.

2.5.26 KEv2 se utilizar para establecer claves, segn se especifica en 2.5.12 a 2.5.20, cuando se utilice la
seguridad de la capa de aplicacin.

2.6 ACTUACIN

2.6.1 Los nodos PS pueden implantar RFC 2488 para mejorar la actuacin en los enlaces de satlite.

2.6.2 Los nodos PS pueden implantar el marco de compresin robusta de cabeceras (ROHC) segn se
especifica en RFC 4995 para optimizar la utilizacin de la anchura de banda.

2.6.3 Si se apoya ROHC, entonces se apoyarn, segn corresponda, los siguientes perfiles ROHC:


a) el perfil ROHC para TCP/P especificado en RFC 4996;

b) el perfil ROHC para protocolo de transporte en tiempo real (RTP)/UDP/ESP especificado en
RFC 3095;

c) el perfil ROHC de P-solamente especificado en RFC 4843; y

d) el ROHC sobre el perfil de protocolo punto a punto (PPP) especificado en RFC 3241.

______________________

I-AP-1
APNDICE de Ia Parte I

PIan de numeracin de sistemas autnomos (AS)

Nota. Este plan de numeracin abarca los Estados contratantes de la OACI,
los Estados no contratantes y los territorios.

Regin de la OACI

Pas/organizacin/emplazamiento

Nmero AS
APAC Afganistn 64512
APAC Samoa estadounidense (Estados Unidos) 64513
ESAF Angola 64514
NACC Anguila (Reino Unido) 64515
NACC Antigua y Barbuda 64516
SAM Argentina 64517
NACC Aruba (Pases Bajos) 64518
WACAF Ascensin y Santa Helena (Reino Unido) 64519
APAC Australia 64520
NACC Bahamas 64521
APAC Bangladesh 64522
NACC Barbados 64523
NACC Belice 64524
WACAF Benin 64525
NACC Bermudas (Reino Unido) 64526
APAC Bhutn 64527
SAM Venezuela 64528
SAM Bolivia 64529
ESAF Botswana 64530
SAM Brasil 64531
ESAF Territorio britnico del Ocano ndico 64532
APAC Brunei Darussalam 64533
WACAF Burkina Faso 64534
ESAF Burundi 64535
APAC Camboya 64536
WACAF Camern 64537
NACC Canad 64538
WACAF Cabo Verde 64539
NACC slas Caimn (Reino Unido) 64540
WACAF Repblica Centroafricana 64541
WACAF Chad 64542
SAM Chile 64543
APAC China 64544
SAM Colombia 64545
WACAF Congo 64546
APAC slas Cook 64547
NACC Costa Rica 64548
WACAF Cte d'voire 64549
NACC Cuba 64550
APAC Repblica Popular Democrtica de Corea 64551
WACAF Repblica Democrtica del Congo 64552

I-AP-2 Manual para implantar la ATN utilizando normas y protocolos IPS

Regin de la OACI


Nmero AS
APAC Timor-Leste 64553
ESAF Djibouti 64554
NACC Dominica 64555
NACC Repblica Dominicana 64556
APAC sla de Pascua (Chile) 64557
SAM Ecuador 64558
MD Egipto 64559
NACC El Salvador 64560
WACAF Guinea Ecuatorial 64561
ESAF Eritrea 64562
ESAF Etiopa 64563
SAM slas Malvinas (Reino Unido) 64564
NACC Antillas francesas 64565
WACAF Gabn 64566
WACAF Gambia 64567
WACAF Ghana 64568
NACC Grenada 64569
APAC Guam (Estados Unidos) 64570
NACC Guatemala 64571
WACAF Guinea 64572
WACAF Guinea-Bissau 64573
SAM Guyana 64574
SAM Guyana francesa 64575
NACC Hait 64576
NACC Honduras 64577
APAC Hong Kong, China 64578
APAC slas Wallis y Futuna (Francia) 64579
APAC ndia 64580
APAC ndonesia 64581
MD rn, Repblica slmica del 64582
MD raq 64583
EUR/NAT srael 64584
NACC Jamaica 64585
APAC Japn 64586
APAC Johnston sland (Estados Unidos) 64587
MD Jordania 64588
ESAF Kenya 64589
MD Bahrein 64590
APAC Kingman Reef (Estados Unidos) 64591
APAC Kiribati 64592
MD Kuwait 64593
ESAF Reunin (Francia) 64594
APAC Repblica Democrtica Popular Lao 64595
MD Lbano 64596
ESAF Lesotho 64597
WACAF Liberia 64598
MD Jamahiriya rabe libia 64599
APAC Macao, China 64600
ESAF Madagascar 64601
ESAF Malawi 64602
Apndice Plan de numeracin de sistemas autnomos (AS) I-AP-3

Regin de la OACI


Nmero AS
APAC Malasia 64603
APAC Maldivas 64604
WACAF Mal 64605
APAC slas Marianas (Estados Unidos) 64606
APAC slas Marshall 64607
EUR/NAT Albania 64608
EUR/NAT Armenia 64612
EUR/NAT Austria 64616
EUR/NAT Azerbaiyn 64620
EUR/NAT Belars 64624
EUR/NAT Blgica 64628
EUR/NAT Bosnia y Herzegovina 64632
EUR/NAT Bulgaria 64636
EUR/NAT Croacia 64640
MD Chipre 64644
EUR/NAT Repblica Checa 64648
EUR/NAT Dinamarca 64652
EUR/NAT Estonia 64656
EUR/NAT Finlandia 64660
EUR/NAT Francia 64664
EUR/NAT Georgia 64668
EUR/NAT Alemania 64672
EUR/NAT Grecia 64676
EUR/NAT Hungra 64680
EUR/NAT slandia 64684
EUR/NAT rlanda 64688
EUR/NAT talia 64692
EUR/NAT Kazajstn 64696
EUR/NAT Kirguistn 64700
EUR/NAT Letonia 64704
EUR/NAT Liechtenstein 64706
EUR/NAT Lituania 64708
EUR/NAT Luxemburgo 64712
EUR/NAT La ex Repblica Yugoslava de Macedonia 64716
EUR/NAT Malta 64720
EUR/NAT Repblica de Moldova 64724
EUR/NAT Mnaco 64728
EUR/NAT Pases Bajos 64732
EUR/NAT Noruega 64736
EUR/NAT Polonia 64740
EUR/NAT Portugal 64744
EUR/NAT Rumania 64748
EUR/NAT Federacin de Rusia 64752
EUR/NAT Serbia 64756
EUR/NAT Eslovaquia 64760
EUR/NAT Eslovenia 64764
EUR/NAT Espaa 64768
EUR/NAT Suecia 64772
EUR/NAT Tayikistn 64776
EUR/NAT Suiza 64780

I-AP-4 Manual para implantar la ATN utilizando normas y protocolos IPS

Regin de la OACI


Nmero AS
EUR/NAT La Santa Sede 64782
EUR/NAT Turqua 64784
EUR/NAT Turkmenistn 64788
EUR/NAT Ucrania 64792
EUR/NAT Reino Unido 64796
EUR/NAT Uzbekistn 64800
EUR/NAT Argelia 64804
EUR/NAT Andorra 64808
EUR/NAT Gibraltar (Reino Unido) 64812
EUR/NAT Groenlandia (Dinamarca) 64816
EUR/NAT Montenegro 64820
EUR/NAT Marruecos 64824
EUR/NAT San Marino 64828
EUR/NAT Tnez 64832
EUR/NAT Regional Europa 65108
EUR/NAT Regional Europa 65112
EUR/NAT EUROCONTROL 65208
WACAF Mauritania 65237
ESAF Mauricio 65238
NACC Mxico 65239
APAC Micronesia, Estados Federados de 65240
APAC Midway (Estados Unidos) 65241
APAC Mongolia 65242
NACC Montserrat (Reino Unido) 65243
ESAF Mozambique 65244
APAC Myanmar 65245
ESAF Namibia 65246
APAC Nauru 65247
APAC Nepal 65248
NACC Antillas Neerlandesas 65249
APAC Nueva Caledonia (Francia) 65250
APAC Nueva Zelandia 65251
NACC Nicaragua 65252
WACAF Nger 65253
WACAF Nigeria 65254
APAC Niue (Nueva Zelandia) 65255
MD Omn 65256
APAC Pakistn 65257
APAC Palau 65258
Territorio palestino, ocupado 65259
APAC Palmyra (Estados Unidos) 65260
SAM Panam 65261
APAC Papua Nueva Guinea 65262
Apndice Plan de numeracin de sistemas autnomos (AS) I-AP-5

Regin de la OACI


Nmero AS
SAM Paraguay 65263
SAM Per 65264
APAC Filipinas 65265
APAC slas Pitcairn (Reino Unido) 65266
APAC Polinesia francesa 65267
NACC Puerto Rico (Estados Unidos) 65268
MD Qatar 65269
APAC Repblica de Corea 65270
APAC Fiji 65271
ESAF Rwanda 65272
NACC Saint Kitts y Nevis 65273
NACC Santa Luca 65274
NACC San Vicente y las Granadinas 65275
APAC Samoa 65276
WACAF Santo Tom y Prncipe 65277
MD Arabia Saudita 65278
WACAF Senegal 65279
ESAF Seychelles 65280
WACAF Sierra Leona 65281
APAC Singapur 65282
APAC slas Salomn 65283
ESAF Somalia 65284
ESAF Sudfrica 65285
APAC Sri Lanka 65286
MD Sudn 65287
SAM Suriname 65288
ESAF Swazilandia 65289
MD Repblica rabe Siria 65290
APAC Tailandia 65291
WACAF Togo 65292
APAC Tonga 65293
NACC Trinidad y Tabago 65294
NACC slas Turcas y Caicos (Reino Unido) 65295
APAC Tuvalu 65296
ESAF Uganda 65297
ESAF Comoras 65298
MD Emiratos rabes Unidos 65299
ESAF Repblica Unida de Tanzana 65300
NACC Estados Unidos 65301
SAM Uruguay 65302
APAC Vanuatu 65303
APAC Viet Nam 65304
NACC slas Vrgenes Britnicas (Reino Unido) 65305
NACC slas Vrgenes (Estados Unidos) 65306
APAC Wake sland (Estados Unidos) 65307
Sahara Occidental 65308
MD Yemen 65309
ESAF Zambia 65310
ESAF Zimbabwe 65311
______________________

Parte II

ApIicaciones de Ia famiIia de protocoIos de Internet (IPS)

II-1-1
CaptuIo 1
INTRODUCCIN

1.1 OBJETIVO

Nota. En esta parte se describe la forma en que las aplicaciones ATN heredadas/preexistentes
pueden utilizar la ATN/IPS.

1.2 APLICACIONES ATN HEREDADAS

Nota. Las aplicaciones ATN heredadas se definen en el Manual de disposiciones tcnicas de la red
de telecomunicaciones aeronuticas (ATN) (Doc 9705) o en el Manual de especificaciones tcnicas detalladas para la
red de telecomunicaciones aeronuticas (ATN) utilizando normas y protocolos SO/OS (Doc 9880) (en preparacin).
Las aplicaciones ATN que se describen en el Doc 9705 y el Doc 9880 especifican el uso de capas ATN/OSI para
servicios de comunicacin. En este captulo se describe la forma en que estas aplicaciones utilizan la ATN/IPS con
impacto mnimo en las propias aplicaciones.

1.3 APLICACIONES TERRESTRES

Servicios de tratamiento de mensajes ATS (ATSMHS)

Nota 1. La aplicacin ATSMHS tiene por objeto proporcionar servicios de mensajes genricos en
la ATN.

Nota 2. Los anfitriones IPS que apoyan la aplicacin ATSMHS se ajustarn al Doc 9880, Parte IIB.

1.3.1 Para operar ATSMHS sobre ATN/PS, los anfitriones PS:

a) utilizarn RFC 2126 para proporcionar directamente interfaz TCP/Pv6; o

b) utilizarn RFC 1006 para proporcionar una interfaz TCP/Pv4 combinada con un dispositivo de
traduccin de protocolo Pv4/Pv6.

1.3.2 Los anfitriones PS que apoyan la aplicacin ATSMHS utilizarn el nmero de puerto TCP 102 segn
se especifica en RFC 1006 y RFC 2126.

Comunicaciones de datos entre instaIaciones ATS (AIDC)

Nota 1. La aplicacin AIDC, segn se define en el Manual de aplicaciones de enlace de datos en
los servicios de trnsito areo (Doc 9694), intercambia informacin entre dependencias ATS (ATSU) que apoyan
funciones crticas de control del trnsito areo (ATC), como la notificacin de vuelos que se aproximan al lmite de una
regin de informacin de vuelo (FIR), la coordinacin de las condiciones del lmite y la transferencia de la autoridad de
control y comunicaciones.

II-1-2 Manual para implantar la ATN utilizando normas y protocolos IPS

Nota 2. La AIDC, segn se define en el Doc 9880, Parte IIA, no est planificada actualmente para
implantar en el entorno ATN/IPS.

1.3.3 Los anfitriones PS en la ATN que apoyan los intercambios de aplicaciones ADC pueden utilizar la
aplicacin operacional equivalente que se describe en las especificaciones de EUROCONTROL para el intercambio de
datos en lnea (OLD).

1.3.4 Los anfitriones PS en la ATN que apoyan la aplicacin OLD utilizarn las especificaciones de
EUROCONTROL para que el protocolo de transferencia de mensajes de vuelo opere la aplicacin sobre Pv6.

1.3.5 Los anfitriones PS en la ATN que apoyan el protocolo de transferencia de mensajes de vuelo de
EUROCONTROL utilizarn el nmero de puerto TCP 8500.

1.4 APLICACIONES AIRE-TIERRA

Servicio de diIogo

1.4.1 El servicio de dilogo (DS), segn se documenta en el Doc 9880, Parte , sirve de interfaz entre las
aplicaciones ATN y los protocolos de capa superior ATN/OS a travs de la funcin de control. Para minimizar el
impacto sobre las aplicaciones ATN, se elabor un nuevo servicio de dilogo que apoya la implantacin de las
aplicaciones sobre la ATN/PS. En esta seccin se especifica un sustituto de la interfaz DS ATN/OS con las capas
superiores, denominado PS DS.

1.4.2 El PS DS correlaciona las primitivas TCP/UDP con la interfaz DS de la aplicacin ATN segn se
muestra en la Figura -1-1.

Usuario de la aplicacin
ATN-Aplicacin ASE
TCP/UDP

PS DS

Figura II-1-1. Diagrama de Ias capas superiores IPS ATN

1.4.3 Las primitivas de la DS ATN/OS se harn corresponder como se detalla en las secciones siguientes.
Esta correspondencia se utiliza como sustituto de la especificacin sobre el servicio de comunicaciones de capa
superior (ULCS) del Doc 9880, Parte .
Parte II Aplicaciones de la familia de protocolos de internet (IPS)
Captulo 1 Introduccin II-1-3

1.4.4 El formato de cabecera del paquete de la red de telecomunicaciones aeronuticas (ATNPKT) definido
en 1.4.11 a 1.4.15 describe un formato especial diseado para hacer lugar a la transmisin de datos de aplicacin ATN
sobre la ATN/PS. Puede utilizarse TCP o UDP con el formato de cabecera ATNPKT.

Comunicaciones por enIace de datos entre controIador y piIoto (CPDLC),
vigiIancia dependiente automtica (ADS) y servicios de informacin de vueIo (FIS)

1.4.5 Los anfitriones PS que apoyan aplicaciones CFDLC, ADS y FS de ATN/OS utilizarn el PS DS en
vez del DS que se define en el Doc 9880.

Gestin de contexto (CM)

1.4.6 Los anfitriones PS que apoyan la aplicacin CM de ATN apoyarn las extensiones de su notacin de
sintaxis abstracta (ASN) segn se describe en la Parte , 1.4.39, de este documento.

Nota 1. Este apoyo tiene el fin de permitir la transmisin de la nueva informacin de
direccionamiento IPS contenida en la aplicacin CM actualizada notacin de sintaxis abstracta uno (ASN.1).

Nota 2. La aplicacin CM tambin se conoce como servicio de capacidad de iniciacin de enlace de
datos (DLIC).

Nota 3. Se prev que en una edicin posterior del Doc 9880 se incluirn estas extensiones
tomando precedencia respecto de las especificadas en este documento.

Primitivas deI servicio de diIogo ATN/IPS

Nota. A efectos de mantener el carcter comn con las primitivas de servicio de dilogo ULCS
descritas en el Doc 9880, el IPS DS utiliza los mismos nombres de primitiva.

1.4.7 Los nodos PS que apoyan la funcionalidad DS exhibirn el comportamiento definido por las
primitivas del servicio en las Tablas -1-1 y -1-2.

TabIa II-1-1. Primitivas deI servicio de diIogo

Servicio Descripcin
D-START Es un servicio confirmado utilizado para establecer el nexo entre los usuarios DS en
comunicacin.
D-DATA Este servicio no confirmado se utiliza por un usuario DS para enviar un mensaje de dicho
usuario DS al usuario DS par.
D-END Este es un servicio confirmado utilizado para proporcionar la desconexin ordenada entre los
usuarios DS en comunicacin, de modo que cualquier dato en trnsito entre las partes se
entregue antes de que tenga efecto la desconexin.
D-ABORT Este servicio no confirmado puede invocarse para interrumpir la relacin entre los usuarios DS
en comunicacin. Todos los datos en trnsito entre ellos pueden perderse.


Servicio Descripcin
D-P-ABORT Este servicio no confirmado se utiliza para indicar al usuario DS que el proveedor de servicios de
dilogo ha interrumpido la relacin con el usuario DS par. Todos los datos en trnsito entre los
usuarios DS en comunicacin pueden perderse.
D-UNT-DATA Este servicio no confirmado se utiliza para enviar un dato nico de un usuario DS par a otro.
Cualquier problema en la entrega del dato al receptor no se sealar al originador. Este servicio
se especifica en la Tabla -1-7.

TabIa II-1-2. Parmetros de Ias primitivas deI servicio de diIogo

Servicio Parmetros
D-START dentificacin de entidad par llamada
dentificacin de sistema llamado
Direccin de presentacin llamada
dentificacin de entidad par llamante
dentificacin de sistema llamante
Direccin de presentacin llamante
Nmero de versin de usuario DS
Requisitos de seguridad
Calidad de servicio
Resultado
Fuente de rechazo
Datos de usuario
D-DATA Datos de usuario
D-END Resultado
Datos de usuario
D-ABORT Originador
Datos de usuario
D-P-ABORT (sin parmetros)

Nota. Los parmetros de las primitivas DS se hacen corresponder con la cabecera IP, un campo de
la cabecera del protocolo de transporte o con datos de transporte en el formato ATNPKT segn se define en 1.4.11 a
1.4.15.

Definicin de servicio de diIogo

Secuencia de primitivas

1.4.8 Los nodos PS que apoyan las funciones DS permitirn que los usuarios DS pares en comunicacin:

a) establezcan un dilogo;

b) intercambien datos de usuario;

c) terminen un dilogo en forma ordenada o anormal;

d) estn informados de una terminacin de dilogo anormal del DS debida a una falla de
comunicaciones subyacentes; y

e) sean coherentes con el uso apropiado de las primitivas del servicio correspondiente.

1.4.9 Cualquiera de los dos usuarios DS puede enviar datos en cualquier momento despus del
intercambio inicial D-START, utilizando el servicio D-DATA. En circunstancias normales, el dilogo se libera por un
usuario DS invocando el servicio D-END. Un dilogo se libera a normalmente mediante el servicio D-ABORT. Si el
proveedor del servicio subyacente libera en forma anormal el dilogo, los usuarios DS son notificados mediante la
indicacin de servicio D-P-ABORT.

1.4.10 Slo es vlido para el usuario DS expedir y recibir primitivas para un "dilogo en la secuencia
especificada en la Tabla -1-3. Los casilleros de la tabla que contienen "Y indican primitivas vlidas que pueden seguir
las cabeceras de la columna de primitiva DS. Por ejemplo, slo "D-START ind puede seguir a la primitiva "D-END cnf.

TabIa II-1-3. Secuencia de primitivas DS para un diIogo en un usuario DS

la or|m|r|va 0$ 0-$T/RT 0-0/T/ 0-Eh0 0-/3DRT 0-P-/3DRT
Pueoe |r seou|oa oe |a or|m|r|va 0$ Y reo cnl |no rso reo |no reo cnl |no rso reo |no |no
1 D-START req
2 D-START cnf (aceptado) Y
3 D-START ind Y Y Y Y Y
4 D-START rsp (aceptado) Y
5 D-DATA req Y Y Y Y Y
6 D-DATA ind Y Y Y Y Y
7 D-END req Y Y Y Y
8 D-END cnf (aceptado) Y
9 D-END ind Y Y Y Y
10 D-END rsp (aceptado) Y
11 D-ABORT req Y Y Y Y Y Y Y Y
12 D-ABORT ind Y Y Y Y Y Y Y Y
13 D-P-ABORT ind Y Y Y Y Y Y Y Y

Formato ATNPKT

1.4.11 La finalidad del ATNPKT es transmitir informacin entre usuarios DS pares durante el procesamiento
de una primitiva DS. Se lleva en la parte datos del protocolo de transporte (TCP o UDP) y se utiliza para transmitir
parmetros de las primitivas del servicio que no pueden correlacionarse con los campos existentes y de la cabecera P
o de transporte. El ATNPKT tambin transmitir informacin para indicar la funcin de protocolo DS (p. ej., el tipo de
primitiva DS).


1.4.12 Para proporcionar el uso ms eficiente de la anchura de banda, se emplea un formato de longitud
variable. El formato de longitud variable permitir el procesamiento optimizado de la primitiva DS. Esto es un aspecto
importante cuando se opere en banda estrecha o con costosos enlaces de comunicaciones aire-tierra.

1.4.13 El formato ATNPKT contiene dos partes:

una parte fija que est presente independientemente de la primitiva DS; y

una parte variable para campos opcionales.

1.4.14 La presencia de parmetros opcionales se indica estableciendo bits dentro de la parte fija
del ATNPKT. Estos bits se denominan "banderas de presencia y constituyen el "campo de presencia. La posicin
de un parmetro opcional en la parte variable se determina mediante su posicin en el campo de presencia. En la
Figura -1-2 se muestra el formato ATNPKT.

Figura II-1-2. Formato ATNPKT

1.4.15 La representacin de parmetros opcionales, en la parte variable del ATNPKT, se determinar
mediante la definicin del parmetro. Los parmetros de longitud variable estarn representados en el formato LV (es
decir longitud + valor). Los parmetros de longitud fija estarn representados por su valor.

Campos ATNPKT

1.4.16 Los formatos de campo ATNPKT se describen aplicando la convencin (<bits> /<proveedor> / <uso>)
donde:

<bits> indica el tamao en bits del valor de campo (excluyendo la longitud para los
parmetros LV);

<proveedor> indica si el valor es proporcionado por el usuario DS como parmetro de primitiva
(externo) o asignado por el proveedor DS (interno);

<uso> indica si el usuario DS presentar, o no, un valor al invocar el parmetro de primitiva
correspondiente (opcional versus obligatorio).

Parte fija del ATNPKT

Versin de ATNPKT

Nota. La versin de ATNPKT indica la versin de la cabecera ATNPKT.

1.4.17 La versin ATNPKT se pondr a 1 y tendr un formato de 4 bits/interno/obligatorio.

Nota 1. La versin ATNPKT es un nmero que aumentar para cada modificacin subsiguiente
del ATNPKT.
Versin
ATNPKT
Primitiva
DS
Tipo de
tecnologa
de aplicacin
m
s
Banderas de presencia
Parte variable
24
Parte fija
0 16 8
0
0 1 2 3 4 5 6 7 8 9 10 11

Nota 2. La reserva de 4 bits permitir hasta 15 versiones.

Nota 3. Este campo no se expone a nivel del usuario DS; ser establecido por el proveedor DS.

Primitiva DS

Nota. El campo de primitiva DS es establecido por el proveedor DS para indicar el tipo de primitiva
DS del paquete.

1.4.18 El campo de primitiva DS adoptar uno de los valores especificados a continuacin y tendr un
formato de 4 bits /interno/obligatorio:

Valor Primitiva DS asignada
1 D-START
2 D-START cnf
3 D-END
4 D-END cnf
5 D-DATA
6 D-ABORT
7 D-UNT-DATA
8 D-ACK
9 D-KEEPALVE

Nota 1. La reserva de 4 bits dar lugar hasta 16 elementos de protocolo, permitiendo definir hasta
7 primitivas adicionales.

Nota 2. La primitiva D-P-ABORT no figura en la lista, y no se enva de extremo a extremo. Tras la
recepcin de un suceso anormal o la expiracin de un temporizador de inactividad, D-P-ABORT se indicar al
usuario DS.

Tipo de tecnologa de aplicacin

Nota. El tipo de tecnologa de aplicacin identifica el tipo de informacin de aplicacin que se
transporta. Otras aplicaciones tambin pueden aprovechar la infraestructura IPS, p. ej., FANS-1/A, ACARS, etc.

1.4.19 El tipo de tecnologa de aplicacin se pondr a un valor de b000 para indicar "ATN/PS DS y tendr
un formato de 3 bits/interno/opcional.

Nota. El uso o definicin de estos valores queda fuera del mbito de este manual.

El bit "ms"

Nota. El bit "ms" se utilizar para la segmentacin y reensamblaje de datagramas UDP; es parte
del mecanismo de fiabilidad que se describe con ms detalles en 1.5.14.

1.4.20 El bit "ms se pondr a 0 para indicar un segmento nico o ltimo; se pondr a 1 para indicar el
primer segmento o segmento intermedio y tendr un formato de 1 bit/interno/opcional.


Campo de presencia

Nota. El campo de presencia es una serie de banderas (o bits) de presencia que indican la
presencia, o no, de campos opcionales en la parte variable del ATNPKT.

1.4.21 El campo de presencia tendr un formato de 12 bits/interno/obligatorio.

1.4.22 La bandera de presencia se pondr a 0 para indicar la ausencia de un campo opcional; se pondr a 1
para indicar la presencia de un campo opcional.

1.4.23 Los detalles de los campos opcionales se ajustarn a la Tabla -1-4.

TabIa II-1-4. DetaIIes de Ios campos de presencia

Bit Campo opcional
Tamao
(en bits) Formato
1
Descripcin
0 dentificacin de fuente 16 V Identificador de conexin DS del emisor
1 dentificacin de destino 16 V Identificador de conexin DS del receptor
2 Nmeros secuenciales 8 V Nmeros secuenciales (Ns, Nr)
3 Tiempo de inactividad 8 V Valor del temporizador de inactividad del emisor (en
minutos)
4 dentificacin de entidad par llamada 24 a 64 (+8) LV
2
Identificador de entidad par llamada (proporcionada por el
usuario DS local)
5 dentificacin de entidad par llamante 24 a 64 (+8) LV
2
Identificador de entidad par llamante (proporcionada por el
usuario DS local)
6 Versin del contenido 8 V Versin de los datos de aplicacin transportados
7 ndicador de seguridad 8 V Requisitos de seguridad:
0 sin seguridad (valor por defecto)
1 Dilogo asegurado apoyando gestin de claves
2 Dilogo asegurado
3 . 255 reservado
8 Calidad de servicio 8 V Clase de encaminamiento ATSC:
0 sin preferencia de poltica de tipo de trfico
1 "A"
2 "B"
3 "C"
4 "D"
5 "E"
6 "F"
7 "G"
8 "H"
9 . 255 reservado
9 Resultado 8 V Resultado de una peticin de iniciar o terminar un dilogo:
0 aceptado (valor por defecto)
1 rechazado transitorio
2 rechazado permanente
3 . 255 reservado

Bit Campo opcional
Tamao
(en bits) Formato
1
Descripcin
10 Originador 8 V Originador de la interrupcin:
0 usuario (valor por defecto)
1 proveedor
2 . 255 reservado
11 Datos de usuario UDP: 0 a 8
184
3
(+16)
TCP: tamao
variable (+16)
LV
2
Datos de usuario (proporcionados por el usuario DS local)

Nota 1. Un campo opcional est presente en la parte variable cuando el bit correspondiente se
pone en el campo de presencia y tiene uno de los formatos siguientes:

V = valor; o
LV = longitud (1 o 2 byte(s)) + valor

Nota 2. Los bits adicionales requeridos para la parte longitud de los parmetros LV se indican entre
parntesis (en bits) en la tercera columna de la Tabla II-1-4.

Nota 3. En 1.4.39 figuran detalles sobre el tamao del parmetro de datos de usuario.

Partes variables del ATNPKT

Nota. Las partes variables del ATNPKT se proporcionarn dependiendo de si se invoca la primitiva
DS y del estado actual de la aplicacin que utiliza el IPS DS.

1.4.24 La posicin de un campo opcional en la parte variable del ATNPKT corresponder a la posicin
relativa de su bit correspondiente en el campo de presencia (es decir las opciones estn en el mismo orden que las
banderas de presencia).

Identificacin de fuente

Nota. La identificacin de fuente indica la conexin DS del lado emisor y es parte del mecanismo de
fiabilidad que se describen en ms detalle en 1.5.

1.4.25 La identificacin de fuente estar presente en las primitivas D-START y D-START cnf y tambin
cuando se transmite D-ABORT despus de D-START y antes de recibirse D-START cnf, y tendr un formato de 16 bits/
interno/opcional.

Identificacin de destino

Nota. La identificacin de destino indica la conexin del lado receptor y es parte de los mecanismos
de fiabilidad que se describen en ms detalle en 1.5.

1.4.26 La identificacin de destino estar presente en las primitivas D-START cnf, D-DATA, D-END, D-END
cnf, D-ABORT, D-ACK y D-KEEPALVE y tendr un formato de 16 bits/interno/opcional.

Nmeros secuenciales

Nota. El campo de nmeros secuenciales contiene los nmeros secuenciales que han de incluirse
en el ATNPKT. El mecanismo se aplica para detectar la prdida y la duplicacin de datagramas UDP; permite el acuse


de recibo implcito (es decir la confirmacin del servicio) o explcito (D-ACK). Este campo es parte de los mecanismos
de fiabilidad que se describen en ms detalle en 1.5.

1.4.27 El campo de nmero secuenciales estar presente en todas las primitivas DS sobre UDP y tendr un
formato de 8 bits/interno/obligatorio segn se detalla en la Figura -1-3.

Figura II-1-3. Formato de nmero secuenciaI

N(S) - [0.15] nmero secuencial del ATNPKT enviado.
N(R) - [0.15] nmero secuencial previsto del siguiente ATNPKT que ha de recibirse.

Nota. Para D-ACK y D-KEEPALIVE, slo el N(R) tiene significado en la transmisin.

1.4.28 Cuando se utilicen nmeros secuenciales con D-ACK y D-KEEPALVE sobre UDP, el valor actual del
nmero secuencial enviado para N(S) puede utilizarse sin aumentarlo subsecuentemente despus de la transmisin.

Tiempo de inactividad

Nota. El tiempo de inactividad indica el valor temporal (en minutos) del temporizador de inactividad
en la parte emisora. Este campo se utiliza como parte de los mecanismos de fiabilidad, que se describen en ms detalle
en 1.5.

1.4.29 El tiempo de inactividad estar presente opcionalmente en las primitivas D-START y D-START cnf y
tendr un formato de 8 bits/interno/opcional.

1.4.30 Cuando el usuario DS no proporciona este parmetro, el proveedor DS fuente utilizar el valor por
defecto de 4 minutos como temporizador de inactividad.

Identificacin de entidad par llamada

Nota. El identificador de entidad par llamada identifica al usuario DS par previsto.

1.4.31 La identificacin de entidad par llamada ser un identificador de aeronave de la OAC de 24 bits o un
designador de instalacin de la OAC de 3 a 8 caracteres y tendr el formato de 24 a 64 bits/externo/opcional.

Identificacin de entidad par llamante

Nota. La identificacin de entidad par llamante identifica al usuario DS par iniciador.

1.4.32 La identificacin de entidad par llamante ser una direccin de aeronave de la OAC de 24 bits o un
designador de instalacin de la OAC de 3 a 8 caracteres y tendr el formato de 24 a 64 bits/externo/opcional.

Versin del contenido

Nota. El campo de versin del contenido se utiliza para indicar el nmero de versin de la
aplicacin.

1.4.33 La versin del contenido ser la versin de la sintaxis ASN.1 utilizada para el campo de datos de
usuario y tendr el formato de 8 bits/externo/opcional.
N(S) N(R)

Indicador de seguridad

Nota 1. El parmetro de indicador de seguridad se utiliza para indicar el nivel de seguridad que ha
de aplicarse al dilogo. En el Doc 9880, este campo se conoce como "requisitos de seguridad"; aqu se ha cambiado la
denominacin dado que "requisito" no es realmente apropiado en este caso. Constituye realmente una indicacin del
usuario DS local sobre el tipo de procedimiento de seguridad que ha de utilizarse para establecer un intercambio de
dilogo seguro.

1.4.34 El parmetro de indicador de seguridad tendr uno de los valores siguientes y un formato de 8 bits/
externo/opcional:

Valor Nivel de seguridad
0 Sin seguridad (valor por defecto)
1 Dilogo asegurado que apoya la gestin de claves
2 Dilogo asegurado
3 255 Reservado

Nota. Si el usuario DS no determina esta parmetro el nivel de seguridad se establece en el valor
por defecto, es decir sin seguridad.

Calidad de servicio

Nota. El parmetro de calidad de servicio (QoS) se utiliza para indicar el requisito QoS del usuario
DS que es un valor correspondiente a la clase de encaminamiento ATSC o a la tasa de errores residuales (RER).

1.4.35 El parmetro QoS tendr los valores siguientes y un formato de 8 bits/externo/opcional:

1. La clase de encaminamiento ATSC proporcionada por el usuario DS, como sigue:

Valor Descripcin de la clase de encaminamiento ATSC
0 No hay preferencia sobre polticas de tipo de trfico
1 "A
2 "B
3 "C
4 "D
5 "E
6 "F
7 "G
8 "H
9 255 Reservado


2. El RER como se define a continuacin:

Valor Nivel RER
0 Bajo
1 Medio
2 Alto

3. La prioridad de la aplicacin ATN puede indicarse insertando valores de punto de cdigo de
servicios diferenciados (DSCP) en la cabecera Pv6 segn se describe en la Parte , 1.5.9 y 1.5.10, de este
documento.

Nota. La prioridad es normalmente establecida por la capa de red, de modo que no es necesario
que la aplicacin proporcione una. La capa de red puede discernir la prioridad a partir del nmero de puerto que se
utiliza de la direccin IP y establecer con arreglo a ello el campo de servicios diferenciados. Tambin cabe sealar que
los procedimientos de gestin de red pueden conducir a una remarcacin del paquete, independientemente de las
indicaciones de la aplicacin inicial, para ser coherentes con las definiciones de servicios diferenciados de la red local.

1.4.36 La suma de control UDP puede activarse para valores RER bajos o medianos y no activarse para un
valor RER alto.

Nota. Las sumas de control TCP estn siempre activadas. Las sumas de control UDP se activan
por defecto.

Resultado

Nota. El resultado es establecido por el usuario DS de destino para indicar si la iniciacin o
terminacin del dilogo pedida se ha completado con xito.

1.4.37 El resultado tendr el formato de 8 bits/externo/obligatorio y tomar uno de los valores siguientes:

Valor Definicin
0 Aceptado
1 Rechazado (transitorio)
2 Rechazado (permanente)
3 255 Reservado

Originador

Nota. El originador indica la fuente de un D-ABORT.

1.4.38 El originador tendr uno de los valores siguientes y un formato de 8 bits/externo/opcional:

Valor Definicin
0 Usuario (por defecto)
1 Proveedor
2 255 Reservado

Nota. Cuando el usuario DS no proporciona este parmetro se supone el valor por defecto.

Datos de usuario

Nota. Los datos de usuario contienen los datos de aplicacin codificados segn las reglas de
codificacin compactadas (PER).

1.4.39 Los datos de usuario tendrn el formato de UDP: 0 a 8 184, TCP: tamao variable/externo/opcional.

Nota 1. El tamao mximo de datos de usuario para un servicio D-DATA es el tamao mximo de
datagrama UDP (8 192 bytes) reducido en el tamao de la cabecera ATNPKT (8 bytes). Para otras primitivas de
servicio, el tamao mximo de datos de usuario debe ajustarse sobre la base del tamao de la parte fija de la cabecera
ms el tamao de las partes de longitud variable para esa primitiva de servicio particular.

Nota 2. El DS IPS segmentar los datagramas UDP con datos de usuario que excedan 1 024 bytes,
como se describe en 1.5.14, los que debern reensamblarse por el receptor.

Correspondencia de parmetros IPS DS

Nota. El IPS DS presenta un interfaz idntico del ULCS a las aplicaciones ATN. Como tales, los
parmetros del IPS DS son idnticos a los del ULCS. No obstante, existe una correspondencia diferente entre los
contenidos de esos parmetros. Estas correspondencias modificadas se resumen en la Tabla II-1-5 y se detallan para
cada primitiva en la Tabla II-1-7.

TabIa II-1-5. Correspondencia entre parmetros de IPS DS y ULCS DS

Parmetro DS
Visible al usuario DS Cabecera IP
Cabecera
de protocolo de
transporte
ATNPKT
(vase la Tabla II-1-4) Comentario
dentificacin de
entidad par llamada
dentificacin de
entidad par llamada
Esta puede ser una direccin de aeronave
de la OAC de 24 bits o un designador de
instalacin de la OAC (4 a 8 caracteres).
dentificacin de
sistema llamado
Nmero de
puerto de
destino
Este es un nmero de puerto registrado
asignado a cada aplicacin ATN (vase
1.5.4).
Direccin de
presentacin llamada
Direccin P de
destino
Direccin P de la aplicacin ATN receptora.
dentificacin de
entidad par llamante
dentificacin de
entidad par llamante
Esta puede ser una direccin de aeronave
de la OAC de 24 bits o un designador de
instalacin de la OAC (4 a 8 caracteres).
dentificacin de
sistema llamante
Nmero de
puerto fuente
Utilizando el TCP, este nmero de puerto se
asigna dinmicamente por la pila de
protocolo de transporte de la parte cliente.
Con UDP, este nmero de puerto tiene
normalmente un valor esttico que es el
mismo que el nmero de puerto de destino.
Direccin de
presentacin llamante
Direccin P de
fuente
Direccin P del originador de la aplicacin
ATN.


Parmetro DS
Visible al usuario DS Cabecera IP
Cabecera
de protocolo de
transporte
ATNPKT
(vase la Tabla II-1-4) Comentario
Nmero de versin de
usuario DS
Versin de contenido Esta es el nmero de versin de la
aplicacin.
Requisitos de
seguridad
Requisitos de seguridad 00 Sin seguridad
01 Dilogo asegurado que apoya la gestin
de claves
02 Dilogo asegurado
03 Reservado
Calidad de servicio Calidad de servicio Este parmetro se transportar solamente
cuando se proporcione como "clase de
encaminamiento ATSC; el RER y la
prioridad no se indican de extremo a extremo
pero se indican opcionalmente al PS DS y
se usan localmente.
Resultado Resultado 00 Aceptado
01 Rechazado (permanente)
02 Rechazado (transitorio)
Fuente rechazada 00 Usuario DS remoto
01 Proveedor DS local

Se proporciona localmente slo en la
primitiva de confirmacin y no se transfiere
de extremo a extremo.
Originador Originador 0 Usuario
1 Proveedor (por defecto)
2-255 Reservado

Datos de usuario Datos de usuario Estos son los datos codificados segn las
reglas de codificacin compactada (PER)
proporcionados por la aplicacin.

1.4.40 La inclusin de parmetros opcionales ATNPKT para cada mensaje de protocolo DS se ajustar a la
Tabla -1-6:

TabIa II-1-6. Parmetros ATNPKT para mensaje de protocoIo DS

(O = opcional, M = obligatorio, - = uso impedido)
1) La identificacin de fuente est presente si D-ABORT se enva despus D-START y antes de recibirse D-START cnf.
2) La identificacin de destino est ausente si D-ABORT se enva despus D-START y antes de recibirse D-START cnf.
3) Para mensajes segmentados, este parmetro est presente nicamente en el primer segmento.
4) Para mensajes segmentados, este parmetro est presente en todos los segmentos.


Mensaje de protocolo 0-$7AR7 0-$7AR7 cnf 0-0A7A 0-0hl7-0A7A 0-Eh0 0-Eh0 cnf 0-A80R7 0-ACK 0-KEEPALlVE
Parte f|ja
\e(s|r ATNPKT V V V V V V V V V
P(|r|l|va 03 V V V V V V V V V
T|po de lecro|odia de
ap||cac|r V V V V V V V V V
Vs 0 0 0 0 0
8arde(a de p(eserc|a V V V V V V V V V
Parte var|ab|e
lderl|l|cac|r de luerle V |1) V |1) - - - - |1) - -
lderl|l|cac|r de desl|ro - V |1) V |1) V |1) V |1) V |2) V V
Nure(os secuerc|a|es V |1) V |1) V |1) V V |1) V |1) V V V
T|erpo de |racl|v|dad 0 |3) 0 |3) - - - - - - -
lderl|l|cac|r de erl|dad
pa( ||arada 0 |3) - - 0 - - - - -
lderl|l|cac|r de erl|dad
pa( ||ararle 0 |3) - - 0 - - - - -
\e(s|r de corler|do 0 |3) 0 |3) - 0 - - - - -
lrd|cado( de sedu(|dad 0 |3) 0 |3) - 0 - - - - -
Ca||dad de se(v|c|o 0 |3) - - - - - - - -
Resu|lado - V |3) - - - V |3) - - -
0(|d|rado( - - - - - - 0 - -
0alos de usua(|o 0 |1) 0 |1) V |1) V 0 |1) 0 |1) 0 - -

Primitivas de servicio de dilogo

Nota. Para proporcionar los servicios indicados en 1.4.7, se utilizan las primitivas que figuran en la
Tabla II-1-7. Cada primitiva puede estar directamente expuesta al usuario DS (primitivas peticin/respuesta) o puede
ser notificada al usuario DS por el proveedor DS (primitivas indicacin/confirmacin).

TabIa II-1-7. DetaIIes de primitivas deI servicio de diIogo

Primitiva de interfaz Descripcin del servicio de dilogo Usuario DS
Proveedor
DS
D-START req Peticin de iniciar dilogo con un usuario DS par

D-START ind Informar a un usuario DS local que un usuario DS par pidi una
iniciacin de dilogo

D-START rsp Completar una iniciacin de dilogo pendiente con respuesta
positiva o negativa

D-START cnf Informar al usuario DS local que el usuario DS par complet la
iniciacin de dilogo pendiente con respuesta positiva o negativa


Primitiva de interfaz Descripcin del servicio de dilogo Usuario DS
Proveedor
DS
D-UNT-DATA req Enviar un datagrama del usuario DS local al usuario DS par (no se
garantiza la entrega de extremo a extremo del datagrama)

D-UNT-DATA ind Informar al usuario DS local que se ha recibido un datagrama de
un usuario DS par

D-DATA req Enviar un datagrama del usuario DS local a un usuario DS par
sobre un dilogo establecido

D-DATA ind Informar a un usuario DS local que se ha recibido un datagrama
de un usuario DS par sobre un dilogo establecido

D-END req Pedir terminacin del dilogo con un usuario DS par

D-END ind Informar al usuario DS local que el usuario DS par ha pedido la
terminacin de dilogo

D-END rsp Completar una terminacin de dilogo pendiente con respuesta
positiva o negativa

D-END cnf Informar a un usuario DS local que el usuario DS par complet la
terminacin de dilogo pendiente con respuesta positiva o
negativa

D-ABORT req Peticin de interrumpir un dilogo con un usuario DS par

D-ABORT ind Informar al usuario DS local que el usuario DS par pidi
interrumpir el dilogo

D-P-ABORT ind Dilogo interrumpido por el proveedor DS

Diagramas de secuencia temporal del servicio de dilogo

1.4.41 Las Figuras -1-4 a -1-13 siguientes ilustran los intercambios del protocolo de servicios de dilogo
entre proveedores DS de fuente y de destino, incluyendo la parte de datos de usuario ATNPKT.

Figura II-1-4. Servicio D-START
Respuesta D-START
ndicacin D-START
Peticin D-START
D-START
Servicio de dilogo
D-START cnf
Confirmacin D-START

Figura II-1-5. Servicio D-DATA (TCP)

Figura II-1-6. Servicio D-DATA (UDP)

Nota. La Figura II-1-5 muestra el servicio D-DATA sobre una conexin TCP. Debido al carcter de
la conexin, no se requiere ACK. La Figura II-1-6 muestra el servicio D-DATA sobre UDP. Para proporcionar acuse de
recibo explcito del paquete UDP, el receptor del D-DATA ATNPKT devuelve el D-ACK.

ndicacin D-DATA
Peticin D-DATA
D-DATA
Servicio de dilogo
Respuesta D-ACK
ndicacin D-DATA
Peticin D-DATA
D-DATA
Servicio de dilogo
D-ACK
Confirmacin D-ACK


Figura II-1-7. Servicio D-END

Figura II-1-8. Servicio D-ABORT

Respuesta D-END
ndicacin D-END
Peticin D-END
D-END
Servicio de dilogo
D-END cnf
Confirmacin D-END
ndicacin D-ABORT
Peticin D-ABORT
D-ABORT
Servicio de dilogo

Figura II-1-9. Servicio D-P-ABORT

Nota. No se ha definido un formato ATNPKT para el servicio D-P-ABORT, dado que es una
indicacin local al usuario DS.

Figura II-1-10. Servicio D-UNIT-DATA (TCP)
Servicio de dilogo
ndicacin D-P-ABORT ndicacin D-P-ABORT
ndicacin D-UNT-DATA
Peticin D-UNT DATA
D-UNT-DATA
Servicio de dilogo


Figura II-1-11. Servicio D-UNIT-DATA (UDP)

Nota. La Figura II-1-10 muestra el servicio D-UNIT-DATA sobre una conexin TCP. Debido al
carcter de la conexin, no se requiere ACK. La Figura II-1-11 muestra el servicio D-UNIT-DATA sobre UDP. Para
proporcionar acuse de recibo explcito del paquete UDP, el receptor del D-UNIT-DATA ATNPKT devuelve un D-ACK.

Figura II-1-12. Servicio D-ACK

Peticin D-ACK
ndicaci D-UNT-DATA n
Peticin D-UNT-DATA
D-UNT-DATA
Servicio de dilogo
D-ACK
ndicacin D-ACK
ndicacin D-ACK
Peticin D-ACK
D-ACK
Servicio de dilogo

Figura II-1-13. Servicio D-KEEPALIVE

1.5 CAPA DE TRANSPORTE

Resea

1.5.1 El PS DS se ha diseado para permitir al usuario seleccionar TCP o UDP para el protocolo de
transporte. A efectos de sencillez, las operaciones relacionadas con el puerto no se consideran como primitivas.

1.5.2 La primitiva de la capa de transporte figuran en la Tabla -1-8.

TabIa II-1-8. Primitivas de Ia capa de transporte utiIizadas en eI IPS DS

Capa de transporte
Primitiva de interfaz Descripcin TCP UDP
OPEN (ABERTO) Establecimiento de la conexin (denominado "activo" en el
lado iniciador y "pasivo" en el otro lado)

CLOSE (CERRADO) Terminacin de la conexin (denominada "activa" en el lado
iniciador y "pasiva" en el otro lado)

RECEVE (RECBR) Recibir datagrama de nivel de transporte
SEND (ENVAR) Enviar datagrama de nivel de transporte

1.5.3 En la Tabla -1-9 figura la correspondencia que ha de aplicarse entre el servicio de dilogo y las
primitivas de capa de transporte.

ndicacin D-KEEPALVE
Peticin D-KEEPALVE
D-KEEPALVE
Servicio de dilogo


TabIa II-1-9. Correspondencia entre capa de transporte y servicio IPS DS

Servicio de dilogo Capa de transporte
Servicio Primitiva de interfaz Primitiva de interfaz Datos de
usuario
Protocolo
Inicializacin
OPEN (pasivo) TCP
Establecimiento de dilogo
D-START D-START req OPEN (activo) TCP
SEND D-START TCP, UDP
D-START ind RECEVE D-START
D-START rsp SEND D-START cnf
D-START cnf RECEVE D-START cnf
Intercambio de datos sin conexin
D-UNT-DATA D-UNT-DATA req SEND D-UNTDATA UDP
D-UNT-DATA ind RECEVE D-UNTDATA
Intercambio de datos en modo conectado
D-DATA D-DATA req SEND D-DATA TCP, UDP
D-DATA ind RECEVE D-DATA
Terminacin de dilogo ordenada (iniciada por el
usuario)

D-END D-END req SEND D-END TCP, UDP
D-END ind RECEVE D-END
D-END rsp SEND D-END cnf
CLOSE (pasivo) TCP
D-END cnf RECEVE D-END cnf TCP, UDP
CLOSE(activo) TCP
Terminacin de dilogo forzada (iniciada por el usuario)
D-ABORT D-ABORT req SEND D-ABORT TCP, UDP
CLOSE (activo) TCP
D-ABORT ind RECEVE D-ABORT TCP, UDP
CLOSE (pasivo) TCP
Terminacin de dilogo debida a error (iniciada por el
proveedor)

D-P-ABORT D-P-ABORT ind RECEVE/SEND (falla) TCP, UDP
CLOSE (pasivo) imprevisto TCP


Nmeros de puerto

1.5.4 Los siguientes nmeros de puerto TCP y UDP se utilizarn al apoyar aplicaciones ATN
heredadas/preexistentes sobre la ATN/PS:

5910 Gestin de contexto
5911 Comunicaciones por enlace de datos entre controlador y piloto
5912 Servicios de informacin de vuelo
5913 Vigilancia dependiente automtica

Nota. Estos nmeros de puerto estn registrados por la Autoridad de nmeros asignados de
Internet (IANA) en: http://www.iana.org/assignments/port-numbers.

Suministro de servicio de diIogo sobre UDP

Nota. UDP se emplea mayormente para aplicaciones que requieren radiodifusin o multidifusin,
pero tambin pueden utilizarse para aplicaciones "peticin-respuesta" sencillas siempre que se aada alguna fiabilidad
en los niveles superiores. UDP no garantiza la entrega de los datagramas en el servicio extremo a extremo. Por esta
razn, se implantan mecanismos adicionales en la IPS DS para tratar las limitaciones UDP, bsicamente el truncado,
prdida o duplicado de datagramas UDP. Estos mecanismos se especifican en los prrafos siguientes.

1.5.5 Para aadir alguna fiabilidad al actuar sobre UDP, el proveedor DS implantar los mecanismos que
se describen en la Tabla -1-10.

TabIa II-1-10. Mecanismos de fiabiIidad UDP de IPS DS

(O = opcional, M = obligatorio)
Proporcionar "conexin de dilogo" sobre UDP

identificacin de conexiones
temporizacin de conexin
temporizacin a terminacin
M
O
O
Detectar la prdida de datagramas UDP utilizando acuse de recibo uno a uno
(por conexin)

temporizador de retransmisin + cmputo mximo de repeticiones
acuse de recibo explcito
acuse de recibo complementario (retardo mximo antes del acuse
de recibo)

M
M

O
Detectar conexiones no apareadas de larga duracin

temporizador de inactividad + temporizador de transmisin
"mantener vivo (keep alive) M
Tratamiento de truncado de datagramas UDP

segmentacin/reensamblado de datagramas M


Identificadores de conexin

1.5.6 Cada entidad par DS participante asignar un par de identificadores de conexin, identificacin de
fuente e identificacin de destino, durante la fase de conexin (D-START/D-START cnf) que se usarn sobre todo
intercambio subsiguiente.

Nota 1. La identificacin de conexin DS por encima de la capa UDP se tratar mediante la
asignacin de este par de identificadores de conexin.

Nota 2. El tamao de 2 bytes de estos identificadores se escogi debido a que permitir que el
proveedor DS asocie una semntica particular al identificador de dilogo asignado a su lado (sin interferir con el usuario
DS para involucrado). En tal caso, el identificador podra ser un ndice en una tabla de contexto, hacindolo
implcitamente nico, pero tambin permitiendo al proveedor DS receptor encontrar el contexto sin tener que aplicar
mltiples criterios de bsqueda y recorrer toda la tabla de contextos.

1.5.7 La identificacin de fuente y la identificacin de destino se transmitirn en la parte variable del
ATNPKT sobre una base de las primitivas DS que se describen en la Tabla -1-11:

TabIa II-1-11. Uso de identificacin de fuente e identificacin de destino

(O = opcional, M = obligatorio)

Campo de primitivas DS Identificacin de fuente Identificacin de destino
D-START M dentificador
proporcionado por el
proveedor DS que inicia el
dilogo; permitir al
usuario encontrar el
contexto del dilogo
durante toda la duracin
de ste.
No asignado en este momento.
D-START cnf M dentificador
proveedor DS que acepta
el dilogo; permitir al
proveedor encontrar el
contexto de dilogo
durante toda la duracin
de ste.
M dentificador del proveedor DS que
inici el dilogo.
D-DATA No hay necesidad de
transportarlo dado que no
tendra sentido para el
proveedor DS de destino.
M dentificador del proveedor DS par.
D-END - No hay necesidad de
D-END cnf No hay necesidad de

Campo de primitivas DS Identificacin de fuente Identificacin de destino
D-ABORT antes
D-START cnf
M dentificador
proveedor DS que inicia el
dilogo.
Desconocido por ahora.
D-ABORT otros casos No hay necesidad de

Deteccin de datagramas perdidos

Nota 1. La prdida de datagramas UDP se detecta mediante un mecanismo de acuse de recibo de
uno a uno, por conexin DS, es decir, un paquete de datos enviado y un acuse de recibo que ha de recibirse antes de
poder enviar ms datos.

Nota 2. El acuse de recibo puede complementarse con un mensaje de dilogo en el sentido
opuesto para el mismo dilogo; esto ser posible, por ejemplo, con primitivas confirmadas.

1.5.8 Para servicios DS no confirmados, el usuario receptor utilizar un acuse de recibo explcito enviando
un ATNPKT sin datos y con un valor especfico (D-ACK) como "primitiva DS.

Nota 1. Para fines de acuse de recibo, se utilizar el campo "nmeros secuenciales" de la parte
variable de la ATNPKT.

Nota 2. Este nmero secuencial se requiere para evitar la entrega de datos duplicados al usuario
DS par despus de la retransmisin (es decir, si se ha perdido un D-ACK), y en circunstancias ms excepcionales, es
decir cuando la red entrega fuera de secuencia datagramas UDP.

1.5.9 El proveedor DS asociar un nmero secuencial incrementado a los ATNPKT salientes y almacenar
el nmero secuencial del ltimo ATNPKT recibido del proveedor DS par para acusar recibo del mismo en una
transmisin subsiguiente.

1.5.10 Los nmeros secuenciales salientes y entrantes sern transportados respectivamente por los
subcampos N(S) y N(R) del campo "nmeros secuenciales.

Nota 1. N(S) corresponde al nmero secuencial actual del ATNPKT que se ha enviado; N(R) es el
nmero secuencial previsto del siguiente ATNPKT que ha de recibirse.

Nota 2. El uso de los nmeros secuenciales permitir al proveedor DS detectar ATNPKT faltantes o
duplicados. Hay como mximo un ATNPKT sin acuse de recibo; por esta razn, no habr acuse de recibo agrupado y
no hay necesidad de implantar un mecanismo de rechazo selectivo.

Nota 3. La falta de un acuse de recibo oportuno entraar una retransmisin. Un nmero excesivo
de retransmisiones interrumpir la conexin DS. Los valores de temporizacin y el nmero mximo de retransmisiones
se detallan en la Tabla II-1-12.


Temporizacin de conexiones

Nota. Para evitar conexiones DS no apareadas de larga duracin, se implanta un sencillo
mecanismo para detectar inactividades. Ambos extremos de la conexin DS transmitan un paquete de "mantener viva"
cuando expire el "temporizador de mantener viva la transmisin". El emisor reactiva el temporizador "mantener viva"
cada vez que enva datos en esa conexin, evitando innecesarias transmisiones de mantener vivo.

1.5.11 Un "mantener viva (ATNPKT sin datos y con un valor D-KEEPALVE como primitiva DS) se enviar
con cada expiracin del temporizador de transmisin mantener vivo local.

1.5.12 El temporizador de "mantener viva la transmisin puede ponerse a 1/3 del temporizador de
inactividad del proveedor DS par, o a un 1/3 del temporizador de inactividad por defecto.

Nota. La falta de recepcin de datos o de paquetes "mantener viva" por un intervalo de tiempo
correspondiente al tiempo de inactividad interrumpir la conexin DS. El valor de parmetro para este tiempo se detalla
en la Tabla II-1-12.

1.5.13 El campo ATNPKT opcional "tiempo de inactividad puede utilizarse en el momento de inicializar el
dilogo (es decir, en D-START y D-START cnf) de modo que cada proveedor DS pueda ajustar su temporizador
"mantener viva local.

Nota. La ausencia de tiempo de inactividad indica que se utiliza el valor de tiempo de inactividad
por defecto como en la Tabla I-1-12.

Indicador "ms"

Nota. La mayora de los mensajes de aplicacin ATN no exceden de 1 000 bytes. Adems, el valor
sugerido de 1 024 bytes no supera la carga til IP (1 500 bytes) en la trama Ethernet (1 518 bytes).

1.5.14 Un D-DATA cuya parte de datos de usuario supere los 1 024 bytes se segmentar utilizando el bit
"ms reservado en la parte fija del ATNPKT.

Nota. Al recibo de un D-DATA con el bit "ms" puesto, el lado receptor es responsable de ordenar y
reensamblar los datos segmentados.

Parmetros deI proveedor DS

1.5.15 Los valores especificados en la Tabla -1-12 se aplicarn a los parmetros del proveedor DS
identificados:

TabIa II-1-12. Parmetros de proveedor DS

Parmetro Mnimo Mximo Por defecto
Retardo antes de retransmisin 1 segundo 60 segundos 15 segundos
Mximo nmero de transmisiones 1 10 3
Tiempo de inactividad 3 minutos 15 minutos 4 minutos

1.6 TABLAS DE ESTADO DEL SERVICIO DE DILOGO (DS) DE IPS

TabIa II-1-13. TabIa de estado DS de IPS para TCP
$ucesos

Estado
0-l0LE 0-C0NNECTE0 0-3TART-3ENT
0-3TART-
RECEl\E0 0-TRAN3FER 0-EN0-3ENT
0-EN0-
RECEl\E0
0-wAlT-
CL03E
0uranre lase oe
|n|c|a||zac|on
0PEN |pas|vo)
3
u
c
e
s
o
s

d
e

u
s
u
a
(
|
o

0
3

0-3TART (ec 0PEN |acl|vo) -
Co((esp. 0-3TART
(ec a 0-3TART -
3EN0 |0-3TART) -
lrd(esa( eslado
0-3TART-3ENT

0-3TART (sp Co((esp. 0-3TART
crl a 0-3TART crl
- 3EN0 |0-3TART
crl) - Er caso de
(espuesla pos|l|va:
- 3la(l l|racl -
lrd(esa( eslado
0-TRAN3FER - s|
ro: - |rd(esa(
eslado 0-wAlT-
CL03E

0-0ATA (ec Co((esp. 0-0ATA
(ec a 0-0ATA -
3EN0 |0-0ATA)

0-EN0 (ec Carce|a( l|racl -
Co((esp. 0-EN0
(ec a 0-EN0 -
3EN0 |0-EN0) -
lrd(esa( eslado
0-EN0-3ENT

0-EN0 (sp Co((esp. 0-EN0
(sp a 0-EN0 crl -
3EN0 |0-EN0 crl)
-Er caso de
(espuesla pos|l|va
: -lrd(esa( eslado
0-wAlT-CL03E -
s ro: - lr|c|a( l|racl -
lrd(esa( eslado
0-TRAN3FER

0-A80RT (ec Co((esp.
0-A80RT (ec
a 0-A80RT -
3EN0
|0-A80RT) -
lrd(esa( eslado
0-wAlT-CL03E
Co((esp.
0-A80RT (ec a
0-A80RT - 3EN0
|0-A80RT) -
lrd(esa( eslado
0-wAlT-CL03E
Carce|a( l|racl -
Co((esp.
0-A80RT (ec a
0-A80RT - 3EN0
|0-A80RT) -
lrd(esa( eslado
0-wAlT-CL03E
Co((esp.
0-A80RT (ec a
0-A80RT - 3EN0
|0-A80RT) -
lrd(esa( eslado
0-wAlT-CL03E
Co((esp.
0-A80RT (ec a
0-A80RT - 3EN0
|0-A80RT) -
lrd(esa( eslado
0-wAlT-CL03E

3
u
c
e
s
o
s

T
C
P

0PEN |pas|vo)
corp|elado
lrd(esa( eslado
0-C0NNECTE0

RECEl\E
|0-3TART)
Co((esp.
0-3TART a
0-3TART |rd -
Nol|l. 0-3TART
|rd a usua(|o 03
- |rd(esa( eslado
0-3TART-
RECEl\E0


$ucesos

Estado
0-3TART-
0-EN0-
RECEl\E0
0-wAlT-
CL03E
0uranre lase oe
|n|c|a||zac|on
0PEN |pas|vo)
RECEl\E
|0-3TART crl)
Co((esp.
0-3TART crl a
0-3TART crl -
Nol|l. 0-3TART
crl a usua(|o 03
- Er caso de
(espuesla
pos|l|va: - lr|c|a(
l|racl - lrd(esa(
eslado
0-TRAN3FER -
3| ro: - CL03E
|acl|va) -
lrd(esa( eslado
0-l0LE

RECEl\E |0-
0ATA)
Repore( l|racl -
Co((esp. 0-0ATA
a 0-0ATA |rd -
Nol|l. 0-0ATA |rd
a usua(|o 03

RECEl\E |0-
EN0)
Carce|a(
l|racl - Co((esp.
0-EN0 a 0-EN0
|rd - Nol|l. 0-EN0
|rd a usua(|o 03 -
lrd(esa( eslado
0-EN0-
RECEl\E0

RECEl\E
|0-EN0 crl)
Co((esp.
0-EN0 crl a
0-EN0 crl - Nol|l.
0-EN0 crl a
usua(|o 03 - Er
caso de (espuesla
pos|l|va: - CL03E
|acl|vo) - lrd(esa(
eslado 0-l0LE -
3| ro : - lr|c|a( l|racl
- lrd(esa( eslado
0-TRAN3FER

3
u
c
e
s
o
s

T
C
P

RECEl\E
|0-A80RT)
Co((esp.
0-A80RT a
0-A80RT |rd -
Nol|l. 0-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Carce|a( l|racl -
Co((esp.
0-A80RT a
0-A80RT |rd -
No(l|l. 0-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Co((esp.
0-A80RT a
0-A80RT |rd -
Nol|l. 0-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Co((esp.
0-A80RT a
0-A80RT |rd -
Nol|l. 0-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE

CL03E |pas|vo) CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Nol|l.
0-P-A80RT |rd
a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Nol|l. 0-P-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Carce|a( l|racl -
Nol|l. 0-P-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Nol|l. 0-P-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
Nol|l. 0-P-A80RT
|rd a usua(|o 03 -
CL03E |acl|vo) -
lrd(esa( eslado
0-l0LE
CL03E
|acl|va) -
lrd(esa(
eslado
0-l0LE

$ucesos

Estado
0-3TART-
0-EN0-
RECEl\E0
0-wAlT-
CL03E
0uranre lase oe
|n|c|a||zac|on
0PEN |pas|vo)
3
u
c
e
s
o
s

d
e

p
(
o
v
e
e
d
o
(

0
3

l|racl exp|(a Nol|l. 0-P-A80RT
|rd a usua(|o 03 -
lrd(esa( eslado
0-l0LE

TabIa II-1-14. TabIa de estado DS IPS para UDP

$ucesos
Esraoo
0-l0LE 0-3TART-3ENT 0-3TART-RECEl\E0 0-TRAN3FER 0-EN0-3ENT 0-EN0-RECEl\E0
3
u
c
e
s
o
s

d
e

u
s
u
a
(
|
o

0
3

0-3TART (ec Co((esp. 0-3TART (ec
a 0-3TART - 3EN0
|0-3TART) - lr|c|a(
lcorrecl - lrd(esa(
eslado 0-3TART-
3ENT

0-3TART (sp Co((esp. 0-3TART crl
a 0-3TART crl - 3EN0
|0-3TART crl) - Er
caso de (espuesla
pos|l|va: - lr|c|a( l|racl -
lrd(esa( eslado
0-TRAN3FER - 3| ro:
- lrd(esa( eslado
0-l0LE

0-0ATA (ec Co((esp. 0-0ATA (ec a
0-0ATA - 3EN0
|0-0ATA)

0-EN0 (ec Carce|a( l|racl -
Co((esp. 0-EN0 (ec a
0-EN0 - 3EN0
|0-EN0) - |r|c|a( lle(r -
lrd(esa( eslado
0-EN0-3ENT

0-EN0 (sp Co((esp. 0-EN0 (sp a
0-EN0 crl - 3EN0
|0-EN0 crl) - Er caso
de (espuesla pos|l|va: -
lrd(esa( eslado 0-l0LE
- 3| ro: - lr|c|a( l|racl -
lrd(esa( eslado
0-TRAN3FER
0-A80RT (ec Carce|a( lcorrecl -
Co((esp. 0-A80RT (ec
a 0-A80RT - 3EN0
|0-A80RT) - lrd(esa(
eslado 0-l0LE
a 0-A80RT - 3EN0
eslado 0-l0LE
Carce|a( l|racl -
a 0-A80RT - 3EN0
eslado 0-l0LE
Carce|a( lle(r - Vap
0-A80RT (ec a
0-A80RT - 3EN0
eslado 0-l0LE
a 0-A80RT - 3EN0
eslado 0-l0LE


$ucesos
Esraoo
0-l0LE 0-3TART-3ENT 0-3TART-RECEl\E0 0-TRAN3FER 0-EN0-3ENT 0-EN0-RECEl\E0

3
u
c
e
s
o
s

u
0
P

RECEl\E |0-
3TART)
Co((esp. 0-3TART a
0-3TART |rd - Nol|l.
0-3TART |rd a usua(|o
03 - lrd(esa( eslado
0-3TART-RECEl\E0

RECEl\E |0-3TART
crl)
Carce|a( lcorrecl -
Co((esp. 0-3TART crl
a 0-3TART crl - Nol|l.
0-3TART crl a usua(|o
03 -Er caso de
(espuesla pos|l|va: -
lr|c|a( l|racl - lrd(esa(
eslado 0-TRAN3FER -
s| ro: -lrd(esa( eslado
0-l0LE

RECEl\E |0-0ATA) Resel l|racl - Co((esp.
0-0ATA a 0-0ATA |rd
- Nol|l. 0-0ATA |rd a
usua(|o 03

RECEl\E |0-EN0) Carce|a( l|racl -
Co((esp. 0-EN0 a
0-EN0 |rd - Nol|l.
0-EN0 |rd a usua(|o
0-EN0-RECEl\E0

RECEl\E
|0-EN0 crl)
Carce|a( lle(r -Co((esp.
0-EN0 crl a 0-EN0
crl - Nol|l. 0-EN0 crl
a usua(|o 03- Er caso
de (espuesla pos|l|va: -
lrd(esa( eslado
0-l0LE - s| ro: -
lr|c|a(l l|racl - lrd(esa(
eslado 0-TRAN3FER

RECEl\E
|0-A80RT)
Co((esp. 0-A80RT a
0-A80RT |rd - Nol|l.
0-A80RT |rd a usua(|o
0-l0LE
Carce|a( l|racl -
Co((esp. 0-A80RT a
0-l0LE
Carce|a( lle(r -
Co((esp. 0-A80RT a
0-l0LE
Co((esp. 0-A80RT a
0-l0LE

3
u
c
e
s
o
s

0
3

lcorrecl exp|(a Nol|l. 0-P-A80RT |rd a
usua(|o 03 - lrd(esa(
eslado 0-l0LE

l|racl exp|(a Nol|l. 0-P-A80RT |rd
a usua(|o 03 -

lle(r exp|(a Nol|l. 0-P-A80RT |rd
a usua(|o 03 -

______________________

Parte III

Texto de orientacin

III-1-1
CAPTULO 1
INTRODUCCIN

1.1 RESEA GENERAL

1.1.1 Esta parte del manual contiene informacin para ayudar a los Estados contratantes de la OAC a
introducir una red ATN/PS para apoyar los servicios de gestin del trnsito areo (ATM). La red ATN/PS debera
proporcionar los siguientes servicios bsicos mnimos.

1.1.2 Estos servicios bsicos permiten que las aplicaciones ATN proporcionen servicios de voz y datos
utilizando la prioridad y seguridad apropiadas en la red ATN/PS.

1.1.3 Los protocolos que se analizan en este documento se basan en el modelo de referencia de
interconexin de sistemas abiertos (OS). En la Figura -1-1 se muestra la relacin entre OS, ATN/OS y los protocolos
ATN/PS utilizando un modelo de cuatro capas del ETF.

Capa de aplicacin 7
Capa de sesin 5
Capa de transporte 4
Capa de red 3
Capa de enlace 2
Capa fsica 1

Capa de presentacin 6
ModeIo de referencia OSI ProtocoIos ATN/OSI

ATN/IPS

Byte acelerado
Byte acelerado

Aplicaciones ATN
(p. ej., CMP, X.400)

Capa de transporte
clase 4

LLC/MAC

Pv6 y CMPv6

TCP/UDP

Servicios
de aplicacin
consolidados
(p. ej., SMTP,
SNMPv3,
FTP, X.400
y Telnet)
LAP B (HDLC)

Capa fsica
(p. ej., EA-232, V.35, X.21)
Capa fsica
(p. ej., FDD, 802.X)
SNDCF

ES-S/CLNP

X.25 PLP

Figura III-1-1. ModeIo de referencia de protocoIos

III-1-2 Manual para implantar la ATN utilizando normas y protocolos IPS

1.2 ANTECEDENTES

La ATN/PS se ha establecido con el objetivo especfico de proporcionar servicios ATM mundiales basados en
tecnologas comerciales disponibles. Con arreglo a las normas y mtodos recomendados (SARPS) de la OAC, los
servicios ATN pueden proporcionarse utilizando los protocolos de la OAC basados en OS segn se especifica en
Doc 9705 y Doc 9880, o como se especifica en este manual. El presente manual describe el enfoque tcnico para las
redes basadas en PS y permitir que los Estados contratantes de la OAC proporcionen servicios ATM.

1.3 ORIENTACIN GENERAL

1.3.1 Esta seccin contiene informacin sobre la implantacin de ATN/PS para aplicaciones ATN,
multidifusin y VoP.

LA ATN/IPS

La interred ATN/IPS

1.3.2 La interred ATN/PS est especfica y exclusivamente dirigida a proporcionar servicios de
comunicaciones de datos a las organizaciones proveedoras de servicios de trnsito areo (ATS) y a las compaas
explotadoras de aeronaves apoyando los siguientes tipos de trfico de comunicaciones:

Comunicaciones ATS (ATSC). Comunicaciones relacionadas con los servicios de trnsito areo
incluyendo el control de trnsito areo, informacin aeronutica y meteorolgica, notificacin de
posicin y servicios relativos a la seguridad y regularidad de los vuelos. Estas comunicaciones
involucran a uno o ms administraciones de servicios de trnsito areo.

Comunicaciones aeronuticas operacionales (AOC). Comunicaciones necesarias para el
ejercicio de la autoridad sobre la iniciacin, continuacin, desvo o terminacin de vuelos por
razones de seguridad, regularidad y eficiencia.

Comunicaciones aeronuticas administrativas (AAC). Comunicaciones utilizadas por las
compaas explotadoras de aeronaves en relacin con los aspectos comerciales de la operacin
de subvuelos y servicios de transporte. Estas comunicaciones se utilizan para varios fines, como
el vuelo y el transporte terrestre, reservas, distribucin de tripulaciones y aeronaves o cualquier
otro fin logstico que mantenga o mejore la eficiencia de la operacin general de los vuelos.
1.3.3 Para apoyar estos tipos de comunicaciones, en este manual se especifica un conjunto de requisitos
administrativos y tcnicos para las entidades que constituyen la interred ATN/PS. Vase la Figura -1-2.

1.3.4 Los requisitos tcnicos que figuran en este manual se imponen al encaminador PS, al anfitrin PS o
al nodo PS cuando el requisito se aplica a ambos. En este manual se adopta la definicin de RFC 2460 de nodo PS
como dispositivo que implanta Pv6 y se distingue entre un encaminador PS como nodo que reenva paquetes P a
otros y un anfitrin PS como nodo que no es un encaminador.

1.3.5 Los requisitos administrativos de este manual se imponen a los dominios administrativos. Un dominio
administrativo es una entidad de organizacin que puede ser un Estado individual, un grupo de Estados (p. ej., una
regin de la OAC o una organizacin regional), un proveedor de servicios de comunicaciones areas (ACSP), un
proveedor de servicios de navegacin area (ANSP), u otra entidad de organizacin que gestione recursos y servicios
de la red ATN/PS.
Parte III Texto de orientacin
Captulo 1 Introduccin III-1-3

Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Anfitrin
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Encaminador
PS
Interred
ATN/IPS
Interred
ATN/IPS
Interred
ATN/IPS
Interred
ATN/IPS
AD
AD
AD
AD
AD
AD
AD
AD
AD
AD
AD
AD

Figura III-1-2. Interred ATN/IPS

1.3.6 El requisito principal es que cada dominio administrativo que participe en la interred ATN/PS debe
operar uno o ms encaminadores PS que ejecutan un protocolo de encaminamiento interdominio denominado
protocolo de pasarela frontera (BGP). Se trata fundamentalmente de que la ATN/PS pueda formarse a travs de los
diversos dominios administrativos para que cualquier anfitrin PS pueda comunicarse con cualquier otro anfitrin PS
en la interred ATN/PS.

1.3.7 Se utiliza un protocolo de encaminamiento interdominio para intercambiar informacin de
encaminamiento entre sistemas autnomos. Un sistema autnomo (AS), segn se define en RFC 1930, es un grupo
conectado de uno o ms prefijos P dirigidos por uno o ms operadores de red que tiene una poltica de enrutamiento
nica y claramente definida. A partir de esta definicin, hay dos entidades distintas: una es el AS como grupo de prefijos
P y la otra es los operadores de red, es decir, los dominios administrativos. Esta distincin tiene sentido en la internet
dado que permite que mltiples organizaciones (es decir, dominios administrativos) ejecuten un BGP para un proveedor
de servicios nternet (SP) que a su vez conecta a cada una de estas organizaciones con la nternet. Este manual no
impide utilizar SP de esta forma; no obstante, segn se indic anteriormente, los requisitos se imponen directamente a
los dominios administrativos.


Coordinacin de polticas entre dominios administrativos

1.3.8 Los encaminadores PS se intercambiarn informacin sobre sus prefijos de red internos con sus
encaminadores inmediatamente vecinos, pero pueden tambin reenviar informacin de encaminamiento sobre otros
prefijos de red obtenidos de otros vecinos BGP. Como resultado, entre dos dominios administrativos puede
retransmitirse por varios dominios administrativos intermedios. Dicho trfico transmitido en nombre de otros dos se
denomina "trfico de trnsito.

1.3.9 En este manual no se especifican los encaminamientos que han de anunciarse entre encaminadores
PS ni tampoco las polticas bsicas de gestin del trfico para un entorno de encaminamientos dinmicos. No obstante,
se requiere que los dominios administrativos coordinen sus polticas para transportar trfico de trnsito con los dominios
administrativos pares. Los dominios administrativos que participan en la ATN/PS deberan asegurar el tratamiento
adecuado del trfico de trnsito sobre la base siguiente:

un dominio administrativo no debera anunciar un prefijo de red si no est dispuesto a aceptar
trfico entrante a dicho destino de prefijo de red;

al establecer las interconexiones entre dos dominios administrativos, puede convenirse un
mecanismo de imputacin para apoyar la poltica de trnsito correspondiente implcita; y

los dominios administrativos que retransmiten trfico de trnsito deberan garantizar que se
mantienen la seguridad y polticas QoS del trfico correspondientes.

Funcionamiento entre redes ATN/IPS con movilidad

1.3.10 La ATN/PS fija o tierra-tierra descrita en 1.3.2 a 1.3.7 puede ampliarse para apoyar la movilidad, es
decir, puede ampliarse para apoyar comunicaciones aire-tierra. Esto se logra mediante el uso de Pv6 mvil, la solucin
de movilidad general del ETF. El Pv6 mvil permite que los modos mviles (MN) (aeronaves en la ATN/PS) se
comuniquen en forma transparente con los nodos corresponsales (CN) (sistemas automticos terrestres en la ATN/PS)
al avanzar dentro o a travs de redes aire-tierra. Un dominio administrativo en la ATN/PS que ofrece servicio mvil
Pv6 se denomina proveedor de servicio de movilidad (MSP). Entonces, la ATN/PS se ampla para apoyar la movilidad
mediante la adicin de MSP que proporcionan servicios de movilidad a los nodos mviles. En la Figura -1-3 se
muestra la ATN/PS con un MSP. Segn se ve en la figura, a efectos de proporcionar servicios de movilidad, el MSP
debe operar uno o ms agentes domsticos. El agente domstico cumple una funcin principal en el sentido de que
proporciona gestin de emplazamiento (LM) para seguir el movimiento de un nodo mvil y localizar el nodo mvil para
entregar datos, mientras que tambin funciona como encaminador interdominio que proporciona conectividad con el
resto de la ATN/PS. (Ntese que esto es un concepto lgico. Diferentes configuraciones fsicas son posibles en las
implantaciones reales). Cabe sealar que el Pv6 mvil RFC 3775 est siendo actualizado por el ETF (RFC 3775 bis).
La implantacin de la RFC 3775 debera tener en cuenta estas actualizaciones.

1.3.11 En la Figura -1-3 se muestra la configuracin mnima, p. ej., para ATSC, donde el MSP podra ser
un ACSP. No obstante, esta no es la nica configuracin posible. Un ANSP puede optar por ser su propio MSP y
obtener servicio de acceso de un ACSP. Para apoyar AOC y AAC una lnea area puede pasar a ser un MSP.
Anlogamente, una autoridad aeroportuaria puede decidir transformarse en MSP y ofrecer servicios a la ATN/PS. En
este caso, el servicio de movilidad de capa P puede ofrecerse junto con o adems de la movilidad de capa de enlace.
Como se observ en 1.3.2 a 1.3.7, la ATN/PS est dirigida a apoyar ATSC, AAC y AOC, no obstante lo cual otras
organizaciones aeronuticas pueden utilizar el enfoque de movilidad. Estas organizaciones pueden transformarse en
MSP y apoyar otros tipos de comunicaciones como las comunicaciones de pasajeros de lnea area (APC). En este
caso, puede ofrecerse una forma mejorada de servicio P mvil denominada movilidad de red (NEMO).


Figura III-1-3. La ATN/IPS con un MSP

Mecanismos de transicin en Ia red

1.3.12 El ETF y las autoridades de nternet han adoptado Pv6 para enfrentar el crecimiento cada vez mayor
de la nternet mundial. Pv6 resuelve muchos de los problemas tcnicos relacionados con Pv4, en particular el limitado
espacio de direcciones Pv4.

1.3.13 La implantacin mundial de Pv6 ya se ha iniciado dentro de las regiones de la OAC para apoyar
aplicaciones de gestin del trnsito areo. Es la piedra fundamental de la nternet de prxima generacin que permitir
contar con un medio flexible de aplicar nuevas tecnologas y servicios. Por esta razn, la ATN/PS se basa en Pv6 para
aprovechar inmediatamente los nuevos productos y tecnologas disponibles comercialmente.

1.3.14 La implantacin de la ATN/PS ser gradual. Muchas organizaciones debern transitar etapas
mltiples para asegurar que los sistemas finales y encaminadores ATN/PS se integran en su entorno existente, en
particular, para aquellas que cuentan con sistemas heredados implantados como AFTN, AFTN/CDN, X.25, ATN/OS
CLNP (CLNP primario sobre Ethernet o "X.25) e Pv4.

AD
AD
Nodo mvil
Nodo
corresponsal
Nodo
corresponsal
Nodo
corresponsal
Nodo
corresponsal
Encaminador
de acceso
Encaminador
de acceso
Proveedor
de servicio
de moviIidad
(MSP)
Agente
domstico
Nodo
corresponsal
Nodo
corresponsal
Interred
ATN/IPS
MPv6


1.3.15 Tres mecanismos de transicin pueden ayudar a las organizaciones que estn introduciendo la
ATN/PS en un entorno heterogneo:

tunelado: un protocolo encapsulado en otro;

doble pila: un entorno en el cual varios protocolos funcionan simultneamente; y

traduccin: la conversin de un protocolo a otro.

1.3.16 En RFC 4213 (Mecanismos de transicin bsicos para anfitriones y encaminadores Pv6) figura una
descripcin profunda de los dos primeros mecanismos. La aplicacin de los tres mecanismos mencionados a la
ATN/PS se describe a continuacin.

Tunelado

1.3.17 El Pv6 se ha especificado para funcionar sobre varias interfaces de capas inferiores como las
tecnologas de retransmisin de tramas, ATM, HDLC, PPP y LAN. El tunelado significa que un protocolo determinado
est encapsulado en otro, lo que significa que Pv6 sera encapsulado en otro protocolo de red equivalente desde el
punto de vista funcional. Con respecto a la ATN/PS, la ventaja principal de este mecanismo sera para las
organizaciones aeronuticas que ya operan redes Pv4 para permitir que los anfitriones encaminadores ATN/PS se
comuniquen entre s sobre una red Pv4 subyacente. Adems, si la infraestructura de interconexin entre los dos
dominios administrativos ATN/PS se limita a Pv4, este mecanismo puede aplicarse.

1.3.18 Se recuerda que Pv6 no puede operar sobre X.25; en cambio puede tunelarse sobre una red X.25 un
tnel Pv6 sobre Pv4. Un mecanismo de tunelado especfico denominado P SNDCF se define para aplicaciones
ATN/OS, y cabe sealar que esto permite el interfuncionamiento entre aplicaciones ATN/OS sobre una red P pero no
permite el interfuncionamiento con otras aplicaciones ATN/PS.

1.3.19 Los mecanismos de tunelado llevan a un aumento de la sobrecarga del protocolo y la segregacin de
los dos dominios encaminados obliga a una gestin de red adicional, p. ej., un dominio encaminado Pv6 sobre un
dominio encaminado Pv4 subyacente deber gestionarse en trminos de QoS, seguridad y optimizacin de
encaminamiento. Adems, este mecanismo slo prev el interfuncionamiento entre sistemas ATN/PS y no permite el
interfuncionamiento entre sistemas ATN/OS u otros sistemas Pv4 dentro de la organizacin. No obstante, puede
proporcionar una forma eficaz de introducir la ATN/PS dentro y entre dos dominios administrativos.

1.3.20 El mecanismo de tunelado se adeca mejor a resolver problemas de comunicacin de capas bajas
entre anfitriones y encaminadores Pv6 ATN/PS; pero no proporciona interfuncionamiento con sistemas que no
cumplen con ATN/PS.

Doble pila

1.3.21 El mecanismo de doble pila implica que una implantacin tramita ms de un protocolo de
comunicaciones para una determinada aplicacin o funcin. Dentro del dominio nternet un nmero considerable de
aplicaciones de comunicacin se han apilado en forma doble, p. ej., HTTP, FTP, SSH, DNS, SMTP, apoyando ambos
protocolos Pv4 e Pv6. No obstante, en el contexto de la ATN/PS, la finalidad de la doble pila es resolver problemas
similares aunque diferentes.

1.3.22 El concepto de doble pila se adeca idealmente para los sistemas que necesitan apoyar aplicaciones
ATN tanto para OS como para PS. En tales entornos, las aplicaciones se disean en forma abstracta para ser
independientes de las capas inferiores, p. ej., no saben qu protocolo de comunicaciones de capa inferior (OS o P) se
est utilizando para comunicar con sus pares. Los vendedores de X.400 han adoptado este enfoque para apoyar
entornos tanto OS como P y evitar la necesidad de desarrollar pasarelas de comunicacin de capa inferior complejas y

ad hoc. Normalmente, tales implantaciones se basan en alguna forma de directorio o "tabla que relaciona una direccin
de alto nivel con una direccin especfica de protocolo de comunicaciones.

1.3.23 El concepto de doble pila puede ampliarse a pila mltiple, p. ej., los fabricantes de AMHS ATN Pv4,
Pv6 y X.25 apoyan normalmente el funcionamiento sobre protocolos mltiples como OS, TCP/P y X.25.

1.3.24 El mecanismo de doble pila proporciona el nivel mximo de interfuncionamiento con los pares
reduciendo al mismo tiempo la complejidad de las pasarelas de protocolo de comunicaciones de capa inferior y puntos
nicos de falla adicionales. Se adecua idealmente a aplicaciones como el sistema de tratamiento de mensajes ATS
(AMHS), por el cual algunos sistemas ya se han implantado sobre la base de TCP/P. Un enfoque de pila doble puede
ser vlido para que los sistemas terrestres de enlace de datos aire-tierra apoyen CPDLC sobre mltiples servicios de
enlace de datos, tales como ATN/OS y ATN/PS.

Traduccin

1.3.25 Los mecanismos de traduccin implican la conversin de un protocolo a otro. Este mecanismo puede
interpretarse como una pasarela de comunicaciones de capa inferior entre dos protocolos que tienen mucho en comn.
Varios traductores, como el RFC 2766 - Traduccin de direcciones de red Traduccin de protocolos (NAT-PT), se
han elaborado en el contexto de la transicin de Pv4 a Pv6 dado que ambas versiones tienen muchas caractersticas
en comn.

1.3.26 Dentro de la transicin general de Pv4 a Pv6, se previ que algunos sistemas pueden ser slo
capaces de comunicarse con Pv4 mientras que otros pueden hacerlo slo con Pv6. Considerando los problemas de
escalabilidad de la nternet mundial y el hecho de que la mayora de las aplicaciones y sistemas de nternet han pasado
a ser de doble pila, la necesidad de contar con traductores ha disminuido.

1.3.27 No obstante, los traductores pueden desempear una importante funcin a corto plazo en el caso de
la ATN/PS. Por ejemplo, aunque los sistemas AMHS existentes funcionan sobre sistemas operativos en doble pila,
ninguno de ellos ha mejorado su cdigo de aplicacin para utilizar Pv6. En otras palabras, se apoya RFC 1006 pero no
RFC 2126. En tales casos particulares y teniendo en cuenta el nmero limitado de sistemas, la implantacin de
traductores proporciona una medida a corto plazo para que dichos sistemas puedan ajustarse a la ATN/PS y
interfuncionar con sistemas habilitados por RFC 2126.

1.3.28 Los traductores Pv4/Pv6 aumentan la complejidad de la infraestructura P y de su gestin. Debe
preferirse un enfoque de doble pila pero, en casos especficos, los traductores pueden ser la nica medida a corto plazo
para poder cumplir con la ATN/PS.

Combinacin de los mecanismos

1.3.29 Dado que la implantacin de ATN/PS ser gradual, es comprensible que se aplique una combinacin
de los tres mecanismos mencionados.

1.3.30 Pueden introducirse combinaciones especficas de los mecanismos mencionados para ajustarse
mejor al entorno del dominio administrativo.

1.4 PILAS DE PROTOCOLOS

Orientacin sobre capa fsica y de enIace

1.4.1 Los aspectos de la capa fsica y de enlace estarn determinados por el servicio requerido y las
conexiones del Estado contratante. Los aspectos de la capa fsica y el enlace se basarn en la necesidad del servicio y
deberan estar contenidos en un Memorando de acuerdo (MoA).


Capa de red

1.4.2 La ATN/PS utiliza Pv6, que a su vez emplea direcciones de 128 bits frente a 32 en Pv4. Los prefijos
Pv6 se intercambian entre dominios administrativos que utilizan rutas estticas o BGP para asegurar un
encaminamiento ATN/PS mundial.

Plan de direcciones

1.4.3 A diferencia del Pv4, dentro del Pv6 no existe la nocin de direcciones privadas. Al igual que en las
prcticas existentes para X.25, cada dominio administrativo deber elaborar un plan de direccionamiento Pv6 (vase la
Parte , 2.3.8 a 2.3.13, Direccionamiento en la red). Esto entraar la recepcin de un prefijo Pv6 nico y
procedimientos de asignacin para redes y anfitriones.

Interfaz de aplicaciones con la capa de red

1.4.4 Aunque las aplicaciones generalmente tienen interfaces con el servicio de comunicacin en la capa
de transporte, a veces es necesario transmitir y recibir datagramas a nivel de red. Esto se logra mediante algunas
extensiones de zcalo AP especificadas en RFC 3542 - nterfaz del programa de aplicaciones (AP) de zcalos
avanzados para Pv6.

Encaminamiento interdominio

1.4.5 El encaminamiento interdominio permite el intercambio de prefijos Pv6 entre dominios
administrativos. Estos intercambios son apoyados por la configuracin del encaminamiento esttico o del protocolo de
pasarelas frontera (BGP) entre encaminadores ATN/PS para asegurar un encaminamiento ATN/PS mundial.

1.4.6 Dependiendo de la escala del dominio administrativo, pueden existir otros niveles internos de
encaminamiento inter e intradominio o confederaciones de BGP.

Plan de numeracin de sistemas autnomos (AS)

1.4.7 Deben asignarse y configurarse nmeros AS en los encaminadores ATN/PS para anunciar
sus sistemas autnomos dentro del dominio encaminado. En el Apndice de la Parte se presenta el plan de
numeracin AS.

Identificadores de encaminador ATN/IPS

1.4.8 Para establecer BGP entre dos vecinos, cada entidad par BGP debe definir un identificador de
encaminador. Si dos encaminadores utilizan el mismo valor de identificador de encaminador, no pueden establecerse
las sesiones BGP. Dado que el identificador de encaminador es un campo de 32 bits, se encuentra normalmente en la
direccin Pv4 del encaminador.

1.4.9 Dado que los encaminadores ATN/PS pueden no tener interfaces Pv4 o direcciones Pv4 nicas,
debe recomendarse un plan. Aunque la unicidad mundial de estos valores no es requisito previo, para facilitar
la implantacin de la ATN/PS se recomienda el plan siguiente (basado en draft-dupont-durand-idr-ipv6-bgp-routerid-
01.txt):

4 bits puestos a uno, 16 bits puestos al nmero AS (el plan mundial de nmeros AS figura en el
Apndice de la Parte );

12 bits atribuidos manualmente dentro del dominio (permiten contar con 4 096 diferentes
identificadores de encaminador en cada dominio de encaminamiento).

Anuncio de encaminamiento

1.4.10 Los encaminadores ATN/PS deberan anunciar los prefijos de red basados en longitudes de prefijo
coherentes o en prefijos de rutas agregados.

Segregacin de tipos de trfico

1.4.11 El BGP-4 no permite originalmente establecer conjuntos diferentes de rutas para diferentes tipos de
trfico al mismo destino. Los requisitos ATN/PS sobre segregacin de tipos de trfico pueden cumplirse mediante
disposiciones apropiadas en el plan de direccionamiento ATN; si la direccin ATN incorpora una indicacin del tipo de
trfico, el BGP-4 transmitir en forma transparente informacin de rutas segregadas para los diversos tipos de trfico.

Prioridad de trfico y servicios diferenciados

1.4.12 Histricamente, las prioridades en la capa de red se seleccionaban explcitamente enviando una
aplicacin a travs del campo tipo de servicio (TOS) en la cabecera P. Aunque los servicios diferenciados (RFC 2474)
conservan la semntica de precedencia P del campo TOS, este enfoque no se recomienda actualmente. Esto se debe
en parte a que la precedencia P ha sido sustituida por una estrategia de comportamiento por salto (PHB) de los
servicios diferenciados y tambin en parte porque los administradores de las redes normalmente no confan en los
reglajes de aplicacin. Los servicios diferenciados (RFC 2474) proporcionan un medio de especificar e implantar el
tratamiento de QoS en forma coherente en toda la red ATN/PS. Esta especificacin se establece nodo por nodo,
especificando el comportamiento de cada nodo que afecte la QoS (PHB). En RFC 2475 Arquitectura de los servicios
diferenciados se presentan el marco general y prcticas actuales correspondientes.

Nota. Vase el prrafo 4 Calidad de servicio (QoS).

Multidifusin

1.4.13 La necesidad de enviar la misma informacin a varios receptores es uno de los requisitos principales
de la distribucin de datos de vigilancia. Este requisito puede apoyarse mediante los servicios de multidifusin de Pv4 e
Pv6. Otras tcnicas de funcionamiento en red que logran el mismo objetivo de multidifusin no se consideran dentro
del mbito de este documento.

1.4.14 Un nmero limitado de Estados contratantes de la OAC han introducido servicios nacionales de
multidifusin Pv4 para distribucin de datos de vigilancia. No obstante, el alcance limitado del espacio de direcciones
de multidifusin Pv4 y la ausencia de pasarelas entre Pv4 e Pv6 inhibe una introduccin escalable para la ATN/PS.

1.4.15 En los ltimos aos, se han logrado considerables progresos tcnicos en el campo de la multidifusin
P, concretamente la multidifusin de fuentes especficas (SSM). Contrariamente a las implantaciones existentes sobre
la base de PM-SM (Multidifusin independiente del protocolo Modo disperso), la SSM proporciona sencillez y
resistencia adicionales al encaminamiento del trfico de multidifusin P y tambin se adecua idealmente a las
necesidades de vigilancia. Su uso sobre Pv6 se recomienda en una directiva de EUROCONTROL titulada "Directrices
de EUROCONTROL para el apoyo a la implantacin (EGS) Parte 5: Especificaciones de comunicacin y navegacin,
Captulo 12, Distribucin de la vigilancia sobre la lista de requisitos de perfil de multidifusin P (PRL) disponible en:
http://www.eurocontrol.int/communications/public/standard_page/com_network.html.

1.4.16 Un canal de datos de multidifusin de fuentes especficas (SSM) se define mediante la combinacin
de una direccin de multidifusin de destino y una direccin de unidifusin de fuente. Esto corresponde a un flujo nico
de datos de vigilancia disponibles de una fuente especfica en la ATN/PS (vase la Figura -1-4).


| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+-----------+
|11111111|0011|1110|00000000|00000000| 000........000 |ID de grupo|
+--------+----+----+--------+--------+----------------+-----------+

Figura III-1-4. Direccin de muItidifusin SSM en IPv6 con aIcance mundiaI IPv6

El identificador de grupo de multidifusin Pv6 estar en la gama de 0x8000000 a 0xFFFFFFFF
permitida para la asignacin dinmica por un anfitrin, segn se especifica en RFC 3307,
seccin 4.3 y RFC 4607, seccin 1.

La gama de direccin SSM Pv6 disponibles resultante es FF3E::8000:0/97
(FF3E:0:0:0:0:0:8000:0 / 97).

Suponiendo el acceso apropiado al servicio, para recibir trfico SSM se requieren los siguientes
tres parmetros:

1. Direccin de la fuente (direccin unidifusin)
2. Direccin multidifusin (indicada por la aplicacin fuente)
3. Puerto (valor por defecto es 8600 para datos de vigilancia ASTERX en Europa)

Capa de transporte

1.4.17 Los protocolos de capa de transporte se utilizan para proporcionar servicios de comunicacin fiables
o de "mejor esfuerzo sobre la ATN/PS. Existen dos protocolos de transporte obligatorio, TCP y UDP. TCP se utiliza
para proporcionar servicios de transporte fiables y UDP se utiliza para proporcionar los servicios de mejor esfuerzo.
Pueden utilizarse otros protocolos de transporte pero no pueden afectar la comunicacin en otros servicios ATN/PS.

Protocolo de control de transmisin (TCP)

1.4.18 El protocolo de nternet (P) funciona intercambiando grupos de informacin denominados paquetes.
Los paquetes son breves secuencias de bytes integradas por una cabecera y un cuerpo de datos. La cabecera describe
la informacin de encaminamiento del paquete que utilizan los encaminadores de nternet para transmitir el paquete en
la direccin correcta hasta que llega a su destino final. El cuerpo contiene la informacin sobre la aplicacin. El TCP se
optimiza para entrega precisa ms que entrega oportuna y a veces incurre en las largas demoras mientras espera por
mensajes fuera de orden o retransmisiones de mensajes perdidos. No es particularmente adecuado para aplicaciones
en tiempo real como las de "voz sobre P (VoP), tambin denominada telefona por nternet. Las aplicaciones en
tiempo real requieren protocolos como el protocolo de transporte en tiempo real (RTP) que funcionen sobre el protocolo
de datagramas de usuario (UDP).

1.4.19 El TCP es un servicio fiable de transmisin de trfico que garantiza la entrega de una corriente de
datos enviada desde un anfitrin a otro sin duplicacin o prdida de datos. Dado que la transferencia de paquetes no es
fiable, se utiliza una tcnica conocida como acuse de recibo positivo con retransmisin para garantizar la fiabilidad de
las transferencias de paquete. Esta tcnica fundamental requiere que el receptor responda con un mensaje de acuse de
recibo cuando recibe los datos. El emisor mantiene un registro de cada paquete que enva, y espera el acuse de recibo
antes de enviar el paquete siguiente. El emisor tambin mantiene un temporizador desde cuando se envi el paquete, y
retransmite un paquete si el temporizador expira. El temporizador se necesita en caso de que el paquete se pierda o se
corrompa.

1.4.20 En caso de congestin, el P puede descartar paquetes. Por razones de eficiencia, dos paquetes
consecutivos en la nternet pueden tomar rutas diferentes hacia su destino. Los paquetes pueden llegar al destino en el
orden errneo.

1.4.21 La biblioteca de soporte lgico TCP utiliza el P y proporciona una interfaz ms sencilla ocultando la
mayora de las estructuras de paquete subyacentes, reorganizando los paquetes fuera de orden, minimizando la
congestin en la red y retransmitiendo los paquetes descartados. Con ello, el TCP simplifica considerablemente la tarea
de redactar aplicaciones de red.

1.4.22 El TCP proporciona un servicio orientado a la conexin con una semntica fiable. Funciona sobre la
capa de red que no necesariamente detecta y comunica todos los errores (p. ej., corrupcin, encaminamiento errneo).
Para este fin, proporciona:

deteccin de errores basada en una suma de control que cubre la cabecera de transporte y la
carga til as como alguna informacin vital de la capa de red; y

recuperacin respecto de los errores basada en la retransmisin de paquetes errneos o
perdidos.

1.4.23 El TCP tambin est diseado para detectar y gestionar la congestin de red de extremo a extremo y
los tamaos mximos de segmentos de datos de usuario. Esto resulta fundamental para el funcionamiento sobre
subredes heterogneas con circuitos troncales de poca anchura de banda y alta latencia, tales como las subredes
actuales ATN/PS areas o terrestres.

Protocolo de datagramas de usuario (UDP)

1.4.24 El UDP proporciona un servicio sin conexiones con deteccin de errores limitada y mecanismos de
gestin sin recuperacin y sin congestin. Est especializado para intercambios de datos ligeros, donde es aceptable la
prdida o corrupcin de paquetes ocasional y no detectada, y cuando la sencillez de uso es el objetivo.

Direccionamiento en la capa de transporte

1.4.25 El direccionamiento en la capa de transporte se basa en nmeros de puerto (valores enteros de
16 bits) relacionados con los puntos de extremo de fuente y destino para identificar corrientes de datos separadas. Los
puertos se clasifican en tres categoras con una correspondiente gama de valores:

Los puertos bien conocidos van de 0 a 1 023 y son asignados por ANA. La mayora de los
sistemas, estos puertos slo pueden ser utilizados por procesos del sistema (o de raz) o por
programas ejecutados por usuarios privilegiados. Estos nmeros de puerto bien conocidos
predefinidos relacionados con aplicaciones especficas TCP o UDP les hace visible ("bien
conocido) para las aplicaciones clientes sin conocimiento o configuracin especfica.

Los puertos registrados van de 1 024 a 49 151 y estn registrados por ANA a peticin de los
usuarios. Dichos puertos tienen la misma funcin que los puertos bien conocidos pero para
aplicaciones ms extendidas o menos crtica. El uso de estos puertos no exige privilegios
especficos.

Los puertos dinmicos o privados van de 49 152 a 65 535. Las aplicaciones pueden usarlos
libremente.

1.4.26 La asignacin de puerto se obtiene solicitndola a ANA. Una imagen actualizada del registro de
puertos figura en: http://www.iana.org/assignments/port-numbers.

1.4.27 Este plan de asignacin es obligatorio sobre la nternet pblica. Debera poder aplicarse a la
ATN/PS (por lo menos respecto a los puertos bien conocidos) a efectos de evitar cualquier conflicto.


1.4.28 Adems, se requiere que los anfitriones ATN/PS apoyen los siguientes nmeros de puertos
registrados:

tcp 102 para ATSMHS
tcp 8500 para FMTP
tcp/udp 5910 para CM
tcp/udp 5911 para CPDLC
tcp/udp 5912 para FS
tcp/udp 5913 para ADS

Interfaz de aplicacin con la capa de transporte

1.4.29 La interfaz de aplicacin con las capas de transporte TCP y UDP se proporciona en una amplia gama
de plataformas/sistemas operativos segn se especifica en RFC 3493 Extensiones bsicas de interfaces de zcalo
para Pv6. Esta RFC extiende la interfaz de zcalo (desarrollada originalmente por la Universidad Berkeley en apoyo de
Pv4 en su distribucin Unix BSD) a Pv6.

Evitacin de la congestin

1.4.30 A fin de adaptarse a las variantes condiciones para drenar trfico en las subredes, el TCP implanta
bsicamente cuatro mecanismos: arranque lento, evitacin de la congestin, retransmisin acelerada y recuperacin
acelerada. Esto se especifica en RFC 2581 Control de la congestin en TCP. Los dos primeros mecanismos tienen
por objeto prevenir prdidas importantes de paquetes cuando ocurre congestin, mientras que los otros dos intentan
acortar el retardo para la retransmisin de los paquetes perdidos. Estos mecanismos se implantan independientemente
en todos los sistemas de extremo y no evitan completamente la prdida de paquetes.

1.4.31 En el caso de las subredes de poca anchura de banda (p. ej., subredes ATN areas o terrestres), las
aplicaciones TCP pueden utilizar el mecanismo de notificacin explcita de congestin que es ms probable que
proporcione una ventaja significativa. Este est especificado en RFC 3168 Adicin de notificacin especfica de
congestin (ECN) al P. Esta caracterstica prev la congestin, reduciendo considerablemente la prdida de paquetes.
No obstante, tiene consecuencias en las capas de transporte y de red y exige la participacin de un considerable
nmero de encaminadores en las redes (de preferencia, encaminadores en el borde de las subredes de baja velocidad
y alta latencia).

Deteccin y recuperacin de errores

1.4.32 La deteccin de errores en TCP se basa en la ausencia de acuses de recibo oportuno. La
recuperacin se realiza mediante retransmisin de (los supuestos) paquetes perdidos. La prdida de un gran nmero
de paquetes en un breve perodo de tiempo puede obstruir el caudal de la conexin TCP, afectando la performance.
Esto puede resultar crtico para subredes de alta latencia (p. ej., subredes ATN areas o terrestres). El apoyo de las
opciones de acuse de recibo selectivo de TCP puede mitigar este problema permitiendo la retransmisin selectiva de
los paquetes perdidos solamente (en vez de la secuencia completa desde el primero al ltimo paquete perdido). Esta
opcin se especifica en RFC 2018 Opciones de acuse de recibo selectivo en TCP.

Intermediarios (proxies) de mejora del rendimiento (PEP)

1.4.33 A menudo se emplean "proxies de mejora del rendimiento (PEP) para mejorar el rendimiento TCP
muy degradado provocado por diferentes caractersticas de enlace en entornos heterogneos, p. ej., en entornos
inalmbricos o satelitales que son comunes en las comunicaciones aeronuticas. Los PEP de capa de transporte o de
capa de aplicacin se aplican para adaptar los parmetros TCP a las diferentes caractersticas de los enlaces.
RFC 3135 Proxies de mejora del rendimiento para mitigar degradaciones relacionadas con los enlaces es un
relevamiento de tcnicas de mejora del rendimiento por PEP y en ellas se describen algunas de las consecuencias de

utilizar PEP. La mayora de estas consecuencias se deben al hecho de que normalmente la semntica de extremo a
extremo de las conexiones se interrumpe. En particular, los PEP inhiben el uso del cifrado Psec de extremo a extremo
lo que tiene consecuencias sobre los procedimientos de movilidad y entrega.

Uso de la capa de transporte

1.4.34 La forma en que se usan las conexiones de la capa de transporte tiene grandes consecuencias sobre
la calidad de servicio (QoS) experimentada por la aplicacin. Los mensajes de aplicacin pueden tener diferentes
clases de servicio (CoS); algunos pueden exigir una entrega fiable en el orden correcto. Existen cuatro opciones para
utilizar el servicio de capa de transporte TCP:

I. Reestablecimiento de una conexin TCP para cada transmisin y para cada servicio

Cada servicio utiliza una conexin TCP especializada. Cuando se generan los datos de
servicio de la aplicacin, la conexin de la capa de transporte se abre y los datos se
transmiten. Una vez terminada con xito la transmisin, se cierra la conexin.

II. Establecimiento de una conexin TCP una vez para cada servicio mantenindola abierta

Cada servicio utiliza una conexin TCP especializada. La conexin se abre en el momento
de abrir la seccin o del primer uso y se cierra en el momento de salir del sistema o de
entrega.

III. Reestablecimiento de una conexin TCP para cada transmisin en un conjunto de servicios
multiplexados

Se establece una conexin TCP compartida para todos los servicios del conjunto (una
aplicacin puede ser anfitriona de varios servicios). Los datagramas producidos por estas
aplicaciones se transmiten por esta conexin compartida. La conexin se abre en el
momento en que se genera el datagrama del servicio y se cierra despus de una transmisin
exitosa.

Nota. Todos los servicios del conjunto multiplexado deberan requerir la misma CoS y
producirse por la misma aplicacin.

IV. Establecimiento de una conexin TCP una vez para un conjunto de servicios multiplexados
mantenindola abierta

Se abre una conexin TCP compartida para todos los servicios del conjunto (una aplicacin
puede ser anfitriona de varios servicios). Los datagramas producidos por estas aplicaciones
se transmiten por esta conexin compartida. La conexin se abre en el momento de entrar
en el sistema o de primer uso y se cierra en el momento de salir del sistema o de entrega.

Nota. Todas las aplicaciones del conjunto multiplexado deberan exigir la misma CoS y
generarse por la misma aplicacin.

1.4.35 No se aconsejan los servicios multiplexados generados por la misma aplicacin pero con diferentes
requisitos de CoS, como en las opciones y V, dado que la QoS de la capa de red se ejecuta por conexin TCP. El
TCP no tiene medios para proporcionar QoS diferenciada dentro de una conexin, de modo que cualquier informacin
CoS se perdera por lo menos parcialmente. Los servicios de multiplexado generados por la misma aplicacin y con los
mismos requisitos CoS no crean este problema.

1.4.36 Se recomienda utilizar por lo menos una conexin del transporte especializada para cada servicio
(opciones y ). La conexin puede establecerse ya sea por servicio o por aplicacin.


1.4.37 Si diferentes servicios de una aplicacin se multiplexan a una conexin TCP compartida, todos los
servicios deben exigir la misma CoS (opciones y V).

1.4.38 Para todas las aplicaciones aire-tierra, se recomienda abrir la conexin en el momento de entrar en el
sistema o primer uso y mantenerla abierta hasta la salida del sistema o la entrega (opciones y V).

Capa de apIicacin

Extensiones ASN.1 a gestin del contexto (CM)

1.4.39 La aplicacin CM de ATN requiere adaptaciones ASN.1 para funcionar sobre el ATN/PS.

Nota. Se prev que en una futura edicin del Doc 9880 figurarn estas extensiones.

Definicin de CM ASN.1

1.4.40 Para apoyar la transmisin de informacin de direcciones especfica del PS, la aplicacin CM de
ASN.1 debe actualizarse. Si bien existen otros mtodos posibles para obtener aplicaciones de informacin de
direccionamiento, la CM tambin proporciona informacin adicional dirigida a facilitar la correlacin de la informacin de
la aeronave con la informacin de plan de vuelo.

1.4.41 Se aadieron nuevas definiciones de ASN.1 con miras a mantener la retrocompatibilidad con
implantaciones CM anteriores. Al intercambiar informacin sobre aplicaciones, la CM ATN OS utilizaba un elemento
AEQuaIifierVersionAddress. Este se complementara con un elemento AEEnhancedQuaIifierVersionAddress, con
un nuevo elemento especfico de APEnhancedAddress como se muestra a continuacin:

AEEnhancedQuaIifierVersionAddress ::= SECUENCA
{
aeQualifier AEQualifier,
apVersion VersionNumber,
apAddress APEnhancedAddress
}

El elemento APEnhancedAddress permitira transportar un TSAP para uso en la red OS o una
direccin P para uso en PS. A continuacin se muestra el APEnhancedAddress:

APEnhancedAddress ::= ELECCN
{
longTsap [0] LongTsap,
shortTsap [1] ShortTsap,
ipAddress [2] PAddress,
...
}

1.4.42 El elemento IPAddress es nuevo y se utiliza para transmitir la direccin Pv6 real. En esta definicin
no se incluy una definicin especfica de Pv4. Esto se hizo para simplificar las definiciones y fomentar la migracin
Pv6. Si se requieren direcciones Pv4 para algunas implantaciones, pueden representarse en formato Pv6 utilizando el
procedimiento de correspondencia con Pv4 comn, es decir, los primeros 80 bits puestos a cero, los siguientes 16
puestos a 1, y los ltimos 32 como representacin de la direccin Pv4.

1.4.43 Adems, se incluye un elemento port (puerto) opcional. La intencin fue permitir la especificacin de
un puerto para la direccin P que pertenezca a una aplicacin particular. El puerto no es necesario si la implantacin
utiliza los nmeros de puerto ANA normalizados asignados a las aplicaciones PS. A continuacin se muestra el
elemento IPAddress:

IPAddress ::= SECUENCA
{
ipHostOrAddr PHostOrAddress,
port Port OPCONAL
...
}

1.4.44 El elemento PHostOrAddress proporciona mayor flexibilidad en el sentido de que pueden utilizarse
un nombre de anfitrin o una direccin Pv6. El nombre del anfitrin se define como una cadena A5 de entre 2 y
255 caracteres de tamao, el puerto como un entero de 0 a 65 536, y la direccin Pv6 como una cadena de octetos de
tamao 16, segn se muestra a continuacin:

IPHostOrAddress ::= ELECCN
{
hostname [0] Hostname,
ipv6Address [1] Pv6Address,
.
}

IPv6Address ::= CADENA DE OCTETOS (16)
Port ::= ENTERO (0..65536)
Hostname ::= Cadena A5 (TAMAO (2..255))

Uso de ASN.1 en CM

1.4.45 El uso del ASN.1 Pv6 ser asimilar al uso de la versin OS. Esto significa que cuando CM quiere
proporcionar informacin de direccin para aplicaciones apoyadas, debe identificar la aplicacin, el nmero de versin
de la aplicacin, y la direccin de la aplicacin para cada una de las aplicaciones que pueden apoyarse. Este debe
hacerse independientemente de la tecnologa de red que se emplee.

1.4.46 Para una aplicacin ATN ejecutada sobre la PS, la direccin Pv6 se utilizar para el
direccionamiento de cada aplicacin apoyada. Actualmente, no se define el uso del nombre de anfitrin, de modo que
solamente se utilizar IPv6Address en IPHostOrAddress. El elemento IPv6Address tomar el valor de la direccin
Pv6 de la aplicacin.

1.4.47 No se necesita proporcionar el nmero de puerto, dado que los nmeros de puerto ya estn definidos
para las aplicaciones y, por consiguiente, no necesitan transmitirse de extremo a extremo. Por consiguiente, el
elemento IPAddress contendr solamente la IPHostOrAddress.

1.4.48 El elemento APEnhancedAddress utilizar la opcin IPAddress, dado que las definiciones de TSAP
no tienen pertinencia para la PS. Y finalmente, los elementos AEQuaIifier y VersionNumber deberan proporcionarse
como parte del AEEnhancedQuaIifierVersionAddress. Los elementos AEQuaIifier y VersionNumber se rellenarn
de la misma forma que para las aplicaciones OS, es decir, el AEQuaIifier tendr un nmero entero, definido en el
Doc 9880, Parte , de 0 a 255 que identifica la aplicacin (p. ej., ADS tiene valor "0) y el VersionNumber ser un
entero de 0 a 255 que identifica la versin de la aplicacin.

1.4.49 Una vez intercambiada, la informacin de la aplicacin estara disponible a otros sistemas o procesos
en los sistemas areos y terrestres, segn sea necesario, para permitir la operacin de las aplicaciones. Esto no
cambia con respecto a CM OS.


1.5 CALIDAD DE SERVICIO (QoS)

Introduccin

1.5.1 El ETF defini el comportamiento por salto (PHB) DiffServ como medio para describir, clasificar y
gestionar el trfico de red para apoyar el suministro de QoS en las redes P. Las RFC no dictan la forma en que se
implantan los PHB dentro de una red, lo que depende normalmente del vendedor de que se trate.

1.5.2 En la prctica, los explotadores pblicos y privados de redes P proporcionan servicios basados en un
nmero limitado de PHB:

EF (reenvo acelerado) definido en RFC 3246, previsto como un servicio de pocas prdidas,
pocos retardos y poca fluctuacin de fase. Normalmente se utilizara para aplicaciones vocales.

AF (reenvo asegurado) definido en RFC 2597 y actualizado en RFC 3260. El reenvo
asegurado permite al operador proporcionar garanta de entrega en la medida en que el trfico
no exceda de la tasa de transmisin suscrita. Estas clases se utilizaran para aplicaciones de
datos sensibles a las demoras generalmente denominados AFx con precedencia de cada.
Normalmente, cada aplicacin de cliente especfica se hara corresponden con una clase AF
especfica y normalmente una clase AF se relaciona con aplicaciones multimedia, p. ej., vdeo.
Las clases AF son independientes entre s y tienen la ventaja de contar con una anchura de
banda garantizada individual. Esto impide que una aplicacin crtica se apodere de toda la
anchura de banda disponible y bloquee otras aplicaciones crticas.

Por defecto una clase de "mejor esfuerzo que se utilizara para aplicaciones no crticas
respecto de misiones y no sensibles a los retardos.

Definiciones de cIases

Contexto

1.5.3 Es probable que los proveedores de servicio de comunicaciones ATN/PS utilicen la misma
infraestructura PS para ATN y otras aplicaciones no definidas para ATN, p. ej., ATSMHS y datos de vigilancia. Los
recursos pueden compartirse a diferentes niveles, es decir las aplicaciones ATN/PS pueden utilizar el mismo tipo de
clase de servicio que otras aplicaciones que no son ATN sobre la misma infraestructura de rutas P. Alternativamente,
los proveedores de servicio de comunicaciones ATN/PS pueden solo querer compartir la misma infraestructura fsica y
explotar una red privada virtual (VPN) por servicio; en este caso, puede aplicarse un modelo CoS separado a cada
servicio VPN, siendo uno de ellos el ATN/PS. Fundamentalmente, los proveedores del servicio de comunicacin
ATN/PS tienen flexibilidad en la forma en que habilitan el CoS para la ATN/PS sobre su infraestructura.

1.5.4 Para las definiciones de CoS, es fundamental que el trfico ATN/PS est suficientemente calificado,
es decir mediante el uso de nmeros de puerto apropiados u otros medios, a efectos de marcar adecuadamente el
trfico que ingresa. Cuando el paquete P ingresa en el ncleo de la red, se aplican los PHB, dependiendo de la
marcacin del paquete. Los proveedores del servicio de comunicaciones ATN/PS debern tramitar trfico de ingreso
no marcado o premarcado y estar dispuestos a marcar o remarcar el trfico antes de que se encamine sobre su
infraestructura. Las tcnicas, mecanismos y polticas internas para imponer el PHB dentro de las redes de un proveedor
de servicio de comunicaciones se consideran fuera del mbito de la ATN/PS.

PHBs/CoS en ATN/IPS

1.5.5 La ATN/PS apoyar las aplicaciones ATN heredadas/preexistentes sobre la PS. Actualmente, este
apoyo abarca CM(DLC), FS(ATS), CPDLC, ADS-C, ATSMHS. En verdad, los servicios de directorio (DR) (vase el
Doc 9880, Parte VA) slo se especifican para ATN/OS y se prev que se implantar ADC mediante soluciones
regionales.

1.5.6 Dado que cada aplicacin ATN se hace corresponder en una CoS determinada, no se considera el
apoyo dinmico de las diferentes prioridades por categora de mensaje de usuario.

1.5.7 En la Tabla -1-1 se proporciona un ejemplo de dominio administrativo que apoya varias aplicaciones
y clases de servicio (CoS) denominadas muy alta, alta, normal y mejor esfuerzo.

TabIa III-1-1. Correspondencia entre prioridades ATN/IPS y cIases

Correspondencia prioridad/aplicacin Identificacin de trfico (ingreso)
Clase
(tipo CoS)
Precedencia
de cada
Prioridad
ATN
Aplicacin
ATN
Puerto
TCP/UDP Direccin IP
Muy alta (EF) Voz (VoP) Nmeros RTP
16384-32767

Alta
(AF)
1 0
1
2
3 ADS-C TCP 5913
UDP 5913
La direccin de fuente o
de destino ser parte de
un espacio de direccin
reservado asignado a los
proveedores de servicio
mvil.
CPDLC TCP 5911
UDP 5911
Normal
(AF)
1 4 ADC TCP 8500
1

FS(ATS) TCP 5912
UDP 5912
mvil.
2 5 METAR
3 6 CM(DLC) TCP 5910
UDP 5910
mvil.
ATSMHS TCP 102
7
Mejor esfuerzo
(por defecto)
8 14

1. Esto se aplica cuando se utiliza OLD/FMTP como medio para habilitar servicios ADC.


1.5.8 Para marcar el trfico de ingreso, el proveedor ATN/PS cuenta con varios medios para identificar el
trfico: nmero de puerto de transporte de destino; direccin de fuente P o direccin de destino P.

Nota. Utilizar el valor de punto de cdigo DiffServ (DSCP)/Tipo de servicio (ToS) establecido por la
aplicacin o por un proveedor de servicios de comunicaciones anterior puede no ser el enfoque ptimo, dado que el
valor puede haberse configurado incorrectamente o ser desconocido.

Valores de punto de cdigo DiffServ (DSCP)

1.5.9 El PHB se indica codificando un valor de 6 bits denominado punto de cdigo de servicios
diferenciados (DSCP) en el campo de servicios diferenciados (DS) de 8 bits de la cabecera del paquete P. El valor
DSCP del campo se trata como ndice de tabla para seleccionar un mecanismo de tratamiento de paquetes particular.
Esta correspondencia debe ser configurable y los dominios administrativos pueden optar por diferentes valores cuando
hagan la correspondencia entre los puntos de cdigo y los PHB. No obstante, se acepta ampliamente que el valor
DSCP 101110 se refiere a EF (reenvo acelerado).

1.5.10 En la Tabla -1-2 se proporciona un ejemplo de correspondencia entre valores DSCP y PHB de
ATN/PS donde varias aplicaciones comparten la misma infraestructura de red P. En esta tabla, se ha asignado a las
aplicaciones aire-tierra puntos de cdigo de selector de clase especiales, segn se especifica en el Doc 9880, para el
SNDCF ATN P; pero dentro de la ATN/PS sera mejor utilizar los PHB de AF para evitar toda interaccin con las
aplicaciones heredadas que utilicen la precedencia P.

TabIa III-1-2. EjempIo de correspondencia entre DSCP y PHB

Valor DSCP PHB Aplicacin
000000 CS0 Mejor esfuerzo
001000 CS1
001010 AF11 ADC
001100 AF12
001110 AF13
010000 CS2 CM
010010 AF21 ATSMHS
010100 AF22
010110 AF23
011000 CS3 FS
011010 AF31 Registro de voz
011100 AF32
011110 AF33
100000 CS4 CPDLC, ADS-C
100010 AF41 Sealizacin de voz
100100 AF42
100110 AF43
101000 CS5
101110 EF Voz
110000 NC1/CS6
111000 NC2/CS7

Caracterizacin del trfico

1.5.11 La caracterizacin del trfico es un medio para expresar el tipo de patrones de trfico, integridad y
requisitos de retardo. Proporciona ms informacin al proveedor del servicio de comunicaciones para que pueda
satisfacer plenamente los requisitos de usuario con una operacin de red especfica. Normalmente, la informacin de
caracterizacin del trfico es parte del acuerdo contractual de nivel de servicio en el cual se definen otros parmetros,
como los puntos de entrega de servicio, resistencia del servicio, tamao de rfagas en exceso de la anchura de banda
comprometida requerido, puntos de mtrica del servicio, MTTR y velocidades de puerto.

1.5.12 En la Tabla -1-3 se proporciona un ejemplo de caracterizacin del trfico para servicio tierra-tierra
tomada de las especificaciones de los Servicios de Red Pan-Europeos (PENS).

TabIa III-1-3. EjempIo de caracterizacin deI trfico

Aplicacin
ATN
Longitud
media
de mensaje
Integridad
expresada
Fluctuacin
de fase
Anchura de banda
tpica
(punto a punto)
Retardo
de red
(1 sentido)
Voz (VoP que utiliza
G.729)
70
(bytes)
<15 ms 12 kbps <100 ms
OLD/FMTP (ADC
regional)
150 (bytes) 1 mensaje de
usuario corrupto
en 2 000
N/A 10k bps <1 s
ATSMHS 3 kbytes 10
-6
(en
trminos de
bloques de
mensaje de
1 000 bytes)
N/A 20 kbps <5 s

1.6 ORIENTACIN SOBRE MOVILIDAD

IPv6 mviI

1.6.1 En este manual se especifica que la solucin de movilidad P para la ATN/PS es Pv6 mvil (MPv6)
segn se establece en RFC 3775. Con el P mvil un nodo mvil (MN) tiene dos direcciones: una direccin domstica
(interna) (HoA), que es una direccin permanente, y una direccin temporaria (CoA) dinmica, que cambia a medida
que el nodo mvil cambia su punto de enlace (vase la Figura -1-5). La tcnica fundamental del P mvil es el
reenvo. Un nodo corresponsal (CN), que es cualquier nodo par con el cual un nodo mvil se est comunicando, enva
paquetes al agente domstico (interno) (HA) del nodo mvil. El CN se comunica con el HA a travs de un
encaminamiento P normal. Al recibo de un paquete del CN, el HA reenviar estos paquetes al MN a su CoA actual. El
HA sencillamente realiza el tunelado del paquete original en otro paquete con su propia direccin de fuente y una
direccin de destino de la CoA actual. Esto es posible debido al protocolo P mvil por el cual el MN enva mensajes de
"actualizacin de vinculacin al HA siempre que cambia su punto de enlace. La actualizacin de vinculacin relaciona
la HoA de los nodos mviles con su CoA actual. El HA mantiene un "depsito de vinculaciones que almacena la CoA
actual del MN.


Red externa
(fornea)
Red domstica
(interna)
Red remota
MN
CN
AR AR
HA
HoA
CoA1 CoA2
Movimiento

Figura III-1-5. IP mviI

Tunelado en dos sentidos del MIPv6

1.6.2 En el sentido inverso, el MN podra sencillamente enviar paquetes directamente al CN utilizando
encaminamiento P normal. No obstante, esto resulta en un encaminamiento triangular y dependiendo de la ubicacin
relativa del HA, podra darse una situacin en que la trayectoria en un sentido (p. ej., CN a HA a MN) resulte
considerablemente ms larga que la trayectoria en sentido opuesto (p. ej., MN a CN). Otra consideracin en este caso
ocurre si el MN utiliza su direccin domstica como direccin de fuente, lo cual podra crear un problema en el sentido
de que muchas redes realizan filtrado de ingreso de los paquetes que llegan y no aceptarn paquetes que sean
topolgicamente incorrectos. Esto sera el caso con los paquetes del MN porque realmente se originan en la direccin
temporaria pero la direccin de fuente en paquete P es la direccin domstica. Debido a estos problemas, el MPv6
permite que el MN siga la misma trayectoria de regreso al CN a travs de la HA utilizando un tunelado en ambos
sentidos por el cual, adems de que el HA efecta el tunelado de paquetes al MN, el MN enva paquetes al HA por
tunelado inverso. El HA decapsular los paquetes P tunelados y los reenviar al CN. Con el tunelado en ambos
sentidos no se exige que el CN apoye el P mvil.

Optimizacin de encaminamiento MIPv6

1.6.3 El tunelado en ambos sentidos resuelve los problemas del encaminamiento triangular y del filtrado de
ingreso; no obstante, todava puede haber encaminamientos subptimos dado que la trayectoria del MN al CN a travs
del HA puede ser relativamente larga incluso cuando el MN y el CN estn en estrecha proximidad. Con MPv6 la
situacin en que la trayectoria a travs del HA es ms larga que una trayectoria directa al CN puede enfrentarse
utilizando una tcnica denominada optimizacin de encaminamiento. Con la optimizacin de encaminamiento, el MN
enva actualizaciones de vinculacin al HA y al CN. En este caso, el MN y el CN pueden comunicarse directamente y
adaptarse a los cambios de la CoA del MN. En RFC 3775 se definen los procedimientos para la optimizacin de
encaminamiento. Se exige que el MN inicie el procedimiento de encaminamiento de regreso. Este procedimiento brinda
al CN algunas garantas razonables de que puede dirigirse al MN a la direccin temporaria de ste y a su direccin
domstica fija.

1.6.4 Se reconoce en general que la optimizacin de encaminamientos tiene carencias. En la RFC 4651 se
presenta una taxonoma y un anlisis de mejoras de la optimizacin de encaminamiento MPv6. En este documento se
seala que las dos pruebas de accesibilidad del procedimiento de encaminamiento de retorno pueden conducir a un

retardo del traspaso inaceptable para muchas aplicaciones en tiempo real o interactivas, por el cual la seguridad y las
garantas del procedimiento de encaminamiento de retorno pueden no ser suficientes para las aplicaciones sensibles a
la seguridad y, la restauracin peridica de un registro en un nodo corresponsal puede entraar una sobrecarga por
seales ocultas. Debido a la sobrecarga y el retardo relacionados con el procedimiento de encaminamiento de retorno y
a que por lo menos para ATSC se prev que el CN y el HN estn en una estrecha proximidad relativa, este manual
exige que las CN PS que implanten la optimizacin de encaminamientos de Pv6 mvil permitan que la optimizacin de
los encaminamientos sea habilitada o inhabilitada administrativamente siendo el estado inhabilitado el estado por
defecto. Se prevn nuevas soluciones para la optimizacin de encaminamientos como resultado de la labor programada
por el ETF en el Grupo de trabajo de extensiones de movilidad para Pv6 (MEXT) que incluye requisitos especficos de
la aviacin.

Mejoras deI MIPv6

1.6.5 Cuando un nodo mvil (MN) cambia su punto de enlace con la red, el cambio puede provocar
retardos, prdida de paquetes y, en general, una sobrecarga de trfico en la red.

IPv6 mvil jerrquico (HMIPv6)

1.6.6 Una tecnologa desarrollada para tratar estos problemas es el "Pv6 mvil jerrquico (HMPv6)
(RFC 4140). La RFC 4140 introduce extensiones del Pv6 y del descubrimiento de vecinos Pv6 para permitir el
tratamiento local de la movilidad. HMPv6 reduce el volumen de sealizacin entre un MN, sus CN, y su HA. El HMPv6
introduce el concepto de punto de anclaje de movilidad (MAP). Un MAP es fundamentalmente un agente domstico
local para un nodo mvil. Un nodo mvil que ingresa en un dominio MAP (es decir una red de acceso visitada) recibir
avisos de encaminamiento que contienen informacin sobre uno o ms MAP. El MN puede vincular su ubicacin actual,
es decir su direccin temporaria de enlace (LCoA), con una direccin en la subred del MAP, denominada direccin
temporaria regional (RCoA). Actuando como HA local, el MAP recibir todos los paquetes en nombre del nodo mvil al
que sirve y en los encapsular y reenviar directamente a la direccin actual del nodo mvil. Si ste cambia su
direccin actual dentro de un dominio MAP local (LCoA), slo debe registrar la nueva direccin en el MAP. La RCoA no
cambia mientras el MN se mueve dentro de un dominio MAP. En RFC 4140 se seala que el uso del MAP no supone
que est presente un HA permanente; un MN no necesita tener una HoA o un HA para conocer el HMPv6 o utilizar las
caractersticas de ste. Los nodos mviles que conocen HMPv6 pueden utilizar su RCoA como direccin de fuente sin
utilizar una opcin de direccin domstica local. De esta forma, la RCoA puede utilizarse como direccin de
identificacin para las capas superiores. Utilizando esta caracterstica, el nodo corresponsal ver al nodo mvil como
nodo fijo mientras se mueve dentro de un dominio MAP. Este uso de la RCoA no tiene penalidades similares a la del
Pv6 mvil (es decir no se devuelven al HA opciones de vinculaciones o direcciones domsticas), pero sigue
proporcionando gestin de movilidad (MM) local a los nodos mviles con encaminamiento casi ptimos. No obstante,
este uso de la RCoA no proporciona movilidad mundial.

Traspaso rpido para IPv6 mvil (FMIPv6)

1.6.7 Otra mejora del MPv6 es el protocolo de traspasos rpidos para Pv6 mvil (FMPv6) (RFC 4068). El
protocolo FMPv6 intenta reducir la posibilidad de prdida de paquetes mediante traspasos de baja latencia. FMPv6
intenta optimizar los traspasos obteniendo informacin para un nuevo encaminador de acceso antes de desconectar del
encaminador de acceso anterior. Los encaminadores de acceso solicitan informacin de otros encaminadores de
acceso para adquirir informacin de vecindad que facilite el traspaso. Una vez seleccionado el nuevo encaminador de
acceso, se establece un tnel entre los encaminadores antiguo y nuevo. La direccin temporaria anterior (pCoA) se
vincula con una nueva direccin temporaria (nCoA) de modo que los datos puedan enviarse por tunelado desde el
encaminador de acceso anterior al nuevo encaminador de acceso durante el traspaso. La combinacin de HMPv6 y
FMPv6 contribuira a mejorar la performance del MPv6, pero a expensas de una mayor complejidad.


IPv6 mvil proxy (PMIPv6)

1.6.8 En el MPv6 descrito anteriormente el MN actualiza al HA con mensajes de actualizacin de
vinculaciones. Este modo de funcionamiento se denomina gestin de movilidad basada en nodos. Un enfoque
complementario es que los proveedores de servicios de red de acceso proporcionen gestin de movilidad basada en la
red utilizando el protocolo Pv6 mvil proxy (PMPv6) sobre los enlaces de acceso que apoyan o emulan una entrega
punto a punto. Este enfoque para apoyar la movilidad no exige que el nodo mvil est involucrado en un intercambio de
mensaje de sealizacin entre s mismo el agente domstico para optimizar potencialmente el suministro de servicios
de red de acceso. Un agente de movilidad proxy en la red ejecuta la sealizacin con el agente domstico y lleva a
cabo la gestin de movilidad en nombre del nodo mvil enlazado a la red. Las entidades funcionales bsicas para
PMPv6 son el anclaje de movilidad local (LMA) y la pasarela de acceso mvil (MAG). El anclaje de movilidad local es
responsable de mantener el estado de accesibilidad del nodo mvil y es el punto de anclaje topolgico para los prefijos
de la red domstica del nodo mvil. La MAG es la entidad que realiza la gestin de movilidad en nombre de un nodo
mvil y reside en el enlace de acceso al que est anclado el nodo mvil. La MAG es responsable de detectar los
movimientos del nodo mvil hacia y desde el enlace de acceso y de iniciar registros de vinculacin con el LMA del nodo
mvil. Una red de acceso que apoye la movilidad basada en la red sera indiferente a la capacidad en la pila Pv6 de los
nodos a los que sirve. La movilidad P para nodos que tienen funciones de cliente P mviles en la pila Pv6, as como a
los nodos que no la tienen, estara apoyada mediante las funciones habilitadoras del Pv6 mvil proxy en la red. Las
ventajas de PMPv6 son la reutilizacin de las funciones del agente domstico y los mensajes y formatos utilizados en
la sealizacin de la movilidad y el agente domstico comn servira como agente de movilidad para todos los tipos de
nodos Pv6. PMPv6 al igual que HMPv6 es un enfoque de gestin de movilidad local que reduce an ms la
sobrecarga de seales aire-tierra.

Movilidad en la red (NEMO)

1.6.9 El Pv6 mvil apoya el movimiento de un nodo de red individual. No obstante, hay escenarios en los
cuales sera necesario apoyar el movimiento de toda una red en la ATN/PS. Un caso es el de APC, donde sera un
derroche de anchura de banda contar con sealizacin de movilidad para cada pasajero individual. Otro caso sera
cuando existe un encaminamiento de a bordo comn que apoye mltiples tipos de trfico, siempre que puedan tratarse
los aspectos de seguridad adecuados. La extensin al Pv6 mvil que apoya estos escenarios se denomina movilidad
de red (NEMO). En este manual se presenta NEMO con arreglo a RFC 3963 como una opcin para implantacin. El
modelo operacional NEMO introduce una nueva entidad denominada nodo de red mvil (MNN), que es un nodo en la
red que se mueve como una unidad. Puede ser un anfitrin movindose con otros MNN o un encaminador mvil. El
encaminador mvil funciona como cualquier anfitrin P mvil en la interfaz de egreso (a un encaminador de acceso
fijo). El encaminador mvil tambin negocia una lista de prefijos con el agente domstico. El agente domstico utiliza
esta lista para reenviar paquetes que llegan para los MNN que comparten un prefijo comn al encaminador mvil. En la
interfaz de ingreso (a la red mvil), el encaminador mvil comunica uno o ms prefijos a los MNN. Aunque en la
superficie NEMO parecer ser una extensin directa al P mvil, existen varias consideraciones que todava se estn
investigando en grupos de trabajo del ETF. Estos aspectos comprenden la optimizacin de encaminamientos del
NEMO y la delegacin y gestin de prefijos.

1.7 ORIENTACIN DE SEGURIDAD

1.7.1 En esta seccin figura una descripcin del fundamento de los requisitos presentados en 2.5 de la
Parte . Se proporciona informacin de antecedentes cuando se justifica una aclaracin adicional as como orientacin
general para la aplicacin de disposiciones de seguridad.

Requisitos para impIantacin

1.7.2 Se tiene la intencin de que el requisito de implantar seguridad sea coherente con la arquitectura de
seguridad para Pv6, que exige que todas las implantaciones Pv6 se ajusten a los requisitos de RFC 4301. Aunque

todos los nodos ATN/PS deben implantar la seguridad del protocolo internet (Psec) y el protocolo de intercambio de
claves 2 de internet (KEv2), el uso real de estas disposiciones se basar en un anlisis de amenazas y vulnerabilidad
del sistema.

Seguridad tierra-tierra

IPsec tierra-tierra

1.7.3 La base de la seguridad tierra-tierra es exigir seguridad de la capa de red en la interred ATN/PS,
implantada aplicando Psec. Psec crea una frontera entre interfaces no protegidas y protegidas. Psec se utiliza
normalmente para formar una red privada virtual (VPN) entre pasarelas (NST 800-77). Una pasarela puede ser un
encaminador u otro dispositivo de seguridad como un cortafuegos (firewall). En este contexto, se considera que otros
dispositivos de seguridad son nodos ATN/PS. El modelo pasarela a pasarela protege las comunicaciones entre redes
ATN/PS y entre regiones o entre Estados u organizaciones en una regin particular. Psec tambin puede utilizarse en
un entorno de anfitrin a pasarela, normalmente para permitir que los anfitriones de una red no segura tengan acceso a
recursos protegidos. Psec tambin puede utilizarse en un entorno anfitrin a anfitrin donde se proporciona proteccin
de las aplicaciones de extremo a extremo.

1.7.4 Para lograr el interfuncionamiento a travs de la interred ATN/PS, en este manual se especifica el
apoyo para la arquitectura de seguridad Psec, el protocolo de encapsulado de seguridad de la carga til (ESP) y un
conjunto comn de algoritmos criptogrficos. La arquitectura es la especificada en RFC 4301. ESP es el especificado
en RFC 4303 y los algoritmos criptogrficos que pueden utilizarse se especifican en RFC 4835. En este manual
ATN/PS se especifica adems que el cifrado ESP es opcional pero que la autenticacin se realiza siempre.

1.7.5 En este manual se especifica que los nodos ATN/PS en el entorno tierra-tierra pueden implementar
el protocolo de cabecera de autenticacin (AH) P segn se especifica en RFC 4302. Esto es en reconocimiento de que,
aunque AH puede existir en ciertos productos, su uso en Psec ha sido bajado de categora. En RFC 4301 se seala
que "el apoyo para AH ha sido bajado de categora a "PUEDE debido a que la experiencia ha demostrado que existen
muy pocos contextos en los cuales ESP no puede proporcionar los servicios de seguridad requeridos. Cabe sealar
que ESP puede utilizarse para proporcionar solamente integridad, sin confidencialidad, hacindolo comparable a AH en
la mayora de los contextos.

IKEv2 tierra-tierra

1.7.6 La arquitectura Psec (RFC 4301) especifica el apoyo para la gestin de claves tanto manual como
automtica. A medida que evoluciona la ATN/PS, el uso de la gestin manual de claves no escalar bien. Por
consiguiente, en este manual se especifica que los nodos en el entorno tierra-tierra implantarn el protocolo de
intercambio de claves 2 de internet (KEv2) como se especifica en RFC 4306 para la gestin automtica de claves.
KEv2 es la versin ms reciente de este protocolo. La especificacin KEv2 es menos complicada que la primera
versin del protocolo lo que debera contribuir a un mejor interfuncionamiento entre las diferentes implantaciones.

1.7.7 Al igual que para ESP, el protocolo KEv2 requiere un conjunto de algoritmos de implantacin
obligatoria para el interfuncionamiento. En este manual se requiere que los nodos en el entorno tierra-tierra implanten
los algoritmos criptogrficos especificados en RFC 4307.

Alternativas al IPsec/IKEv2 para seguridad tierra-tierra

1.7.8 Las alternativas de la seguridad de la red pueden resultar apropiadas en algunos entornos
operacionales. Las alternativas Psec pueden aplicarse en la capa de enlace de datos, transporte o aplicacin. En NST
SP 800-77
2
se describen las alternativas principales, se caracterizan las alternativas en trminos de puntos fuertes y
dbiles y se identifican posibles casos donde stas pueden aplicarse.

2. Referirse a http://csoc.nist.gov/publication/nistpubs/800-77/sp800-77.pdf


Seguridad aire-tierra

IPsec aire-tierra

1.7.9 Anlogamente al entorno tierra-tierra, para lograr el interfuncionamiento en el entorno aire-tierra en
este manual se especifica que los nodos ATN/PS apoyen la arquitectura de seguridad Psec y el protocolo ESP. Al
igual que en el caso terrestre, la arquitectura es la especificada en RFC 4301 y ESP es el especificado en RFC 4835.
No obstante, en vez de implantar todos los algoritmos criptogrficos identificados en RFC 4835, se identifican
algoritmos por defecto especficos para autenticacin y para cifrado y autenticacin conjuntamente. Esto se hace
considerando los enlaces aire-tierra de limitada anchura de banda y para no tener cdigos no utilizados en la plataforma
de avinica.

1.7.10 El algoritmo de autenticacin seleccionado para uso cuando no se selecciona tambin la
confidencialidad es AUTH_HMAC_SHA2_256-128 segn se especifica en RFC 4868. Este algoritmo utiliza una clave
de 256 bits para computar una etiqueta de clave de autenticacin de mensaje de condensacin (HMAC) utilizando la
funcin de condensacin SHA-256. La etiqueta se trunca a 128 bits. El mismo algoritmo se utiliza para la integridad en
KEv2 segn se describe a continuacin.

1.7.11 Si se utiliza el cifrado ESP, en este manual se especifica que la norma de cifrado avanzada (AES)
debe utilizarse en el modo Galois/Conteo (GCM). AES-GCM se utiliza con un valor de verificacin de integridad (CV)
de 8 octetos y con un atributo de longitud de clave de 128 segn se especifica en RFC 4106. AES-GCM es un algoritmo
de "modo combinado que ofrece confidencialidad y autenticacin en una sola operacin. Los algoritmos en modo
combinado ofrecen ganancia de eficiencia cuando se les compara con la aplicacin secuencial del cifrado y luego la
autenticacin. Cuando se utiliza AES-GCM el CV consiste solamente en la etiqueta de autenticacin AES-GCM y no se
aplica una etiqueta HMAC separada.

IKEv2 aire-tierra

1.7.12 Debido a que la gestin manual de claves no resulta prctica en el entorno aire-tierra, en este manual
se exige que los nodos ATN/PS implanten el protocolo de intercambio de claves 2 de internet (KEv2) segn se
especifica en RFC 4306. Al igual que para ESP, teniendo en cuenta limitaciones de anchura de banda, y para que no
hayan cdigos no utilizados en la plataforma de avinica, en este manual se especifica un conjunto de algoritmos por
defecto para utilizar en KEv2. La seleccin de las transformaciones tiene por objeto su compatibilidad con las
selecciones de la Air Transport Association (ATA), el Grupo de trabajo sobre seguridad digital (DSWG), el Comit de
ingeniera electrnica de las lneas areas (AEEC) y los Grupos de trabajo sobre seguridad de enlace de datos (DSEC),
en la medida posible; no obstante, en este manual slo se utilizan transformaciones que se han registrado con ANA.
Para KEv2 se usan cinco transformaciones.

1. Existe una funcin pseudoaleatoria (PRF) que se utiliza en KEv2 para generar materiales de
cifrado y para la autenticacin de la asociacin de seguridad KE. En este manual se exige el uso
de PRF_HMAC_SHA_256 segn se especifica en RFC 4868 como PRF.

2. KEv2 utiliza el protocolo de intercambio de claves Diffie-Hellman para obtener un valor secreto
compartido utilizado por los pares en comunicacin. El clculo de Diffie-Hellman entraa
computar un logaritmo discreto que utilice aritmtica de campo finito o aritmtica de curva
elptica. Cuando se utiliza la criptografa de curva elptica, las opciones convencionales son
utilizar ya sea curvas caractersticas de nmeros primos o curvas binarias. En este manual se
seleccionan una curva caracterstica de nmeros primos y se exige el uso de un grupo ECP
aleatorio de 233 bits segn se especifica en RFC 4753.

3. Cuando se utilizan certificados de clave pblica en KEv2 para la autenticacin de entidades
ciertos datos deben firmarse en el intercambio KEv2. En este manual se requiere que la firma se

realice utilizando el algoritmo de firma digital de curva elptica (ECDSA) empleando SHA-256
como algoritmo de condensacin en la curva caracterstica de nmeros primos de 256 bits segn
se especifica en RFC 4754.

4. El intercambio de autenticacin de KEv2 tiene una carga til cifrada y protegida en integridad.
En este manual se especifica que AES-CBC con claves de 128 bits segn se establece en
RFC 3602 debe utilizarse como transformacin de cifrado KEv2.

5. En este manual se especifica que la carga til cifrada est protegida en integridad utilizando
HMAC-SHA-256-128 segn se determina en RFC 4868.

1.7.13 La familia de algoritmos mencionada junto con el uso de AES-GCM para cifrado ESP es el conjunto
"Familia-B-GCM-128 especificado en RFC 4869. Se espera que esta familia est disponible como implantacin
disponible comercialmente (COTS) y que proporcione una fuerza criptogrfica adecuada ms all de 2030. Vase
NST SP 800-57 donde figura orientacin adicional sobre seleccin de algoritmos criptogrficos y tamaos de clave.

1.7.14 El uso de KEv2, a tiempo que ofrece la ventaja de disponibilidad COTS y flexibilidad en los
algoritmos de sealizacin, mecanismos de autenticacin y otros parmetros, resultar en ms sobrecarga que la que
podra obtenerse en una solucin especficamente adaptada a la aviacin. KEv2 requiere que se intercambien por lo
menos cuatro mensajes para establecer una clave de sesin para comunicaciones aire-tierra. Adems, los algoritmos
de cifrado en KEv2 y ESP resultan en una expansin de mensajes. Si bien esta expansin puede resultar despreciable
para mensajes grandes, representar un porcentaje ms importante en los mensajes pequeos. Aunque esto no es una
consideracin importante para los enlaces de datos con limitaciones de banda ancha, se espera que sea menos
problemtica cuando se haya aprobado para servicio de seguridad operacional un enlace de datos de alta velocidad.

Seguridad de las comunicaciones extremo a extremo aire-tierra

1.7.15 En la Figura -1-6 se muestra las opciones para augurar las comunicaciones extremo a extremo en
el entorno aire-tierra ATN/PS. Se requiere implantar KEv2 y ESP de Psec. En este manual tambin se definen
opciones para TLS y para KEv2 con seguridad a nivel de aplicacin. En todos los casos, en el manual se define un
conjunto por defecto de algoritmos criptogrficos.

Seguridad de la capa de red extremo a extremo aire-tierra

1.7.16 Como se describi en 1.7.9 a 1.7.14, para la seguridad de la capa de red extreme a extreme aire-
tierra, en este manual se exige que se implante ESP conjuntamente con KEv2 para establecimiento de claves. En la
Figura -1-6 se muestra el CN en interfaz con un servidor de certificado PK. El mtodo de interfaz se considera asunto
local. Este puede ser una interfaz de protocolo ligero de acceso a directorios (LDAP) con una base de datos de
certificados X.509 y listas de revocacin de certificados (CRL) u otro protocolo de gestin de certificado. Segn se
seal anteriormente, para ESP de KEv2 se est utilizando un conjunto de algoritmos de "Familia-B segn se
especifica en RFC 4869. El certificado de familia B de la Agencia Nacional de Seguridad de los Estados Unidos y el
perfil CRL identifican los mensajes de gestin de certificados sobre el protocolo CMS, segn se especifica en
RFC 2797, que es el protocolo preferido. El mtodo de autenticacin real utilizado en un dominio administrativo es
asunto local y depender de la aplicacin. KEv2 permite utilizar claves precompartidas o certificados digitales siendo
estos ltimos el mtodo considerado como ms fuerte. Sera posible utilizar claves precompartidas en el sentido de
enlace descendente y utilizar certificados digitales en el sentido de enlace ascendente. Dado que no hay forma prctica
para que el MN verifique independientemente un CRL, podran utilizarse certificados de corta duracin en el sentido de
enlace ascendente. MN en enlace descendente si se utilizan certificados digitales, se recomienda que en vez de que el
MN enve un certificado real, este debera utilizar el mtodo de "condensacin y URL de KEv2. Con este mtodo, el
MN enva el URL de un servidor de certificado PK donde el CN puede encontrar su certificado. Este mtodo utiliza
certificados para la autenticacin cuando se requiere una autenticacin fuerte. Este es el enfoque preferido en el
entorno extremo a extremo aunque sera posible utilizar KEv2 y el protocolo de autenticacin extensible (ESP) con una


infraestructura de autenticacin, autorizacin y contabilidad (AAA). Se prev que el concepto de puente PK que est
elaborando el Grupo de trabajo sobre seguridad digital (DSWG) de la Air Transport Association (ATA) facilitar el
funcionamiento de una PK con carcter mundial. En el marco del concepto de puente PK, cada dominio administrativo
puede certificar a un puente central en vez de que cada dominio administrativo certifique mutuamente con todos los
dems dominios administrativos. (En el prrafo 1.7.25 figura ms orientacin sobre perfiles PK y poltica de certificado).

Nodo mvil
Proveedor
de servicio
de moviIidad
(MSP)
Encaminador
de acceso
Encaminador
de acceso
Agente
domstico
KEv2/Psec(ESP),
TLS,
KEv2/Appl-Scty
Nodo
corresponsal
Servidor
de certificados
PK

Figura III-1-6. Opciones para Ia seguridad extremo a extremo aire-tierra

Seguridad en la capa de transporte extremo a extremo aire-tierra

1.7.17 En este manual se permite que los nodos mviles y nodos corresponsales ATN/PS implanten el
protocolo de seguridad de capa de transporte (TLS) especificado en RFC 5246. Esto permite que las aplicaciones que
ya utilizan TLS funcionen en el entorno aire-tierra ATN/PS. Si se utiliza TLS, entonces se requiere la siguiente
secuencia cifrada, segn se define en RFC 4492:

TLS_ECDH_ECDSA_WTH_AES_128_CBC_SHA

1.7.18 Esta secuencia cifrada es para:

1. El protocolo de seguridad de capa de transporte (TLS). Puede usarse la versin 1.0 1.1.

2. Acuerdo de claves de curva elptica Diffie Hellman (ECDH).

3. Algoritmo de firma digital de curva elptica (ECDSA) para autenticacin de clientes.

4. La norma de cifrado avanzada (AES) con tamao de bloque de 128 en el modo de
encadenamiento de bloque cifrado (CBC) para confidencialidad.

5. El algoritmo de condensacin seguro (SHA), versin 1 para integridad (es decir para HMAC).

1.7.19 Esta secuencia cifrada se selecciona porque tiene algoritmos en comn con las identificadas para
Psec e KEv2 aire-tierra. Ntese que esta secuencia cifrada es una implantacin requerida para servidores y tambin
una secuencia que los clientes pueden implantar para cumplir con RFC 4492.

Seguridad en la capa de aplicacin extremo a extremo aire-tierra

1.7.20 En este manual se permite que los nodos mviles y nodos corresponsales ATN/PS implementen una
seguridad de capa de aplicacin en la frontera de servicios de dilogo PS. Esta alternativa est dirigida a las
aplicaciones ATN heredadas o preexistentes que pueden ya implantar una seguridad de capa de aplicacin en el
entorno ATN/OS. En este caso, los nodos mviles y los nodos correspondientes aadirn a los mensajes de aplicacin
un cdigo de autenticacin de mensajes cifrado HMAC-SHA-256. El HMAC-SHA-256 ya se requiere para ESP e KEv2
de modo que no hay esencialmente criptografa adicional para esta opcin. La etiqueta HMAC truncada a 32 bits se
computa sobre los datos de usuario concatenados con un nmero de secuencia de envo para proteccin de la
reproduccin. Dado que KEv2 es un requisito y, si se usa seguridad de capa de aplicacin para la seguridad aire-tierra,
KEv2 se utiliza nuevamente para establecer las claves.

Seguridad de la red de acceso y sealizacin IP mvil

1.7.21 En la Figura -1-7 se muestran opciones para asegurar la sealizacin del proveedor de servicios de
acceso (ASP) o del proveedor de servicios de movilidad (MSP). La distincin entre ASP y MSP ha resultado til en los
grupos de trabajo del ETF que examinan el uso de infraestructuras de extremo final AAA para seguridad de movilidad.
Con arreglo a RFC 4640, un ASP es un explotador de red que proporciona reenvo directo de paquetes P hacia y
desde el anfitrin final. Un MSP es un proveedor de servicios que suministra servicio mvil Pv6. En la figura el servicio
AAA-NA se utiliza para acceso a la red y el servidor AAA-MP se utiliza para acceso al servicio P mvil.

Nodo mvil
Servidor AAA-MP
Servidor AAA-NA
Seguridad de acceso
a la red
Proveedor
de servicio
de moviIidad
(MSP)
Proveedor
de servicio
de acceso
(ASP)
Seguridad
MPv6
Agente
domstico

Figura III-1-7. Seguridad deI ASP o MSP


Seguridad de la sealizacin de IP mvil

1.7.22 De conformidad con RFC 3775, en este manual se requiere que se utilice Psec especficamente para
proteccin de la sealizacin de P mvil con arreglo a RFC 4877. RFC 4877 es una actualizacin de RFC 3776 y
describe como ha de utilizarse KEv2 para la gestin automtica de clave. RFC 4877 en particular describe la forma en
que puede utilizarse KEv2 con EAP como mtodo de autenticacin. Cuando se emplea autenticacin extensible en
KEv2 hay un intercambio adicional despus de los intercambios KE_SA_NT e KE_SA_AUTH. En este caso, el MN
no incluir una carga til de autenticacin en el intercambio KE_SA_AUTH pero incluir una carga til EAP en el
prximo mensaje. Entonces el HA interacta con el servidor AAA-MP para completar el intercambio de autenticacin y,
si resulta exitoso, completa el intercambio KEv2.

Seguridad de acceso a la red aire-tierra

1.7.23 Los nodos mviles implantarn las disposiciones de seguridad de la red de acceso. Las disposiciones
de seguridad de una red de acceso son las relacionadas con el control del acceso a la red en s y se implantan
normalmente utilizando una infraestructura AAA.

1.7.24 Los grupos de trabajo del ETF sobre movilidad y otras organizaciones de elaboracin de normas han
reconocido que, aunque el Pv6 mvil y el Pv6 mvil proxy fueron diseados originalmente sin integracin con una
infraestructura AAA, puede ser ms eficiente autenticar a los usuarios mediante el uso de credenciales almacenadas en
el servidor AAA. Adems, el uso de una infraestructura AAA puede facilitar otras funciones de autoelevacin como la
configuracin dinmica de otros parmetros (es decir, la direccin domstica local y la direccin del agente domstico)
para lograr el registro de movilidad. El EAP entre el MN y el autenticador puede funcionar sobre el protocolo de nivel de
enlace de acceso a la red o conjuntamente con KEv2 segn se describe para la seguridad de la sealizacin P mvil.
El EAP entre el autenticador y el servidor AAA funciona sobre RADUS (RFC 2865) o DAMETER (RFC 3588).

Perfil de infraestructura de claves pblicas y poltica de certificados

1.7.25 En este manual se requiere que los nodos ATN/PS utilicen el perfil de certificado de infraestructura
de clave pblica X.509 y el perfil de lista de revocacin de certificado (CRL), de nternet, segn se especifica en RFC
5280 y el marco de polticas de certificados de infraestructura de clave pblica X.509 y prcticas de certificado, de
nternet, segn se especifica en RFC 3647. En este manual se toma nota de que el Grupo de trabajo sobre seguridad
digital (DSWG) de la Air Transport Association (ATA) ha elaborado una poltica de certificados (Especificacin 42 de
ATA) para uso de la comunidad aeronutica. La Especificacin 42 de ATA incluye perfiles de certificado y CRL
adecuados para aplicaciones aeronuticas. Estos perfiles proporcionan mayor especifidad que RFC 5280, sin entrar en
contradiccin con sta. Los perfiles de la Especificacin 42 de ATA son interoperables con un puente PK de la industria
aeroespacial. El interfuncionamiento con un puente PK aeroespacial y de defensa operacional proporcionar la
oportunidad de aprovechar la infraestructura existente ms que elaborar una infraestructura especfica para la ATN/PS
y lograr ms rpidamente la uniformidad de interfuncionamiento y polticas en un entorno aeroespacial y de defensa
multinacional y de organizaciones mltiples.

Orientacin general para la implantacin de la seguridad

1.7.26 Muchas agencias gubernamentales han elaborado orientacin y perfiles adicionales para implantar la
seguridad. En los Estados Unidos, la serie de recomendaciones NST 800 constituye un ejemplo de orientacin general
para implantacin de la seguridad que abarca una amplia gama de tpicos.

1.7.27 En el ETF se han producido muchos proyectos nternet que tratan de la seguridad. Dos RFC de
informacin de inters particular son la RFC 4942 y la RFC 4864. En la primera se presenta un panorama de problemas
de seguridad relacionados con Pv6. Estos problemas se agrupan en tres categoras generales: problemas debidos al
propio protocolo Pv6; problemas surgidos de los mecanismos de transicin; y problemas debidos a la introduccin de
Pv6. RFC 4864 observa que la traduccin de direcciones de red (NAT) no se requiere en Pv6 y describe cmo los

mecanismos de proteccin de red local (LNP) pueden proporcionar las ventajas de seguridad relacionadas con NAT. En
particular, el RFC 4864 se describe como las herramientas Pv6 para direcciones de privacidad, direcciones locales
nicas, delegacin de prefijos DHCPv6, y direcciones Pv6 no rastreables pueden utilizarse para proporcionar las
ventajas de seguridad percibidas del NAT, incluyendo las siguientes: pasarela entre la nternet y una red interna;
seguridad simple (derivada de la inspeccin dinmica de paquetes); seguimiento de usuario/aplicacin; privacidad y
ocultamiento de topologa; control independiente de direccionamiento no privada; conservacin de recursos de
direcciones mundiales; y mltiples nmeros de acceso y renumeracin. RFC 4864 describe las ventajas adicionales del
Pv6 original y del direccionamiento nico universal, incluyendo las siguientes: conectividad universal cualquiera a
cualquiera, autoconfiguracin, servicios de multidifusin nativos, mayor proteccin de seguridad, movilidad y fusin de
redes.

1.8 VOZ POR PROTOCOLO INTERNET (VoIP)
(TELEFONA POR INTERNET)

Nota. EUROCAE publica una serie de documentos sobre VoIP para ATM que pueden utilizarse
como textos con especificaciones adicionales. Estos documentos estn numerados ED 136, ED 137 y ED 138.

1.8.1 Las ventajas principales relacionadas con el uso de una red por paquetes para la transmisin de voz
digitalizada son:

eficacia en la atribucin de anchura de banda;

capacidad de utilizar modernos mtodos de compresin de la voz;

relaciona los aspectos econmicos con el uso compartido de la red;

costos reducidos;

fiabilidad mejorada de las redes o paquetes; y

capacidad de utilizar mltiples conexiones lgicas sobre un nico circuito fsico.

Normas y protocoIos

1.8.2 Hay dos marcos normalizados para implantar VoP, UT-T H.323 e ETF SP. Aunque ambos
protocolos pueden utilizarse para aplicaciones VoP, el tema central original de cada protocolo es diferente. La idea
central de H.323 es tramitar llamadas telefnicas y multimedios, incluyendo servicios suplementarios, mientras que el
SP fue diseado como protocolo de transaccin genrico para iniciacin de sesiones y no est destinado a ningn
medio especfico (p. ej., audio o vdeo). En los prrafos siguientes se describen detalles de los protocolos pertinentes.

UIT-T H.323

1.8.3 Como se muestra en la Figura -1-8, el H.323 funciona en la capa de aplicacin para apoyar
protocolos de multimedios, datos y sealizacin. En la misma figura tambin se muestran los diversos protocolos para
transportar trfico multimedios sobre redes TCP/UDP/P.


UDP (protocol o de datagramas de usuari o)
Audi o
Codecs
G.711
G.728
G.729
Vi deo
Codecs
H.261
H.263
RTCP
(protocolo
de control
de transporte
en tiempo real)
T.120
(ti empo real )
T.130
(control
audi o
vi sual )
H.225.0
RAS
Q.931
(seal i zaci n
de l l amadas)
H.235
(seguri dad)
H.245
(seal i zaci n
de control )
RTP
Mul ti medi os Transferenci a de datos Seal i zaci n
TCP (protocol o de control de transferenci a)
P (protocol o i nternet) v4 o v6
3e(|e l.150.1
|se(v|c| os
sup| ererla(|os)

Figura III-1-8. Arquitectura bsica H.323

Multimedios

1.8.4 Este grupo de protocolos convierte seales analgicas (p. ej., voz) en seales digitales, que se
introducen en la red UDP/P o se extraen de la misma. Algunos de estos protocolos comprenden:

audio codecs estos comprimen la voz digital para la transmisin con poca anchura de banda y
descomprimen la voz digital recibida de la red para introducirla en el dispositivo audio del usuario
(p. ej., parlante, auriculares);

video codecs estos comprimen el video digital para anchuras de banda limitadas
y descomprimen el video digital recibido de la red para introducir en el dispositivo video del
usuario; y

RTP (protocolo de transporte en tiempo real) y protocolo de control RTP (RTCP) estos son
protocolos de control para las cargas tiles introducidas en la red. El RTP regula la entrega
extremo a extremo de audio y video en tiempo real sobre redes P. El RTCP regula los servicios
de control en las transmisiones multimedios y monitorea la calidad de su distribucin, incluyendo
la sincronizacin de los receptores.

Transferencia de datos

1.8.5 Esta clase de protocolos proporciona comunicaciones de datos multipunto en tiempo real y servicios
de aplicacin sobre redes P (p. ej., toma de decisiones en colaboracin con intercambios de video, voz y datos).


Las transferencias de datos entre aplicaciones genricas y la red P se procesan por el protocolo UT-T T.120 que
puede funcionar sobre varios transportes, incluyendo PSTN e SDN.

1.8.6 El protocolo UT-T T.130 est todava en desarrollo para controlar sesiones audiovisuales para
conferencias multimedios en tiempo real y para asegurar una alta QoS.

1.8.7 Sealizacin

La sealizacin de llamadas UT-T H.225.0 se utiliza para establecer conexiones e intercambiar
seales de llamada entre puntos de extremo (terminales y pasarelas) H.323, que se transportan
como datos en tiempo real sobre la red TCP/UDP/P. El H.225.0 emplea UT-T Q.931 para
establecimiento y desconexin de llamadas.

La sealizacin de control UT-T H.245 se utiliza para intercambiar mensajes de extremo a
extremo entre puntos de extremo H.323. Los mensajes de control se transportan sobre canales
del control lgico H.245 retransmitidos entre puntos extremo de la sesin de conferencia.

UT-T H.235 proporciona servicios de seguridad dentro del marco H.323, como autenticacin,
cifrado, integridad y no repudio.

UT-T H.450.1 trata de los procedimientos y el protocolo de sealizacin entre entidades H.323 para el control de
servicios suplementarios. Otros protocolos dentro de la serie UT-T H.450 (es decir H.450.2-12) proporcionan servicios
suplementarios especficos (p. ej., transferencia de llamadas, retencin de llamadas, llamada en espera y prioridad de
llamadas).

MGCP/MEGACO

1.8.8 En la Figura -1-9 se muestra las familias de protocolos SP. SP es un protocolo de control de carta
de aplicacin que proporciona funciones avanzadas de sealizacin y control para comunicaciones multimedios de
amplio alcance. SP es una alternativa a H.323, que establece, modifica y termina sesiones multimedios y que pueden
utilizarse para telefona P. Constituye un componente importante en el contexto de otros protocolos para permitir una
arquitectura multimedios completa, segn se muestra en la Figura -1-10. Estos protocolos comprenden RTP para
transporte de datos en tiempo real y garanta QoS, RTSP para controlar los medios de difusin en tiempo real,
MEGACO para controlar las pasarelas al PSTN, y SDP para describir las sesiones multimedios. Estas sesiones
comprenden conferencias multimedios por nternet, telefona por nternet y distribucin multimedios sobre
TCP/UDP/Pv4, o Pv6, segn se muestra en la Figura -1-11.

1.9 IMPLANTACIONES IPS

Intercambio de datos en Inea (OLDI)

1.9.1 El intercambio de datos en lnea (OLD) combinado con el protocolo de transferencia de mensajes de
vuelo (FMTP) es un medio para habilitar los requisitos operacionales ADC para la coordinacin y transferencia de
aeronaves entre dependencias de control de trnsito areo adyacentes. La relacin entre los mensajes ADC y OLD se
describe en el Manual de aplicaciones de enlace de datos para los servicios de trnsito areo (Doc 9694), Parte V,
Captulo 1, Apndice. La especificacin de OLD no obliga a implantar mensajes OLD pero establece los requisitos que
deben satisfacer al implantar dichas instalaciones. Si los mensajes OLD se implantan como resultado de disposiciones
normativas, o se basan en un acuerdo bilateral entre dependencias de control de trnsito areo, entonces los requisitos
sealados como obligatorios en esta especificacin para esos mensajes se hacen de implantacin obligatoria. Esto se
requiere para cumplir con la finalidad de los mensajes y asegurar el interfuncionamiento entre sistemas.


Figura III-1-10. Interfaz de VoIP con PSTN a travs de MEGACO

Familia SIP
Control de aplicaciones y sistemas
Servicios
de datos
(p.ej.,
utilizando
RTSP)
PNT
(interfaz con
sealizacin
PSTN,
p.ej., Ss7,
ATS
QSG)
Equipo
AV /O
SP
Mtodos
Transferencia de llamada/conferencia/
retencin de llamada/monitoreo de llamada
y otros servicios suplementarios
Cabeceras
de extensin
Cuerpo de mensaje (p.ej., SDP)
RTP
Audio Vdeo
TCP UDP
P
PSTN
Pasarela
MEGACO
Red
P
Figura III-1-9. FamiIia de protocoIos SIP


Servidor
SP
SP/TCP o UDP
RTP/UDP
Red
P
Red
P
Red
P

Figura III-1-11. VoIP con SIP

El procedimiento de coordinacin exige que los sistemas identifiquen si las transferencias se efectan con arreglo a las
cartas de acuerdo (LoAs). El proceso que verifica dicho cumplimiento se conoce en la especificacin OLD como "el
filtro. La base de datos utilizada para el filtro puede incluir lo siguiente:

puntos de coordinacin convenidos;

niveles de vuelo aceptables (o inaceptables) que tambin pueden estar relacionados con los
puntos de coordinacin;

aerdromos de salida;

destinos;

rutas directas convenidas;

lmites de tiempo o distancia antes del COP, despus de los cuales todos los mensajes de
coordinacin se consideran no normalizados; y

toda otra condicin, segn se convenga bilateralmente.

1.9.2 Todos los elementos de esta lista pueden combinarse para definir condiciones ms complejas. El
formato de los mensajes (vase Procedimientos para los servicios de navegacin area - Gestin del trnsito areo
(PANS-ATM) (Doc 4444) de la OAC o EUROCONTROL Standard Document for ATS Data Exchange Presentation
(ADEXP) que han de transmitirse y recibirse debe convenirse bilateralmente. La direccin de las dependencias ATS
que proporcionan los servicios tambin debe convenirse bilateralmente y debe ser diferente de las direcciones de otras
dependencias con las cuales las dependencias ATS ya estn conectadas o prevn conectarse. Las direcciones de
dependencias ATS son parte del mensaje OLD.


Protocolo de transferencias de mensajes de vuelo (FMTP)

1.9.3 El protocolo de transferencia de mensajes de vuelo (FMTP) es una pila de comunicaciones basada en
TCP/Pv6 para apoyar la transmisin de mensajes OLD. FMTP es una mquina estatal que tramita el establecimiento
de conexiones y la gestin de sesiones. Cada sistema FMTP requiere un valor de identificacin que debe
intercambiarse durante el establecimiento de la conexin. Los valores de identificacin deben convenirse bilateralmente
y deben ser diferentes de los valores de las otras dependencias con las cuales las dependencias ATS ya estn
conectadas o prevn conectarse.

1.9.4 La especificacin FMTP supone la transferencia de caracteres ASC, pero las implantaciones del
protocolo pueden ampliar este apoyo a otros conjuntos de caracteres o transferencias binarias. Se dispone de ms
textos de orientacin sobre FMTP de EUROCONTROL en el siguiente sitio web:

http://www.eurocontrol.int/communications/public/standard_page/com_network.html.

Ensayo de OLDI/FMTP

1.9.5 EUROCONTROL ha elaborado una herramienta de ensayo denominada herramienta de ensayo entre
centros de EUROCONTROL (ETC) para validar las implantaciones OLD/FMTP y construir escenarios de ensayo. La
herramienta en cuestin puede conseguirse por peticin a:

etic@eurocontrol.int.

AMHS

1.9.6 AMHS ya alcanz estado operacional sobre TCP/P en las regiones Europa y Norteamrica. Cabe
sealar que las instalaciones europeas utilizan Pv6 para las interconexiones de redes en conformidad con la Parte de
este documento.

______________________

III-AP-1
APNDICE de Ia Parte III

DOCUMENTOS DE REFERENCIA

NORMAS Y PROTOCOLOS DE IETF

Los documentos siguientes estn disponibles al pblico en http://www.ietf.org y forman parte de este manual en la
medida especificada en el mismo. En caso de conflicto entre los documentos de referencia y el contenido de este
manual, las disposiciones del manual tendrn precedencia.

Peticin de comentarios (RFC)

netlmm-mn-ar-if Network-based Localized Mobility Management nterface between Mobile Node and Mobility Access
Gateway, May 2007
RFC 768 User Datagram Protocol, August 1980
RFC 793 Transmission Control Protocol (TCP), September 1981
RFC 1006 SO Transport Service on top of TCP, May 1987
RFC 1122 Requirements for nternet Hosts Communication Layers
RFC 1123 Requirements for nternet Hosts Application and Support
RFC 1323 TCP Extensions for High Performance, May 1992
RFC 1981 Path Maximum Transmission Unit (MTU) Discovery for P Version 6, August 1996
RFC 2126 SO Transport Service on top of TCP, March 1997
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 2460 nternet Protocol, Version 6 (Pv6) Specification, December 1998
RFC 2474 Definition of Differentiated Services Field (DS Field) in the Pv4 and Pv6 Headers, December 1998
RFC 2475 An Architecture for Differentiated Service
RFC 2488 Enhancing TCP over Satellite Channels, January 1999
RFC 2597 Assured Forwarding PHB Group
RFC 2858 Multiprotocol Extensions for Border Gateway Protocol (BGP-4), June 2000
RFC 3095 Robust Header Compression (ROHC): Framework and Four Profiles; RTP, UDP, ESP, and
Uncompressed
RFC 3241 Robust Header Compression (ROHC) over PPP
RFC 3246 An Expedited Forwarding PHB (Per-Hop Behaviour)
RFC 3602 The AES-CBC Cipher Algorithm and ts Use with Psec
RFC 3647 nternet X.509 Public Key nfrastructure Certificate Policy and Certification Practices Framework
RFC 3775 Mobility Support in Pv6, June 2004
RFC 3963 Network Mobility (NEMO) Basic Support Protocol
RFC 4106 The use of Galois/Counter Mode (GCM) in Psec Encapsulating Security Payload (ESP)
RFC 4213 Basic Transition Mechanisms for Pv6 Hosts and Routers
RFC 4271 A Border Gateway Protocol 4 (BGP-4), January 2006
RFC 4291 P Version 6 Addressing Architecture, February 2006
RFC 4301 Security Architecture for the nternet Protocol, December, 2005
RFC 4302 nternet Protocol (P) Authentication Header, December 2005
RFC 4303 P Encapsulating Security Payload (ESP), December 2005
RFC 4306 nternet Key Exchange (KEv2) Protocol, December 2005
RFC 4307 Cryptographic Algorithms for Use in the nternet Key Exchange Version 2 (KEv2), December 2005
RFC 4443 nternet Control Message Protocol (CMPv6) for the nternet Protocol Version 6 (Pv6) Specification,
March 2006

III-AP-2 Manual para implantar la ATN utilizando normas y protocolos IPS

RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), May 2006
RFC 4555 KEv2 Mobility and Multihoming Protocol (MOBKE), June 2006
RFC 4753 Encryption Control Protocol (ECP) Groups for KE and KEv2
RFC 4754 KE and KEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)
RFC 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM), April 2007
RFC 4831 Goals for Network-Based Localized Mobility Management (NETLMM), April 2007
RFC 4835 Cryptographic Algorithm mplementation Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH) ,April 2007
RFC 4843 An Pv6 Prefix for Overlay Routable Cryptographic Hash dentifiers (ORCHD)
RFC 4868 Using HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 with Psec
RFC 4877 Mobile Pv6 Operation with KEv2 and the Revised Psec Architecture
RFC 4996 Robust Header Compression (ROHC): A Profile for TCP/P (ROHC-TP)
RFC 5246 The Transport Layer Security (TSL) Protocol Version 1.2
RFC 5280 nternet X.509 Public Key nfrastructure Certificate and Certificate Revocation List (CRL) Profile

PUBLICACIONES PERTINENTES DE LA OACI

En caso de conflicto entre este manual y las disposiciones del Anexo 10, las disposiciones del Anexo 10 tendrn
precedencia.

Anexo 2 Reglamento del aire.
Anexo 3 Servicio meteorolgico para la navegacin area internacional.
Anexo 10 Telecomunicaciones aeronuticas, Volumen Sistemas de comunicaciones, Parte Sistemas de
comunicaciones de datos digitales.
Anexo 11 Servicios de trnsito areo.
Procedimientos para los servicios de navegacin area Gestin del trnsito areo (PANS-ATM) (Doc 4444).

ManuaIes de Ia OACI

Manual de aplicaciones de enlace de datos para los servicios de trnsito areo (Doc 9694).
Manual de disposiciones tcnicas de la red de telecomunicaciones aeronuticas (ATN) (Doc 9705).
Manual completo sobre la red de telecomunicaciones aeronuticas (ATN) (Doc 9739).
Manual de especificaciones tcnicas detalladas para la red de telecomunicaciones aeronuticas (ATN) en los que se
aplican normas y protocolos ISO/OSI (Doc 9880) (en preparacin).

ESPECIFICACIONES DE EUROCONTROL

Los siguientes documentos estn disponibles al pblico en http://www.eurocontrol.int/ses y forman parte de este manual
en la medida especificada en el mismo. En caso de conflicto entre estos documentos de referencia y el contenido de
este manual, las disposiciones del manual tendrn precedencia.

EUROCONTROL-SPEC-0100-EUROCONTROL Specification of nteroperability and Performance Requirements for the
Flight Message Transfer Protocol (FMTP), Edition 2.0, June 2007.
EUROCONTROL-SPEC-0106-EUROCONTROL Specification for On-Line Data nterchange (OLD), Edition 4.1,
January 2008.

- FIN -

Organizacin de Aviacin Civil Internacional
Aprobado por el Secretario General
y publicado bajo su responsabilidad
aeronuticas (ATN) utilizando
Primera edicin 2010
Doc 9896
AN/469

DOC. 9896 Manual para Implantar La Red (ATN) Utilizando Norma y Protocolos de La Familia de Internet Es

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DOC. 9896 Manual para Implantar La Red (ATN) Utilizando Norma y Protocolos de La Familia de Internet Es

Încărcat de

Drepturi de autor:

Formate disponibile

Organizacin de Aviacin Civil Internacional

Aprobado por el Secretario General

S-ar putea să vă placă și