C : > 2 > 4 A B 2 > ? > A 5 B 8 0 2 8 0 F 8 > = = > 9 ATN ...dspk.cs.gkovd.ru/library/data/9896_ru.pdf · AMHS Система обработки сообщений ОВД ... IPS

�

Опубликовано отдельными изданиями на русском, английском, испанском и французском языках МЕЖДУНАРОДНОЙ ОРГАНИЗАЦИЕЙ ГРАЖДАНСКОЙ АВИАЦИИ 999 University Street, Montréal, Quebec, Canada H3C 5H7 Информация о порядке оформления заказов и полный список агентов по продаже и книготорговых фирм размещены на веб-сайте ИКАО www.icao.int. Издание первое, 2010. Doc 9896. Руководство по сети авиационной электросвязи (ATN), использующей стандарты и протоколы пакета протоколов Интернет (IPS) Номер заказа: 9896 ISBN 978-92-9231-634-1 © ИКАО 2010 Все права защищены. Никакая часть данного издания не может воспроизводиться, храниться в системе поиска или передаваться ни в какой форме и никакими средствами без предварительного письменного разрешения Международной организации гражданской авиации.

(iii)

ПОПРАВКИ

Об издании поправок сообщается в дополнениях к Каталогу изданий ИКАО; каталог и дополнения к нему имеются на веб-сайте ИКАО www.icao.int. Ниже приводится форма для регистрации поправок.

РЕГИСТРАЦИЯ ПОПРАВОК И ИСПРАВЛЕНИЙ

ПОПРАВКИ ИСПРАВЛЕНИЯ

№ Дата Кем внесено № Дата Кем внесено

(v)

ПРЕДИСЛОВИЕ

Настоящий документ определяет протоколы передачи данных и сервисы для использования при внедрении разработанной Международной организацией гражданской авиации (ИКАО) сети авиационной электросвязи (ATN), использующей пакет протоколов Интернет (IPS). Материал в настоящем документе дополняет Стандарты и Рекомендуемую практику (SARPS), содержащиеся в главе 3 части I тома III Приложения 10 "Авиационная электросвязь". Ниже разъясняется редакционная практика, использованная в настоящем документе. Подробные технические спецификации в документе, в которых основной глагол поставлен в настоящем времени, изъявительном наклонении, обязательны для реализации в целях обеспечения надлежащего функционирования ATN. Подробные технические спецификации в документе, в которых употребляются глаголы "следует" или "должен" в соответствующем лице с инфинитивом основного глагола, рекомендуются для реализации в ATN. Тем не менее, в определенных конфигурациях реализация такой спецификации может не требоваться. Подробные технические спецификации в документе, в которых применяется глагол "может", являются факультативными. Такие факультативные положения не влияют на функциональное взаимодействие между узлами ATN/IPS. Настоящее руководство состоит из следующих частей: Часть I. Подробные технические спецификации. В этой части содержится общее описание ATN/IPS. Оно включает требования к сети, передаче данных и обеспечению безопасности для ATN/IPS. Часть II. Приложения пакета протоколов Интернет (IPS). Эта часть содержит описание приложений, поддерживаемых ATN/IPS. Оно включает механизмы конвергенции и прикладные сервисы, которые позволяют использовать устаревшие приложения ATN, основанные на модели взаимодействия открытых систем (OSI), на транспортном уровне ATN/IPS. Часть III. Инструктивный материал. В этой части содержится инструктивный материал о связи по сети ATN/IPS, включающий информацию об архитектуре, а также общие данные для использования при внедрении ATN/IPS.

______________________

(vii)

ОГЛАВЛЕНИЕ

Страница

Сокращения и термины ................................................................................................................................ (ix) ЧАСТЬ I. ПОДРОБНЫЕ ТЕХНИЧЕСКИЕ СПЕЦИФИКАЦИИ Глава 1. Введение ........................................................................................................................................ I-1-1 1.1 Общий обзор ................................................................................................................................. I-1-1 Глава 2. Требования .................................................................................................................................... I-2-1 2.1 Организация ATN/IPS ................................................................................................................... I-2-1 2.2 Требования к канальному уровню ............................................................................................... I-2-2 2.3 Требования к межсетевому уровню ............................................................................................ I-2-2 2.4 Требования к транспортному уровню ......................................................................................... I-2-5 2.5 Требования к защите .................................................................................................................... I-2-5 2.6 Характеристики ............................................................................................................................. I-2-8 Добавление к части I. План нумерации автономных систем (AS) ............................................................ I-ДОБ-1 ЧАСТЬ II. ПРИЛОЖЕНИЯ ПАКЕТА ПРОТОКОЛОВ ИНТЕРНЕТ (IPS) Глава 1. Введение ........................................................................................................................................ II-1-1 1.1 Цель ............................................................................................................................................... II-1-1 1.2 Устаревшие приложения ATN...................................................................................................... II-1-1 1.3 Наземные приложения ................................................................................................................. II-1-1 1.4 Приложения в связи "воздух – земля" ........................................................................................ II-1-2 1.5 Транспортный уровень ................................................................................................................. II-1-22 1.6 Таблицы состояния IPS-диалогового сервиса (DS) ................................................................... II-1-28 ЧАСТЬ III. ИНСТРУКТИВНЫЙ МАТЕРИАЛ Глава 1. Введение ........................................................................................................................................ III-1-1 1.1 Общий обзор ................................................................................................................................. III-1-1 1.2 Исходная информация ................................................................................................................. III-1-2 1.3 Общие рекомендации .................................................................................................................. III-1-2 1.4 Стек протоколов ........................................................................................................................... III-1-8 1.5 Качество обслуживания (QoS) ..................................................................................................... III-1-17 1.6 Рекомендации по мобильности ................................................................................................... III-1-21 1.7 Рекомендации по защите ............................................................................................................. III-1-24 1.8 Протокол речевой связи в Интернете (VoIP) .............................................................................. III-1-31 1.9 Схемы реализации IPS ................................................................................................................ III-1-34 Добавление к части III. Справочные документы ........................................................................................ III-ДОБ-1

______________________

(ix)

СОКРАЩЕНИЯ И ТЕРМИНЫ

Использованные в настоящем руководстве сокращения определены следующим образом:

AAC Авиационная административная связь AF Ускоренная пересылка AH Заголовок аутентификации AIDC Обмен данными между органами ОВД AINSC Служебная связь авиакомпаний AMHS Система обработки сообщений ОВД ANSP Поставщик аэронавигационного обслуживания AOC Связь в целях авиационного оперативного контроля AS Автономная система ATN Сеть авиационной электросвязи ATSC Связь в целях обслуживания воздушного движения ATSMHS Служба обработки сообщений ОВД ATSU Орган ОВД BGP Протокол граничного шлюза CN Узел-корреспондент CRL Список отозванных сертификатов DiffServ Дифференцированное обслуживание ECC Криптография эллиптической кривой ECP Протокол управления шифрованием EF Ускоренная пересылка ESP Инкапсуляция защищенных данных FMTP Протокол передачи управления полетом HA Домашний агент HC Управление передачей обслуживания HMAC Хэш-код аутентификации сообщения IANA Администрация адресного пространства Интернет ICMP Протокол управляющих сообщений в сети Интернет ICV Значение контроля целостности IETF Специальная группа по разработке Интернета IKEv2 Протокол обмена ключами в Интернете, версия 2 IP Интернет-протокол IPS Пакет Интернет-протоколов IPsec Защита Интернет-протоколов IPv4 Интернет-протокол, версия 4 IPv6 Интернет-протокол, версия 6 ISO Международная организация по стандартизации LIR Локальный Интернет-регистратор LM Управление информацией о местоположении MM Управление мобильностью MN Мобильный узел MoA Меморандум о договоренности MSP Поставщик мобильного обслуживания MTU Максимальный размер пакета передачи OLDI Обмен данными онлайн

(x) Руководство по ATN, использующей стандарты и протоколы IPS

OSI Взаимодействие открытых систем PHB Пошаговое поведение (на каждом узле) PPP Протокол точка-точка QoS Качество обслуживания RFC Запрос на комментарии RIR Региональная Интернет-регистратура ROHC Устойчивое сжатие IP-заголовков RTP Протокол передачи данных в реальном времени SARPS Стандарты и Рекомендуемая практика TCP Протокол управления передачей TLS Защищенная передача данных TOS Тип обслуживания UDP Протокол пользовательских датаграмм ОВД Обслуживание воздушного движения ОрВД Организация воздушного движения РПИ Район полетной информации УВД Управление воздушным движением

Приведенные ниже определения соответствуют терминологии Специальной группы по разработке Интернета (IETF): Автономная система. Связанная группа из одного или более префиксов IP, работающих у одного или

нескольких сетевых операторов, которые имеют единую и четко определенную политику маршрутизации.

Административный домен. Административная единица в ATN/IPS. Административным доменом может быть

отдельное государство, группа государств, организация в авиационной отрасли (например, поставщик обслуживания "воздух – земля") или поставщик аэронавигационного обслуживания (ANSP), которые управляют сетевыми ресурсами и услугами ATN/IPS. С точки зрения маршрутизации административный домен включает одну или несколько автономных систем.

Внутридоменная маршрутизация (протоколы внутренней маршрутизации). Протоколы для обмена

информацией маршрутизации между маршрутизаторами в пределах автономной системы. Глобальная мобильность. Глобальная мобильность представляет собой мобильность в сетях доступа. Локальная мобильность. Локальная мобильность представляет собой мобильность сетевого уровня в сети

доступа. Маршрутизатор. Маршрутизатором является узел, который передает пакеты Интернет-протокола (IP), не

адресованные непосредственно ему. Маршрутизатор управляет ретрансляцией и маршрутизацией транзитных данных между конечными системами отправления и назначения.

Междоменная маршрутизация (протоколы внешней маршрутизации). Протоколы для обмена информацией

маршрутизации между автономными системами. В некоторых случаях они могут использоваться между маршрутизаторами внутри автономной системы, однако в основном предназначены для обмена информацией между автономными системами.

Мобильный IPS-узел. IPS-узел, использующий услуги одного или более поставщиков мобильного

обслуживания (MSP).

Сокращения и термины (xi)

Объединенная сеть ATN/IPS. Объединенная сеть ATN/IPS состоит из узлов и сетей IPS, функционирующих в многонациональной среде.

Поставщик мобильного обслуживания (MSP). Поставщик обслуживания, который предоставляет мобильное

IPv6-обслуживание (т. е. домашние агенты) в сети ATN/IPS. MSP является объектом административного домена (AD), которым может быть поставщик услуг авиационной связи (ACSP), поставщик аэронавигационного обслуживания (ANSP), авиакомпания, полномочный орган аэропорта, правительственная организация и т. д.

Сеть доступа. Сеть, которая характеризуется конкретной технологией доступа. Узел. Устройство, которое использует IPv6. Управление данными о местоположении. Функция управления данными о местоположении (LM) используется

для отслеживания движения мобильного узла и установления местоположения мобильного узла для доставки данных.

Управление мобильностью на базе сетей. Схема управления мобильностью (MM), при которой сигналы MM

передаются объектами сети от имени мобильного узла. Управление мобильностью на базе хостов. Схема управления мобильностью (MM), при которой передачу

сигналов MM выполняет мобильный узел. Управление передачей обслуживания. Функция управления передачей обслуживания (HC) используется для

обеспечения "непрерывности сеанса" в отношении "текущего" сеанса мобильного узла. Хост. Хост – это узел, не являющийся маршрутизатором. Хост представляет собой компьютер, подключенный к

сети ATN/IPS, который предоставляет обслуживание конечным пользователям.

______________________

Часть I

Подробные технические спецификации

I-1-1

Глава 1 ВВЕДЕНИЕ

1.1 ОБЩИЙ ОБЗОР 1.1.1 Настоящее руководство содержит минимальные стандарты и протоколы связи, которые позволят создать разработанную ИКАО сеть авиационной электросвязи (ATN), основанную на пакете протоколов Интернет (IPS), сокращенно именуемую ATN/IPS. Предметом настоящего руководства является функциональное взаимодействие между административными доменами в объединенной сети ATN/IPS, хотя материал руководства может также использоваться внутри административного домена. Внедрение сети ATN/IPS, использующей стандарты и протоколы настоящего руководства, будет осуществляться на основе региональных аэронавигационных соглашений между Договаривающимися государствами ИКАО, как это предусмотрено в п. 3.3.2 главы 3 части I тома III Приложения 10. Координацией работы в рамках таких соглашений занимаются группы регионального планирования и осуществления проектов (PIRG). 1.1.2 Архитектура протоколов ATN/IPS показана на рис. I-1-1. В ATN/IPS принята четырехуровневая модель, которая определена в стандарте Интернет STD003 Общества Интернет (ISOC). Примечание. STD003 представляет собой комбинацию RFC 1122 и RFC 1123 Специальной группы по разработке Интернета (IETF). 1.1.3 Эта модель имеет четыре уровня абстракции: канальный уровень, уровень Интернета или протокола Интернета (IP), транспортный уровень и прикладной уровень. 1.1.4 Как показано на рис. I-1-1, в настоящем руководстве не оговорен какой-либо специальный протокол канального уровня, т. к. этот вопрос регулируется на местном или двустороннем уровнях и не влияет на функциональное взаимодействие в целом. 1.1.5 В руководстве принята версия 6 протокола Интернет (IPv6) для функционального взаимодействия на уровне Интернета. Вопросы использования IPv4 в наземных сетях для перехода к IPv6 (или в качестве постоянной сети) в настоящем руководстве не рассматриваются. Протокол IPv6 должен внедряться в сетях связи "воздух – земля". Для внутридоменной маршрутизации принят протокол граничного шлюза – 4 (BGP-4) с расширениями. 1.1.6 Для передачи с соединением и без организации соединения на транспортном уровне приняты протокол управления передачей (TCP) и протокол пользовательских датаграмм (UDP). 1.1.7 В части II настоящего документа рассматриваются механизмы конвергенции и прикладные сервисы, которые позволяют использовать устаревшие приложения ATN на базе модели взаимодействия открытых систем (OSI) на транспортном уровне ATN/IPS. 1.1.8 Часть III настоящего документа содержит инструктивный материал для обеспечения внедрения ATN/IPS.

I-1-2 Руководство по ATN, использующей стандарты и протоколы IPS

Рис. I-1-1. Архитектура протокола ATN/IPS

______________________

Прикладнойуровень

Прикладнойуровень

КонвергенцияOSI/IPS

Уровень Интернет(I v6)P

Уровень Интернет(I v6, BGP-4+)P

Уровень Интернет(I v6, BGP4+)P

Уровень Интернет(I v6)P

Канальный уровень

Локальная иливнутридоменная

подсеть

Локальная иливнутридоменная

подсетьМеждоменная

подсеть

Канальный уровеньКанальный уровень

Междоменныймаршрутизатор

Распределенные соединения

Междоменныймаршрутизатор

Канальный уровень

I-2-1

Глава 2 ТРЕБОВАНИЯ

2.1 ОРГАНИЗАЦИЯ ATN/IPS

ATN/IPS 2.1.1 Объединенная сеть ATN/IPS состоит из узлов и сетей IPS, функционирующих в много-национальной среде и обеспечивающих связь для обслуживания воздушного движения (ATSC), а также служебную связь авиакомпаний (AINSC), включая авиационную административную связь (AAC) и связь в целях авиационного оперативного контроля (AOC). 2.1.2 В настоящем руководстве узлом IPS считается устройство, использующее IPv6. Существует два типа узлов IPS: — маршрутизатор IPS: узел IPS, осуществляющий пересылку пакетов Интернет-протокола

(IP), не адресованных непосредственно ему; — хост IPS: узел IPS, не являющийся маршрутизатором. 2.1.3 С административной точки зрения объединенная сеть ATN/IPS состоит из нескольких взаимосвязанных административных доменов. Административным доменом может быть отдельное государство, группа государств (например, регион ИКАО), поставщик услуг авиационной связи (ACSP), поставщик аэронавигационного обслуживания (ANSP) или любая другая организационная единица, управляющая ресурсами и службами сети ATN/IPS. 2.1.4 Каждый административный домен, участвующий в объединенной сети ATN/IPS, использует один или несколько маршрутизаторов IPS, которые выполняют протокол междоменной маршрутизации, определенный в настоящем руководстве. 2.1.5 С точки зрения маршрутизации протоколы междоменной маршрутизации используются для обмена информацией маршрутизации между автономными системами (AS), где AS представляет собой связанную группу из одного или более префиксов IP-адреса. Передаваемая информация маршрутизации включает префиксы IP-адресов различной длины. Например, префикс IP-адреса, передаваемый в связи между регионами ИКАО, может быть короче, чем префикс IP-адреса, которым обмениваются отдельные государства в конкретном регионе. 2.1.6 Административным доменам следует координировать политику в области передачи транзитного трафика со своими партнерами.

Мобильность ATN/IPS 2.1.7 Мобильность ATN/IPS основана на стандартах мобильности IPv6, используемых поставщиками мобильного обслуживания (MSP).


Примечание. MSP в сети ATN/IPS представляет собой объект административного домена, которым может быть ACSP, ANSP, авиакомпания, полномочный орган аэропорта, правительственная или другая авиационная организация. 2.1.8 MSP в сети ATN/IPS использует одного или более домашних агентов (HA).

2.2 ТРЕБОВАНИЯ К КАНАЛЬНОМУ УРОВНЮ Вопросы установления характеристик канального уровня для узла IPS решаются на местном уровне.

2.3 ТРЕБОВАНИЯ К МЕЖСЕТЕВОМУ УРОВНЮ

Общие аспекты межсетевого взаимодействия IPv6 2.3.1 Узлы IPS используют IPv6, как указано в RFC 2460. 2.3.2 Узлы IPS используют процесс поиска максимального размера пакета передачи IPv6 (MTU) для выбранного пути, указанный в RFC 1981. 2.3.3 Узлы IPS устанавливают значение поля метки потока в заголовке IPv6 на 0, т. к. оно не используется в ATN/IPS.

Мобильный протокол IPv6 2.3.4 Мобильные IPS-узлы (MN) используют мобильный протокол IPv6, как указано в RFC 3775. 2.3.5 Домашние агенты IPS используют мобильный протокол IPv6, как указано в RFC 3775. 2.3.6 IPS MN и HA могут использовать расширения мобильного протокола IPv6 для обеспечения поддержки сетевой мобильности, как указано в RFC 3963. 2.3.7 Узлы IPS, использующие оптимизацию маршрута мобильного протокола IPv6, разрешают административное включение или выключение функции оптимизации маршрута, причем по умолчанию устанавливается значение "выключено". Примечание. Использование функции оптимизации маршрута мобильного протокола IPv6 не является обязательным по данной спецификации до тех пор, пока IETF не разработает дополнительные стандарты RFC.

Сетевая адресация 2.3.8 Узлы IPS используют архитектуру адресации IPv6, указанную в RFC 4291. 2.3.9 Узлы IPS используют адреса IPv6 глобального действия при передаче данных в ATN/IPS.

Часть I. Подробные технические спецификации Глава 2. Требования I-2-3

2.3.10 Административные домены получают присвоенные префиксы адреса IPv6 в своей местной Интернет-регистратуре (LIR) или региональной Интернет-регистратуре (RIR). 2.3.11 MSP получают присвоенные 32-битовые префиксы адреса IPv6 для исключительного использования мобильными IPS-узлами или мобильными сетями. 2.3.12 MSP должны использовать структуру адресов IPv6 для присвоения воздушным судам (см. рис. I-2-1).

Рис. I-2-1

Примечание 1. При такой структуре каждое воздушное судно является 56-битовым конечным сайтом IPv6, основанным на распределяемых ИКАО 24-битовых адресах воздушных судов, которые определены в добавлении к главе 9 части I тома III Приложения 10. Примечание 2. Для передач с борта (ОВД, AOC, AAC, и т. д.), воздушное судно может иметь несколько подсетей, соединенных с мобильным маршрутизатором, несколько MSP или сочетание обоих вариантов. 2.3.13 MSP размещает свои 32-битовые агрегированные префиксы в сети ATN/IPS.

Междоменная маршрутизация Примечание 1. Протоколы междоменной маршрутизации используются для обмена информацией маршрутизации между AS. Примечание 2. Для целей маршрутизации AS имеет уникальный идентификатор, называемый номером AS. Примечание 3. Один административный домен может отвечать за управление несколькими AS. Примечание 4. Протокол маршрутизации в рамках AS определяется на местном уровне управляющей организацией. 2.3.14 IPS-маршрутизаторы, поддерживающие междоменную динамическую маршрутизацию, используют BGP-4, как указано в RFC 4271. 2.3.15 IPS-маршрутизаторы, которые поддерживают междоменную динамическую маршрутизацию, используют мультипротокольные расширения для BGP-4, как указано в RFC 2858. 2.3.16 Административные домены используют номера AS для маршрутизаторов ATN/IPS, которые применяют BGP-4.

Поставщик мобильногообслуживания

RIR/LIR

ПодсетьID Интерфейс IDАдрес ВС ИКАО

32 бит 24 бит 8 бит 64 бит


2.3.17 Административные домены, которые используют частные номера AS, следуют плану нумерации AS, приведенному в добавлении к части I настоящего документа. Примечание. Административным доменам, которым требуются дополнительные частные номера AS, следует осуществлять координацию через ИКАО. 2.3.18 IPS-маршрутизаторам, которые поддерживают междоменную динамическую маршрутизацию, следует аутентифицировать обмены информацией маршрутизации, как указано в RFC 2385.

Обнаружение ошибок и сообщение о них 2.3.19 IPS-узлы используют протокол управляющих сообщений в сети Интернет (ICMPv6), как указано в RFC 4443.

Качество обслуживания (QoS) 2.3.20 Административные домены используют дифференцированное обслуживание (DiffServ), как указано в RFC 2475, для обеспечения качества обслуживания (QoS) приложений и служб ATN/IPS. 2.3.21 Административные домены используют функции дифференцированных классов обслуживания в сети ATN/IPS для удовлетворения эксплуатационных и прикладных требований. 2.3.22 Административные домены, предоставляющие услуги IP-телефонии, используют функцию пошагового поведения (PHB) при ускоренной пересылке (EF), как указано в RFC 3246. 2.3.23 Административные домены пропускают прикладной трафик ATN через PHB гарантированной пересылки (AF), как указано в RFC 2597. Примечание. Функция гарантированной пересылки позволяет оператору ATN/IPS гарантировать доставку сообщения при условии, что объем трафика не превышает установленных пределов. Избыточный трафик с большей вероятностью отбрасывается при возникновении перегруженности. 2.3.24 Административные домены, осуществляющие приоритизацию в отношении PHB AF, устанавливают соотношение между приоритетами передачи сообщений в ATN, как указано в таблице 3-1 главы 3 части I тома III Приложения 10.

Переход на другую версию IP 2.3.25 Административным доменам следует использовать механизм двойного уровня IP для обеспечения совместимости IPv6 и IPv4, как описано в RFC 4213. Примечание. Данное положение гарантирует, что хосты ATN/IPS будут также поддерживать IPv4 для обратной совместимости с локальными приложения IPv4.


2.4 ТРЕБОВАНИЯ К ТРАНСПОРТНОМУ УРОВНЮ

Протокол управления передачей (TCP) 2.4.1 IPS-узлы используют протокол управления передачей (TCP), как указано в RFC 793. 2.4.2 IPS-узлы могут использовать расширения TCP для повышения производительности, как указано в RFC 1323.

Протокол пользовательских датаграмм (UDP) 2.4.3 IPS-хосты используют протокол пользовательских датаграмм, как указано в RFC 768.

Номера портов протокола передачи 2.4.4 IPS-узлы поддерживают и используют номера портов TCP и/или UDP, которые определены в пп. 2.1.1.2, 2.1.2.3 и 2.3.2 части II настоящего документа.

2.5 ТРЕБОВАНИЯ К ЗАЩИТЕ Примечания. При использовании изложенных ниже требований к защите связи в сети ATN/IPS следует руководствоваться результатами анализа угрозы и уязвимости системы. 2.5.1 Настоящий раздел определяет требования и возможности защиты IPS-узла, но не предписывает их использование при передаче данных в сети ATN/IPS.

Защита связи "земля – земля" Примечание. Защита IP-уровня при ведении связи "земля – земля" в объединенной сети ATN/IPS осуществляется с помощью протокола защиты сетевого трафика (IPsec) и протокола обмена ключами в Интернет, версия 2 (IKEv2). IPsec/IKEv2 в связи "земля – земля" 2.5.2 IPS-узлы при ведении связи "земля – земля" соблюдают требования архитектуры защиты для Интернет-протокола, указанные в RFC 4301. 2.5.3 IPS-узлы при ведении связи "земля – земля" используют IP-протокол инкапсуляции защищенных данных (ESP), как указано в RFC 4303. 2.5.4 IPS-узлы при ведении связи "земля – земля" могут использовать IP-протокол заголовка аутентификации (AH), как указано в RFC 4302. 2.5.5 IPS-узлы при ведении связи "земля – земля" используют протокол обмена ключами в сети Интернет, версия 2 (IKEv2), как указано в RFC 4306.


2.5.6 IPS-узлы при ведении связи "земля – земля" соблюдают требования к использованию криптографических алгоритмов для ESP и AH, если применяются AH, как указано в RFC 4835. 2.5.7 IPS-узлы при ведении связи "земля – земля" используют нулевой алгоритм шифрования, как указано в RFC 4835, но не нулевой алгоритм аутентификации, при установлении ассоциаций протокола защиты сетевого трафика (IPsec). 2.5.8 IPS-узлы при ведении связи "земля – земля" применяют криптографические алгоритмы, предназначенные для использования в протоколе IKEv2, как указано в RFC 4307, при согласовании алгоритмов для обмена ключами. 2.5.9 IPS-узлы при ведении связи "земля – земля" должны использовать профиль сертификата инфраструктуры открытых ключей в формате Интернет X.509 и списка отозванных сертификатов (CRL), указанный в RFC 5280, если в качестве метода аутентификации IKEv2 используется цифровая подпись. 2.5.10 IPS-узлы при ведении связи "земля – земля" должны использовать определенные стандартом Интернет X.509 политику в области сертификатов инфраструктуры открытых ключей и рамки практики сертификатов, как указано в RFC 3647, если в качестве метода аутентификации IKEv2 используется цифровая подпись. Примечание. Рабочая группа по безопасности цифровой связи (DSWG) Ассоциации воздушного транспорта (ATA) разработала политику в области сертификатов (спецификация 42 ATA) для использования авиационным сообществом. Спецификация 42 ATA содержит профили сертификатов и CRL, пригодные для авиационного применения и функционального взаимодействия с используемым аэрокосмической отраслью мостом в инфраструктуру открытых ключей (PKI). Эти профили более конкретны, чем в RFC 5280, но не противоречат этому документу.

Защита связи "воздух – земля" Защита сети доступа "воздух – земля" 2.5.11 Мобильные IPS-узлы вводят меры защиты сети доступа, обеспечивающие безопасность сети доступа. Примечание. Например, в сетях доступа WiMAX, 3GPP и 3GPP2 действуют процедуры аутентификации и авторизации. IPsec/IKEv2 в связи "воздух – земля" 2.5.12 IPS-узлы при ведении связи "воздух – земля" соблюдают требования архитектуры защиты протокола Интернет, как указано в RFC 4301. 2.5.13 IPS-узлы при ведении связи "воздух – земля" используют IP-протокол ESP, как указано в RFC 4303. 2.5.14 IPS-узлы при ведении связи "воздух – земля" используют AUTH_HMAC_SHA2_256-128 в качестве алгоритма целостности для аутентификации ESP, как указано в RFC 4868, при установлении ассоциаций защиты IPsec.


2.5.15 IPS-узлы при ведении связи "воздух – земля" с шифрованием используют AES-GCM с 8-октетным значением контроля целостности (ICV) и атрибутом длины ключа 128 бит для шифрования и аутентификации ESP, как указано в RFC 4106. 2.5.16 IPS-узлы при ведении связи "воздух – земля" используют протокол IKEv2, как указано в RFC 4306. 2.5.17 IPS-узлы при ведении связи "воздух – земля" используют протокол IKEv2 со следующими преобразованиями: a) PRF_HMAC_SHA_256 в качестве псевдослучайной функции, как указано в RFC 4868; b) 256-битовая случайная группа протокола управления шифрованием (ECP) для значений

обмена ключами по алгоритму Диффи-Хэллмана, как указано в RFC 4753; c) ECDSA с SHA-256 на кривой P-256 в качестве метода аутентификации, как указано в

RFC 4754; d) AES-CBC с 128-битовыми ключами в качестве преобразований шифрования IKEv2, как

указано в RFC 3602; e) HMAC_SHA_256-128 в качестве преобразования целостности IKEv2, как указано в

RFC 4868. 2.5.18 IPS-узлы при ведении связи "воздух – земля" должны использовать установленный стандартом Интернет X.509 профиль сертификата инфраструктуры открытых ключей и списка отозванных сертификатов (CRL), как указано в RFC 5280, если в качестве метода аутентификации IKEv2 используется цифровая подпись. 2.5.19 IPS-узлы при ведении связи "воздух – земля" должны использовать соответствующую стандарту Интернет X.509 политику в области сертификатов инфраструктуры открытых ключей и рамки практики сертификатов, как указано в RFC 3647, если в качестве метода аутентификации IKEv2 используется цифровая подпись. Примечание. Рабочая группа по безопасности цифровой связи (DSWG) Ассоциации воздушного транспорта (ATA) разработала политику в области сертификатов (спецификация 42 ATA) для использования авиационным сообществом. Спецификация 42 ATA содержит профили сертификатов и CRL, пригодные для авиационного применения и функционального взаимодействия с используемым аэрокосмической отраслью мостом в инфраструктуру открытых ключей (PKI). Эти профили более конкретны, чем в RFC 5280, но не противоречат этому документу. 2.5.20 IPS-узлы при ведении связи "воздух – земля" используют мобильный протокол IPv6 с IKEv2 и пересмотренную архитектуру IPsec, как указано в RFC 4877. Защита транспортного уровня при связи "воздух – земля" 2.5.21 Мобильные IPS-узлы и узлы-корреспонденты могут вводить протокол защищенной передачи данных (TLS), как указано в 5246. 2.5.22 Мобильные IPS-узлы и узлы-корреспонденты используют пакет шифрования TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, как указано в RFC 4492, при использовании TLS.


Защита прикладного уровня при связи "воздух – земля" 2.5.23 Мобильные IPS-узлы и узлы-корреспонденты могут вводить меры защиты прикладного уровня на границе диалогового обслуживания IPS, которые указаны в разделе 1.4 части II настоящего документа. 2.5.24 Мобильные IPS-узлы и узлы-корреспонденты добавляют в конце сообщений хэш-код аутентификации сообщений (HMAC), как указано в RFC 2104, используя SHA-256 в качестве криптографической хэш-функции, если применяются меры защиты прикладного уровня. 2.5.25 Тег HMAC, укороченный до 32 битов, передается поверх данных пользователя вместе с 32-битовым порядковым номером направляемого пакета для защиты повторной передачи, если применяются меры защиты прикладного уровня. 2.5.26 IKEv2 используется для ввода в действие ключа, как указано в пп. 2.5.12–2.5.20, если применяются меры защиты прикладного уровня.

2.6 ХАРАКТЕРИСТИКИ 2.6.1 IPS-узлы могут использовать RFC 2488 для улучшения характеристик в каналах спутниковой связи. 2.6.2 IPS-узлы могут использовать рамки устойчивого сжатия IP-заголовков (ROHC), как указано в RFC 4995, для оптимизации использования ширины полосы. 2.6.3 Если осуществляется поддержка ROHC, поддерживаются, соответственно, следующие профили ROHC: a) профиль ROHC для TCP/IP, указанный в RFC 4996; b) профиль ROHC для протокола передачи данных в реальном времени (RTP)/UDP/ESP,

указанный в RFC 3095; c) профиль ROHC только для IP, указанный в RFC 4843; d) профиль ROHC поверх протокола точка-точка (PPP), указанный в RFC 3241.

______________________

I-ДОБ-1

ДОБАВЛЕНИЕ к части I

План нумерации автономных систем (AS)

Примечание. Настоящий план нумерации охватывает Договаривающиеся государства ИКАО, государства, не являющиеся Договаривающимися, и территории

Регион ИКАО Страна/организация/территория Номер AS

APAC Австралия 64520 EUR/NAT Австрия 64616 EUR/NAT Азербайджан 64620 EUR/NAT Албания 64608 EUR/NAT Алжир 64804 APAC Американское Самоа (Соединенные Штаты Америки) 64513 NACC Ангилья (Соединенное Королевство) 64515 ESAF Ангола 64514 EUR/NAT Андорра 64808 NACC Антигуа и Барбуда 64516 SAM Аргентина 64517 EUR/NAT Армения 64612 NACC Аруба (Нидерланды) 64518 APAC Афганистан 64512 NACC Багамские Острова 64521 APAC Бангладеш 64522 NACC Барбадос 64523 MID Бахрейн 64590 EUR/NAT Беларусь 64624 NACC Белиз 64524 EUR/NAT Бельгия 64628 WACAF Бенин 64525 NACC Бермудские Острова (Соединенное Королевство) 64526 EUR/NAT Болгария 64636 SAM Боливия 64529 EUR/NAT Босния и Герцеговина 64632 ESAF Ботсвана 64530 SAM Бразилия 64531 ESAF Британская территория в Индийском океане 64532 NACC Британские Виргинские Острова (Соединенное Королевство) 65305 APAC Бруней-Даруссалам 64533 WACAF Буркина- Фасо 64534 ESAF Бурунди 64535 APAC Бутан 64527 EUR/NAT Бывшая югославская Республика Македония 64716 APAC Вануату 65303 EUR/NAT Венгрия 64680 SAM Венесуэла 64528 NACC Виргинские Острова (Соединенные Штаты Америки) 65306 APAC Вьетнам 65304 WACAF Габон 64566 NACC Гаити 64576

I-ДОБ-2 Руководство по ATN, использующей стандарты и протоколы IPS


SAM Гайана 64574 WACAF Гамбия 64567 WACAF Гана 64568 NACC Гватемала 64571 WACAF Гвинея 64572 WACAF Гвинея-Бисау 64573 EUR/NAT Германия 64672 EUR/NAT Гибралтар (Соединенное Королевство) 64812 NACC Гондурас 64577 APAC Гонконг, Китай 64578 NACC Гренада 64569 EUR/NAT Гренландия (Дания) 64816 EUR/NAT Греция 64676 EUR/NAT Грузия 64668 APAC Гуам (Соединенные Штаты Америки) 64570 EUR/NAT Дания 64652 WACAF Демократическая Республика Конго 64552 ESAF Джибути 64554 NACC Доминика 64555 NACC Доминиканская Республика 64556 EUR/NAT Евроконтроль 65208 EUR/NAT Евроконтроль 65212 EUR/NAT Евроконтроль 65216 EUR/NAT Евроконтроль 65220 EUR/NAT Евроконтроль 65224 EUR/NAT Евроконтроль 65228 EUR/NAT Евроконтроль 65232 EUR/NAT Евроконтроль 65236 MID Египет 64559 ESAF Замбия 65310 Западная Сахара 65308 ESAF Зимбабве 65311 EUR/NAT Израиль 64584 APAC Индия 64580 APAC Индонезия 64581 MID Иордания 64588 MID Ирак 64583 MID Иран, Исламская Республика 64582 EUR/NAT Ирландия 64688 EUR/NAT Исландия 64684 EUR/NAT Испания 64768 EUR/NAT Италия 64692 MID Йемен 65309 WACAF Кабо-Верде 64539 EUR/NAT Казахстан 64696 NACC Каймановы Острова (Соединенное Королевство) 64540 APAC Камбоджа 64536 WACAF Камерун 64537 NACC Канада 64538 MID Катар 65269

Часть I. Подробные технические спецификации Добавление. План нумерации автономных систем (AS) I-ДОБ-3


ESAF Кения 64589 MID Кипр 64644 APAC Кирибати 64592 APAC Китай 64544 SAM Колумбия 64545 ESAF Коморские Острова 65298 WACAF Конго 64546 APAC Корейская Народно-Демократическая Республика 64551 NACC Коста-Рика 64548 WACAF Кот-д'Ивуар 64549 NACC Куба 64550 MID Кувейт 64593 EUR/NAT Кыргызстан 64700 APAC Лаосская Народно-Демократическая Республика 64595 EUR/NAT Латвия 64704 ESAF Лесото 64597 WACAF Либерия 64598 MID Ливан 64596 MID Ливийская Арабская Джамахирия 64599 EUR/NAT Литва 64708 EUR/NAT Лихтенштейн 64706 EUR/NAT Люксембург 64712 ESAF Маврикий 65238 WACAF Мавритания 65237 ESAF Мадагаскар 64601 APAC Макао, Китай 64600 ESAF Малави 64602 APAC Малайзия 64603 WACAF Мали 64605 APAC Мальдивы 64604 EUR/NAT Мальта 64720 APAC Марианские Острова (Соединенные Штаты Америки) 64606 EUR/NAT Марокко 64824 APAC Маршалловы Острова 64607 NACC Мексика 65239 APAC Мидуэй (Соединенные Штаты Америки) 65241 APAC Микронезии, Федеративные Штаты 65240 ESAF Мозамбик 65244 EUR/NAT Монако 64728 APAC Монголия 65242 NACC Монтсеррат (Соединенное Королевство) 65243 APAC Мьянма 65245 ESAF Намибия 65246 APAC Науру 65247 APAC Непал 65248 WACAF Нигер 65253 WACAF Нигерия 65254 NACC Нидерландские Антильские Острова 65249 EUR/NAT Нидерланды 64732 NACC Никарагуа 65252

I-ДОБ-4 Руководство по ATN, использующей стандарты и протоколы IPS


APAC Ниуэ (Новая Зеландия) 65255 APAC Новая Зеландия 65251 APAC Новая Каледония (Франция) 65250 EUR/NAT Норвегия 64736 ESAF Объединенная Республика Танзания 65300 MID Объединенные Арабские Эмираты 65299 WACAF О-ва Вознесения и Св. Елены (Соединенное Королевство) 64519 MID Оман 65256 APAC Остров Джонстон (Соединенные Штаты Америки) 64587 APAC Остров Пасхи (Чили) 64557 APAC Остров Питкэрн (Соединенное Королевство) 65266 APAC Остров Уэйк (Соединенные Штаты Америки) 65307 APAC Острова Кука 64547 NACC Острова Теркс и Кайкос (Соединенное Королевство) 65295 APAC Острова Уоллис и Футуна (Франция) 64579 APAC Пакистан 65257 APAC Палау 65258 Палестинская территория, оккупирована 65259 APAC Пальмира (Соединенные Штаты Америки) 65260 SAM Панама 65261 APAC Папуа-Новая Гвинея 65262 SAM Парагвай 65263 SAM Перу 65264 EUR/NAT Польша 64740 EUR/NAT Португалия 64744 NACC Пуэрто-Рико (Соединенные Штаты Америки) 65268 EUR/NAT Региональный – Европа 65108 EUR/NAT Региональный – Европа 65112 APAC Республика Корея 65270 EUR/NAT Республика Молдова 64724 ESAF Реюньон (Франция) 64594 APAC Риф Кингмен (Соединенные Штаты Америки) 64591 EUR/NAT Российская Федерация 64752 ESAF Руанда 65272 EUR/NAT Румыния 64748 NACC Сальвадор 64560 APAC Самоа 65276 EUR/NAT Сан-Марино 64828 WACAF Сан-Томе и Принсипи 65277 MID Саудовская Аравия 65278 ESAF Свазиленд 65289 EUR/NAT Святейший Престол 64782 ESAF Сейшельские Острова 65280 WACAF Сенегал 65279 NACC Сент-Винсент и Гренадины 65275 NACC Сент-Китс и Невис 65273 NACC Сент-Люсия 65274 EUR/NAT Сербия 64756 APAC Сингапур 65282 MID Сирийская Арабская Республика 65290

Часть I. Подробные технические спецификации Добавление. План нумерации автономных систем (AS) I-ДОБ-5


EUR/NAT Словакия 64760 EUR/NAT Словения 64764 EUR/NAT Соединенное Королевство 64796 NACC Соединенные Штаты Америки 65301 APAC Соломоновы Острова 65283 ESAF Сомали 65284 MID Судан 65287 SAM Суринам 65288 WACAF Сьерра-Леоне 65281 EUR/NAT Таджикистан 64776 APAC Таиланд 65291 APAC Тимор-Лешти 64553 WACAF Того 65292 APAC Тонга 65293 NACC Тринидад и Тобаго 65294 APAC Тувалу 65296 EUR/NAT Тунис 64832 EUR/NAT Туркменистан 64788 EUR/NAT Турция 64784 ESAF Уганда 65297 EUR/NAT Узбекистан 64800 EUR/NAT Украина 64792 SAM Уругвай 65302 APAC Фиджи 65271 APAC Филиппины 65265 EUR/NAT Финляндия 64660 SAM Фолклендские Острова (Соединенное Королевство) 64564 EUR/NAT Франция 64664 SAM Французская Гайана 64575 APAC Французская Полинезия 65267 NACC Французские Антильские Острова 64565 EUR/NAT Хорватия 64640 WACAF Центральноафриканская Республика 64541 WACAF Чад 64542 EUR/NAT Черногория 64820 EUR/NAT Чешская Республика 64648 SAM Чили 64543 EUR/NAT Швейцария 64780 EUR/NAT Швеция 64772 APAC Шри-Ланка 65286 SAM Эквадор 64558 WACAF Экваториальная Гвинея 64561 ESAF Эритрея 64562 EUR/NAT Эстония 64656 ESAF Эфиопия 64563 ESAF Южная Африка 65285 NACC Ямайка 64585 APAC Япония 64586

______________________

Часть II

Приложения пакета протоколов Интернет (IPS)

II-1-1

Глава 1 ВВЕДЕНИЕ

1.1 ЦЕЛЬ Примечание. В настоящей части описывается, как устаревшие приложения ATN могут использовать ATN/IPS.

1.2 УСТАРЕВШИЕ ПРИЛОЖЕНИЯ ATN Примечание. Устаревшие приложения ATN определены в Руководстве по техническим положениям для сети авиационной электросвязи (ATN) (Doc 9705) и/или Руководстве по подробным техническим спецификациям для сети авиационной электросвязи (ATN), использующей стандарты и протоколы ISO/OSI (Doc 9880) (подготавливается). Приложения ATN, описанные в документах Doc 9705 и Doc 9880, предусматривают использование уровней ATN/OSI для связного обслуживания. В настоящей главе описывается, как эти приложения используют протоколы ATN/IPS с минимальными последствиями для самих приложений.

1.3 НАЗЕМНЫЕ ПРИЛОЖЕНИЯ

Служба обработки сообщений ОВД (ATSMHS) Примечание 1. Целью приложения ATSMHS является предоставление общего обслуживания, связанного с обработкой сообщений в ATN. Примечание 2. IPS-хосты, которые поддерживают приложение ATSMHS, отвечают требованиям части IIB Doc 9880. 1.3.1 Для реализации ATSMHS в ATN/IPS IPS-хосты: a) используют RFC 2126 для обеспечения непосредственного сопряжения с TCP/IPv6; или b) используют RFC 1006 для обеспечения сопряжения с TCP/IPv4 в сочетании с устройством(ами)

преобразования протоколов IPv4/IPv6. 1.3.2 IPS-хосты, которые поддерживают приложение ATSMHS, используют TCP-порт № 102, как указано в RFC 1006 и RFC 2126.

Обмен данными между органами ОВД (AIDC) Примечание 1. Приложение AIDC, которое определено в Руководстве по применению линий передачи данных в целях обслуживания воздушного движения (Doc 9694), обеспечивает обмен информацией между органами ОВД (ATSU), осуществляющими критические функции управления воздушным движением

II-1-2 Руководство по ATN, использующей стандарты и протоколы IPS

(УВД), например, уведомление о воздушных судах, приближающихся к границе района полетной информации (РПИ), координация действий в пограничных районах и передача полномочий на управление и ведение связи. Примечание 2. Приложение AIDC, которое определено в части IIA документа Doc 9880, в настоящее время не планируется к реализации в ATN/IPS. 1.3.3 IPS-хосты в ATN, которые поддерживают обмены приложениями AIDC, могут использовать эквивалентные эксплуатационные приложения, описанные в спецификациях Евроконтроля для обмена данными онлайн (OLDI). 1.3.4 IPS-хосты в ATN, которые поддерживают приложение OLDI, используют спецификации Евроконтроля для протокола передачи сообщений о полете при реализации указанного приложения в IPv6. 1.3.5 IPS-хосты в ATN, которые поддерживают протокол Евроконтроля для передачи сообщений о полете, используют TCP-порт № 8500.

1.4 ПРИЛОЖЕНИЯ В СВЯЗИ "ВОЗДУХ – ЗЕМЛЯ"

Диалоговое обслуживание 1.4.1 Диалоговое обслуживание (DS), которое рассматривается в части III документа Doc 9880, обеспечивает интерфейс между приложениями ATN и протоколами верхнего уровня ATN/OSI через функцию управления. В целях минимизации воздействия на приложения ATN было разработано диалоговое обслуживание для поддержки реализации приложений в ATN/IPS. В настоящем разделе рассматривается замена для интерфейса DS ATN/OSI с верхними слоями, именуемая IPS DS. 1.4.2 DS IPS соотносит примитивы TCP/UDP с интерфейсом DS приложения ATN, как показано на рис. II-1-1.

Рис. II-1-1. Схема верхних уровней ATN IPS

1.4.3 Соотношение примитивов DS в ATN/OSI подробно рассматривается в нижеследующих разделах. Такое соотношение используется в качестве замены для спецификации связного обслуживания верхнего уровня (ULCS) в части III документа Doc 9880.

Пользователь приложений

ATN-App ASE

TCP/UDP

IPS DS

Часть II. Приложения пакета протоколов Интернет (IPS) Глава 1. Введение II-1-3

1.4.4 Формат заголовка пакета сети авиационной электросвязи (ATNPKT), определяемый в пп. 1.4.11–1.4.15, описывает зарезервированный формат, предназначенный для передачи данных приложения ATN в сети ATN/IPS. С форматом заголовка ATNPKT можно использовать TCP или UDP.

Связь "диспетчер-пилот"по линии передачи данных (CPDLC), автоматическое зависимое наблюдение (ADS) и полетно-информационное обслуживание (FIS)

1.4.5 IPS-хосты, которые поддерживают приложения CPDLC, ADS и FIS в ATN/OSI, используют DS IPS вместо DS, которое определено в Doc 9880.

Управление контекстом (CM) 1.4.6 IPS-хосты, которые поддерживают приложение CM в ATN, поддерживают расширения абстрактно-синтаксической нотации (ASN), описанные в п. 1.4.39 части III настоящего документа. Примечание 1. Это позволяет передавать новую информацию адресации IPS, содержащуюся в обновленном приложении CM, с помощью абстрактно-синтаксической нотации, версия 1 (ASN.1). Примечание 2. Приложение CM называют также сервисом возможности инициализации линии передачи данных (DLIC). Примечание 3. Ожидается, что в следующее издание документа Doc 9880 будут включены те расширения, которые пользуются приоритетом перед указанными в настоящем документе.

Примитивы диалогового обслуживания ATN/IPS Примечание. В интересах унифицированности примитивы диалогового обслуживания IPS имеют те же наименования, что и примитивы диалогового обслуживания ULCS, описанные в документе Doc 9880. 1.4.7 IPS-узлы, которые поддерживают функцию DS, соблюдают параметры поведения, определяемые сервисными примитивами в таблицах II-1-1 и II-1-2.

Таблица II-1-1. Примитивы диалогового обслуживания

Сервис Описание

D-START Этот подтвержденный сервис используется для установления соединения между ведущими связь пользователями DS

D-DATA Этот неподтвержденный сервис используется пользователем DS для направления сообщения от этого пользователя DS одноранговому пользователю DS

D-END Этот подтвержденный сервис используется для обеспечения упорядоченного разъединения ведущих связь пользователей DS таким образом, чтобы любые транзитные данные были доставлены партнерам до разъединения


Сервис Описание

D-ABORT Этот неподтвержденный сервис можно задействовать для прекращения отношений между ведущими связь пользователями DS. Любые передаваемые транзитные данные могут быть утеряны

D-P-ABORT Этот неподтвержденный сервис используется для сообщения пользователю DS, что поставщик диалогового обслуживания прервал связь с одноранговым пользователем DS. Любые транзитные данные, передаваемые ведущими связь пользователями DS, могут быть утеряны

D-UNIT-DATA Этот неподтвержденный сервис используется для направления одного элемента данных от одного однорангового пользователя DS другому. О любых проблемах с доставкой этого элемента данных получателю отправителю сообщаться не будет. Этот сервис показан в таблице II-1-7

Таблица II-1-2. Параметры примитивов диалогового обслуживания

Сервис Параметры

D-START ID вызываемого пользователя ID вызываемой системы Представительский адрес вызываемого пользователя ID вызывающего пользователя ID вызывающей системы Представительский адрес вызывающего пользователя Номер версии пользователя DS Требования к защите Качество обслуживания Результат Источник отклонения Данные пользователя

D-DATA Данные пользователя

D-END Результат Данные пользователя

D-ABORT Инициатор Данные пользователя

D-P-ABORT (нет параметров)

Примечание. Параметры примитивов DS соотносятся с заголовком IP, полем заголовка протокола передачи или в качестве передаваемых данных в формате ATNPKT, определяемом в пп. 1.4.11–1.4.15.


Определение диалогового обслуживания Последовательность примитивов 1.4.8 IPS-узлы, которые поддерживают функцию DS, позволяют одноранговым пользователям DS при ведении связи: a) установить диалог; b) обмениваться данными пользователя; c) прекратить диалог штатным или нештатным образом; d) получить информацию о нештатном прекращении DS-диалога из-за отказа связи; e) последовательно применять соответствующие сервисные примитивы. 1.4.9 Каждый пользователь DS может направлять данные в любое время после первоначального обмена сообщениями D-START с помощью сервиса D-DATA. При нормальных обстоятельствах для окончания диалога пользователь DS использует функцию D-END. Для нештатного прекращения диалога используется функция D-ABORT. В случае нештатного прекращения диалога поставщиком обслуживания пользователей DS уведомляют с помощью сервисного сообщения D-P-ABORT. 1.4.10 Пользователь DS может передавать и получать примитивы для "диалога" только в последовательности, указанной в таблице II-1-3. Наличие "Y" в соответствующих ячейках таблицы указывает на действительные примитивы, которые могут следовать за заголовком колонки примитивов DS. Например, после примитива "D-END cnf" может следовать только "D-START ind".

Таблица II-1-3. Последовательность примитивов DS для одного диалога одного пользователя DS

Примитив DS → D-START D-DATA D-END D-ABORT D-P-ABORT

За ним может следовать DS-примитив Y req cnf ind Rsp req ind req cnf ind rsp req ind ind

1 D-START req

2 D-START cnf (принято) Y

3 D-START ind Y Y Y Y Y

4 D-START rsp (принято) 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 (принято) Y

9 D-END ind Y Y Y Y

10 D-END rsp (принято) 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


Формат ATNPKT 1.4.11 Цель ATNPKT – передавать информацию между одноранговыми пользователями DS во время обработки DS-примитива. Данный пакет содержится в элементе данных протокола передачи (TCP или UDP). Он используется для передачи параметров сервисных примитивов, которые не могут быть соотнесены с существующими полями IP или заголовка передачи. ATNPKT может также содержать информацию о функции протокола DS (например, о типе DS-примитива). 1.4.12 Для обеспечения наиболее эффективного использования ширины полосы применяется формат переменной длины. Формат переменной длины позволяет оптимизировать обработку примитива DS. Этот аспект играет важную роль при работе в узком диапазоне или при использовании дорогостоящих каналов связи "воздух –земля". 1.4.13 Формат ATNPKT состоит из двух частей: — фиксированная часть, которая присутствует независимо от примитива DS; — изменяемая часть для факультативных полей. 1.4.14 О наличии факультативных параметров свидетельствует установка битов в фиксированной части ATNPKT. Эти биты, именуемые "флагами присутствия", образуют "поле присутствия". Положение факультативного параметра в меняющейся части определяется его положением в поле присутствия. Формат ATNPKT показан на рис. II-1-2.

Рис. II-1-2. Формат ATNPKT

1.4.15 Представление факультативного параметра в изменяемой части ATNPKT будет зависеть от определения параметра. Параметры переменной длины будут представлены в формате LV (т. е. длина (Length) + значение (Value)). Параметры фиксированной длины будут представлены их значением. Поля ATNPKT 1.4.16 Для описания форматов полей ATNPKT используют условные обозначения (<биты>/ <провайдер>/<использование>): — <биты> указывает размер поля в битах (исключая длину для параметров LV); — <провайдер> указывает, что данное значение предоставляется пользователем DS в

качестве параметра примитива (внешнее) или присваивается поставщиком DS (внутреннее);

— <использование> указывает, предполагает ли пользователь DS представить значение

после инициирования соответствующего параметра примитива (факультативное или обязательное).

ВерсияATNPKT

ПримитивDS

больше

Флаги присутствия

Изменяемая часть24

Фиксированная часть 0 168

0

0 1 2 3 4 5 6 7 8 9 10 11


Фиксированная часть ATNPKT Версия ATNPKT Примечание. Версия ATNPKT указывает на версию заголовка ATNPKT. 1.4.17 Версия ATNPKT устанавливается на 1 и имеет формат 4 бита / внешнее / обязательное. Примечание 1. Версия ATNPKT представляет собой число, которое будет увеличиваться в результате последующих модификаций ATNPKT. Примечание 2. Резервирование четырех битов обеспечит до 15 версий. Примечание 3. Это поле не присутствует на уровне пользователя DS; его устанавливает поставщик DS Примитив DS Примечание. Поле примитива DS устанавливается поставщиком DS и указывает тип примитива DS в пакете. 1.4.18 Поле примитива DS имеет одно из указанных ниже значений и формат 4 бита / внутреннее / обязательное:

Значение Назначенный DS-примитив

1 D-START 2 D-START cnf 3 D-END 4 D-END cnf 5 D-DATA 6 D-ABORT 7 D-UNIT-DATA 8 D-ACK 9 D-KEEPALIVE

Примечание 1. Резервирование четырех битов даст возможность предусмотреть до 16 элементов протокола и определить до 7 дополнительных примитивов. Примечание 2. Сообщение D-P-ABORT не указано, т. к. оно не направляется в связи между конечными пользователями. После получения информации о нештатном событии или истечении допустимого времени бездействия абонент DS получит сообщение D-P-ABORT. Тип технологии приложения Примечание. Тип технологии приложения указывает на тип передаваемой прикладной информации. Другие приложения также могут использовать инфраструктуру IPS, например, FANS-1/A, ACARS и т. д.


1.4.19 Поле типа технологии приложения устанавливается на b000, что означает "ATN/IPS DS", и имеет формат 3 бита / внутреннее / факультативное. Примечание. Использование или определение других значений в настоящем руководстве не рассматривается. Бит "больше" Примечание. Бит "больше" будет использоваться при сегментации и сборе датаграмм UDP; он является частью механизмов надежности, более подробно рассматриваемых в п. 1.5.14. 1.4.20 Установка бита "больше" на 0 указывает единственный или последний сегмент; установка на 1 указывает первый или промежуточный сегмент; это поле имеет формат 1 бит / внутреннее / факультативное. Поле присутствия Примечание. Поле присутствия представляет собой серию флагов (или битов) присутствия, которые указывают, имеются ли факультативные поля в меняющейся части ATNPKT. 1.4.21 Поле присутствия имеет формат 12 бит / внутреннее / обязательное. 1.4.22 Установка флага присутствия на 0 указывает на отсутствие факультативного поля; его установка на 1 указывает на наличие факультативного поля. 1.4.23 Характеристики факультативного поля указаны в таблице II-1-4.

Таблица II-1-4. Характеристики поля присутствия

Бит

Факультативное поле

Размер (в битах)

Формат1

Описание

0 ID отправителя 16 V Идентификатор отправителя в DS-соединении

1 ID получателя 16 V Идентификатор получателя в DS-соединении

2 Порядковые номера 8 V Порядковые номера (Ns, Nr)

3 Время бездеятельности

8 V Значение времени бездеятельности отправителя (в минутах)

4 ID вызываемого абонента

24–64 (+8) LV2 ID вызываемого абонента (предоставляется местным абонентом DS)

5 ID вызывающего абонента

24–64 (+8) LV2 ID вызывающего абонента (предоставляется местным абонентом DS)

6 Версия содержания 8 V Версия передаваемых прикладных данных

7 Указатель защиты 8 V Требования к защите: 0 – защиты нет (значению по умолчанию) 1 – защита диалога с поддержкой управления ключами 2 – защита диалога 3 … 255 – зарезервировано


Бит

Факультативное поле

Размер (в битах)

Формат1

Описание

8 Качество обслуживания

8 V Класс маршрутизации ATSC: 0 – без предпочтений типа трафика 1 – "A" 2 – "B" 3 – "C" 4 – "D" 5 – "E" 6 – "F" 7 – "G" 8 – "H" 9 … 255 – зарезервировано

9 Результат 8 V Результат запроса об инициировании или прекращении диалога: 0 – принято (значение по умолчанию) 1 – отклонено временно 2 – отклонено постоянно 3 … 255 – зарезервировано

10 Инициатор 8 V Инициатор прерывания: 0 – пользователь (значение по умолчанию) 1 – провайдер 2 … 255 – зарезервировано

11 Данные пользователя

UDP: 0–8 1843 (+16) TCP: изменяемый размер (+16)

LV2 Данные пользователя (предоставляются местным пользователем DS)

Примечание 1. Факультативное поле присутствует в изменяемой части, если соответствующий бит установлен в поле присутствия и имеет один из следующих форматов: — V = значение; или — LV = длина (1 или 2 бит(а)) + значение Примечание 2. Количество дополнительных битов, требуемых для части длины параметров LV, указано в скобках (в битах) в третьей колонке таблицы II-1-4. Примечание 3. Более подробно вопрос о размере параметра данных пользователя рассматривается в п. 1.4.39. Изменяемые части ATNPKT Примечание. Изменяемые части ATNPKT будут предоставляться в зависимости от примитива DS и текущего состояния приложения, использующего IPS DS. 1.4.24 Положение факультативного поля в изменяемой части ATNPKT соответствует относительному положению соответствующего бита в поле присутствия (т. е. порядок факультативных полей соответствует порядку флагов присутствия).


ID источника Примечание. ID источника указывает соединение DS со стороны отправителя; оно является частью механизмов надежности, более подробно рассматриваемых в п. 1.5. 1.4.25 ID источника присутствует в примитивах D-START и D-START cnf, а также при передаче D-ABORT после D-START и до получения D-START cnf; оно имеет формат 16 бит / внутреннее / факультативное. ID назначения Примечание. ID назначения указывает на соединение со стороны получателя; это поле является частью механизмов надежности, более подробно рассматриваемых в п. 1.5. 1.4.26 ID назначения присутствует в примитивах D-START cnf, D-DATA, D-END, D-END cnf, D-ABORT, D-ACK и D-KEEPALIVE и имеет формат 16 бит / внутреннее / факультативное. Порядковые номера Примечание. Поле порядковых номеров содержит порядковые номера для включения в ATNPKT. Этот механизм используется для обнаружения утери и дублирования датаграмм UDP и обеспечивает косвенное (т. е. путем подтверждения обслуживания) или прямое подтверждение приема (D-ACK). Это поле является частью механизмов надежности, более подробно рассматриваемых в п. 1.5. 1.4.27 Поле порядковых номеров присутствует во всех примитивах DS при использовании UDP и имеет формат 8 бит / внутреннее / обязательное, как показано на рис. II-1-3.

Рис. II-1-3. Формат порядкового номера

N(S) - [0…15] — порядковый номер отправленного ATNPKT. N(R) - [0…15] — ожидаемый порядковый номер следующего ATNPKT для получения. Примечание. Для D-ACK и D-KEEPALIVE только N(R) имеет значение при передаче. 1.4.28 При использовании порядковых номеров с D-ACK и D-KEEPALIVE в режиме UDP можно использовать текущее значение направляемого порядкового номера для N(S) без его последующего увеличения после передачи. Время бездеятельности Примечание. Время бездеятельности указывает значение времени (в минутах) на таймере бездеятельности со стороны отправителя. Это поле является частью механизмов надежности, подробнее рассматриваемых в п. 1.5. 1.4.29 Поле времени бездеятельности факультативно присутствует в примитивах D-START и D-START cnf и имеет формат 8 бит / внутреннее / факультативное.

N(S) N(R)


1.4.30 Если этот параметр не предоставлен пользователем DS, провайдер DS использует значение таймера бездеятельности по умолчанию в 4 минуты. ID вызываемого абонента Примечание. ID вызываемого абонента идентифицирует предполагаемого однорангового пользователя DS. 1.4.31 ID вызываемого абонента представляет собой 24-битовый идентификатор воздушного судна ИКАО или 3–8-значное условное обозначение средства ИКАО и имеет формат 24–64 бит / внешнее / факультативное. ID вызывающего абонента Примечание. ID вызывающего абонента идентифицирует инициирующего связь однорангового пользователя DS. 1.4.32 ID вызывающего абонента представляет собой 24-битовый идентификатор воздушного судна ИКАО или 3–8-значное условное обозначение средства ИКАО и имеет формат 24–64 бит / внешнее / факультативное. Версия содержания Примечание. Поле версии содержания используется для указания номера версии приложения. 1.4.33 Версия содержания указывает версию синтаксиса ASN.1, используемого в поле данных абонента, и имеет формат 8 бит / внешнее / факультативное. Указатель защиты Примечание 1. Параметр указателя защиты используется для сообщения об уровне защиты, которым обеспечивается диалог. В документе Doc 9880 это поле названо "требования к защите", но в настоящем документе использовано иное название, так слово "требования" в данном случае неприменимо. Скорее, речь идет об информации от местного пользователя DS о том, какая процедура защиты будет применяться при установлении диалогового обмена. 1.4.34 Поле указателя защиты имеет одно из перечисленных ниже значений и формат 8 бит / внешнее / факультативное:

Значение Уровень защиты

0 Защиты нет (значение по умолчанию)

1 Защита диалога с поддержкой управления ключами

2 Защищенный диалог

3–255 Зарезервировано


Примечание. В отсутствие этого параметра со стороны пользователя DS уровень защиты устанавливается на значение по умолчанию, т. е. защита не обеспечивается. Качество обслуживания Примечание. Параметр качества обслуживания (QoS) информирует о требованиях пользователя DS к качеству обслуживания, и его значение соответствует классам маршрутизации ATSC и/или коэффициенту необнаруженных ошибок (RER). 1.4.35 Параметр QoS имеет одно из перечисленных ниже значений и формат 8 бит / внешнее / факультативное: 1. Предоставленный пользователем DS класс маршрутизации ATSC, как показано ниже:

Значение Описание класса маршрутизации ATSC

0 Без предпочтений по типу трафика

1 "A"

2 "B"

3 "C"

4 "D"

5 "E"

6 "F"

7 "G"

8 "H"


2. RER, как показано ниже:

Значение Уровень RER

0 Низкий

1 Средний

2 Высокий

3. Приоритет приложений ATN можно указать путем добавления в заголовок IPv6 значений

точки кода дифференцированных услуг (DSCP), о чем говорится в пп. 1.5.9 и 1.5.10 части III настоящего документа.

Примечание. Приоритет обычно устанавливается сетевым уровнем, и поэтому у приложения нет необходимости его устанавливать. Сетевой уровень может определить приоритет по номеру используемого порта или IP-адреса и соответственно установить поле дифференцированного обслуживания. Следует также учитывать, что процедуры управления сетью могут потребовать изменения маркировки пакета вне зависимости от первоначально указанных приложений для приведения в соответствие с местными определениями сетевого дифференцированного обслуживания.


1.4.36 Функция контрольных сумм в режиме UDP может быть задействована при малых или средних значениях RER и не задействована при высоких значениях RER. Примечание. Функция контрольных сумм в режиме TCP всегда задействуется. Контрольные суммы UDP задействуются по умолчанию. Результат Примечание. Поле результат устанавливается пользователем DS в пункте назначения с целью сообщить, были ли успешно выполнено запрошенное инициирование или прекращение диалога. 1.4.37 Поле результата имеет формат 8 бит / внешнее / обязательное и одно из перечисленных ниже значений:

Значение Определение

0 Принято

1 Отклонено (временно)

2 Отклонено (постоянно)


Инициатор Примечание. Поле инициатора сообщает об источнике D-ABORT. 1.4.38 Поле инициатора имеет одно из указанных ниже значений и формат 8 бит / внешнее / факультативное:

Значение Определение

0 Пользователь (по умолчанию)

1 Провайдер

2–255 Зарезервировано Примечание. Если пользователь DS не предоставил этого параметра, принимается значение по умолчанию. Данные пользователя Примечание. Поле данных пользователя содержит информацию о применяемых правилах уплотненного кодирования (PER). 1.4.39 Поле данных пользователя имеет формат для UDP: 0–8184, для TCP: изменяемый размер / внешнее / факультативное


Примечание 1. Максимальным размером поля данных пользователя для сервиса D-DATA является максимальный размер датаграммы UDP (8192 бит) минус размер заголовка ATNPKT (8 бит). Для других сервисных примитивов максимальный размер поля данных пользователя необходимо корректировать в зависимости от размера части фиксированного заголовка и размера частей изменяемой длины для данного конкретного сервисного примитива. Примечание 2. IPS DS будет сегментировать датаграммы UDP с данными пользователя, размер которых превышает 1024 бит, о чем говорится в п. 1.5.14, для последующей сборки получателем. Соотношение параметров IPS DS Примечание. IPS DS представляет идентичный интерфейс ULCS с приложениями ATN. Сами параметры IPS DS идентичны параметрам ULCS, однако соотношение между содержанием этих параметров различается. Сводные данные измененных соотношений приведены в таблице II-1-5, а по каждому примитиву в таблице II-1-7.

Таблица II-1-5. Соотношение параметров IPS DS — ULCS DS

Параметр DS, видимый для

пользователя DS Заголовок IP

Заголовок протокола передачи

ATNPKT (см. таблицу II-1-4) Комментарий

ID вызываемого абонента

ID вызываемого абонента

Это может быть 24-битовый адрес воздушного судна ИКАО или условное обозначение средства ИКАО (4–8 знаков)

ID вызываемой системы

Номер порта назначения

Это зарегистрированный номер порта, присваиваемый каждому приложению ATN (см. п. 1.5.4)

Вызываемый представительский адрес

IP-адрес пункта назначения

IP-адрес приложения ATN получателя

ID вызывающего абонента

ID вызывающего абонента

Это может быть 24-битовый адрес воздушного судна ИКАО или условное обозначение средства ИКАО (4–8 знаков)

ID вызывающей системы

Номер порта отправителя

При использовании TCP этот номер порта динамически присваивается стеком протоколов передачи клиента. При использовании UDP этот номер порта обычно имеет статическое значение, которое соответствует номеру порта получателя

Представительский адрес вызывающего абонента

IP-адрес отправителя

IP-адрес приложения ATN инициатора

Номер версии пользователя DS

Версия содержания

Это номер версии приложения


Параметр DS, видимый для

пользователя DS Заголовок IP

Заголовок протокола передачи

ATNPKT (см. таблицу II-1-4) Комментарий

Требования к защите

Требования к защите

00 – Защита не обеспечивается 01 – Защищенный диалог с поддержкой управления ключами 02 – Защищенный диалог 03 – Зарезервирован

Качество обслуживания

Качество обслуживания

Этот параметр следует передавать только тогда, когда предоставляется "класс маршрутизации ATSC"; RER и приоритет не указываются конечными пользователями, а факультативно указываются IPS DS и используются локально

Результат Результат 00 – Принято 01 – Отклонено (постоянно) 02 – Отклонено (временно)

Источник отклонения

00 – Удаленный DS-пользователь 01 – Локальный DS-провайдер Предоставляется локально только в примитиве подтверждения; не передается между конечными пользователями

Инициатор Инициатор 0 – Пользователь 1 – Провайдер (по умолчанию) 2-255 – Зарезервировано

Данные пользователя

Данные пользователя

Это данные о правилах уплотненного кодирования (PER) , предоставленные приложением

1.4.40 Включение факультативных параметров ATNPKT для каждого сообщения DS-протокола производится в соответствии с таблицей II-1-6.


Таблица II-1-6. Параметры ATNPKT для сообщений DS-протокола (O = факультативный, M = обязательный, – = не используется) (1) ID источника присутствует, если D-ABORT посылается после D-START, но до получения D-START cnf. (2) ID получателя отсутствует, если D-ABORT направляется после D-START, но до получения D-START cnf. (3) В сегментированных сообщениях этот параметр присутствует только в первом сегменте. (4) В сегментированных сообщениях этот параметр присутствует во всех сегментах.

Протокольное сообщение D-START D-START cnf D-DATA

D-UNIT-DATA D-END D-END cnf D-ABORT D-ACK

D-KEEPALIVE

Фиксированная часть

Версия ATNPKT M M M M M M M M M

Примитив DS M M M M M M M M M

Тип прикладной технологии M M M M M M M M M

Больше O O O O O

Флаг присутствия M M M M M M M M M

Изменяемая часть

ID отправителя M (4) M (4) – – – – (1) – –

ID получателя – M (4) M (4) M (4) M (4) M (2) M M

Порядковые номера M (4) M (4) M (4) M M (4) M (4) M M M

Время бездеятельности O (3) O (3) – – – – – – –

ID вызываемого абонента O (3) – – O – – – – –

ID вызывающего абонента O (3) – – O – – – – –

Версия содержания O (3) O (3) – O – – – – –

Индикатор защиты O (3) O (3) – O – – – – –

Качество обслуживания O (3) – – – – – – – –

Результат – M (3) – – – M (3) – – –

Инициатор – – – – – – O – –

Данные пользователя O (4) O (4) M (4) M O (4) O (4) O – –

Примитивы диалогового обслуживания Примечание. Для предоставления услуг, указанных в п. 1.4.7, используются примитивы, перечисленные в таблице II-1-7. Каждый примитив может непосредственно передаваться пользователю DS (примитивы запроса/ответа) или сообщаться пользователю DS провайдером DS (примитивы сообщения/ подтверждения).


Таблица II-1-7. Данные о примитивах диалогового обслуживания

Примитив интерфейса Описание диалогового сервиса DS-

пользователь DS-

провайдер

D-START req Запрашивает установление диалога с одноранговым DS-пользователем

D-START ind Информирует местного DS-пользователя о том, что одноранговый DS-пользователь запросил установление диалога

D-START rsp Завершает запрошенное инициирование диалога положительным или отрицательным ответом

D-START cnf Информирует местного DS-пользователя о том, что одноранговый DS-пользователь завершил запрошенное инициирование диалога положительным или отрицательным ответом

D-UNIT-DATA req Отправляет датaграмму от местного DS-пользова-теля одноранговому DS-пользователю (доставка датаграммы в конечный пункт не гарантируется)

D-UNIT-DATA ind Информирует местного DS-пользователя о том, что получена датаграмма от однорангового DS-пользователя

D-DATA req Отправляет датaграмму от местного DS-пользователя одноранговому DS-пользователю во время установленного диалога

D-DATA ind Информирует местного DS-пользователя о том, что от однорангового DS-пользователя получена датаграмма во время установленного диалога

D-END req Запрашивает прекращение диалога с одноранговым DS-пользователем

D-END ind Информирует местного DS-пользователя о том, что одноранговый DS-пользователь запросил прекращение диалога

D-END rsp Завершает запрошенное прекращение диалога положительным или отрицательным ответом

D-END cnf Информирует местного DS-пользователя о том, что одноранговый DS-пользователь завершил запрошенное прекращение диалога положительным или отрицательным ответом

D-ABORT req Запрашивает прерывание диалога с одноранговым DS-пользователем

D-ABORT ind Информирует местного DS-пользователя о том, что одноранговый DS-пользователь запросил прерывание диалога

D-P-ABORT ind Диалог прерван DS-провайдером


Диаграммы времени-последовательности диалогового обслуживания 1.4.41 Приведенные ниже рис. с II-1-4 по II-1-13 иллюстрируют протокольные обмены диалогового обслуживания между DS-провайдерами пунктов отправления и назначения, включая часть данных пользователя ATNPKT.

Рис. II-1-4. Сервис D-START

Рис. II-1-5. Сервис D-DATA (TCP)

D-START ответ

D-START индикация

D-START запросD-START

Диалоговый сервис

D-START cnf

D-START подтверждение

D-DATA индикация

D-DATA запросD-DATA



Рис. II-1-6. Сервис D-DATA (UDP)

Примечание. На рис. II-1-5 показан сервис D-DATA при использовании TCP. В связи с характером такого соединения примитив ACK не требуется. На рис. II-1-6 показан сервис D-DATA при использовании UDP. Для прямого подтверждения получения UDP-пакета получатель D-DATA ATNPKT возвращает D-ACK.

Рис. II-1-7. Сервис D-END

D-ACK ответ

D-DATA индикация

D-DATA запросD-DATA


D-ACK

D-ACK подтверждение

D-END ответ

D-END индикация

D-END запросD-END


D-END cnf

D-END подтверждение


Рис. II-1-8. Сервис D-ABORT

Рис. II-1-9. Сервис D-P-ABORT

Примечание. Формат ATNPKT для сервиса D-P-ABORT не определен, т. к. это местная индикация DS-пользователю.

Рис. II-1-10. Сервис D-UNIT-DATA (TCP)

D-ABORT индикация

D-ABORT запросD-ABORT



D-P-ABORT индикация D-P-ABORT индикация

D-UNIT-DATA индикация

D-UNIT DATA запросD-UNIT-DATA



Рис. II-1-11. Сервис D-UNIT-DATA (UDP)

Примечание. На рис. II-1-10 показан сервис D-UNIT-DATA при использовании TCP. В связи с характером такого соединения примитив ACK не требуется. На рис. II-1-11 показан сервис D-UNIT-DATA при использовании UDP. Для прямого подтверждения получения UDP-пакета получатель D-UNIT-DATA ATNPKT возвращает D-ACK.

Рис. II-1-12. Сервис D-ACK

Рис. II-1-13. Сервис D-KEEPALIVE

D-ACK запрос

D-UNIT-DATA индикация

D-UNIT-DATA запросD-UNIT-DATA


D-ACK

D-ACK индикация

D-ACK индикация

D-ACK запросD-ACK


D-KEEPALIVE индикация

D-KEEPALIVE запросD-KEEPALIVE



1.5 ТРАНСПОРТНЫЙ УРОВЕНЬ

Обзор 1.5.1 IPS DS позволяет пользователю выбрать в качестве транспортного протокола TCP или UDP. Для упрощения связанные с портами операции не рассматриваются как примитивы. 1.5.2 Примитивы транспортного уровня приведены в таблице II-1-8.

Таблица II-1-8. Примитивы транспортного уровня, используемые в IPS DS

Транспортный уровень

Примитив интерфейса

Описание TCP UDP

OPEN Установление соединения (именуемое "активное" со стороны инициатора и "пассивное" с другой стороны)

CLOSE Прекращение соединения (именуемое "активное" со стороны инициатора и "пассивное" с другой стороны)

RECEIVE Получить датаграмму транспортного уровня

SEND Направить датаграмму транспортного уровня

1.5.3 На таблице II-1-9 показано соотношение между диалоговым сервисом и примитивами транспортного уровня.

Таблица II-1-9. Соотношение примитивов транспортного уровня с сервисами IPS DS

Диалоговый сервис Транспортный уровень

Сервис Примитив интерфейса Примитив интерфейса Данные пользователя

Протокол

Инициализация

OPEN (пассивное) TCP

Установление диалога

D-START D-START req OPEN (активное) TCP

SEND D-START TCP, UDP

D-START ind RECEIVE D-START

D-START rsp SEND D-START cnf

D-START cnf RECEIVE D-START cnf

Обмен данными без соединения

D-UNIT-DATA D-UNIT-DATA req SEND D-UNITDATA UDP

D-UNIT-DATA ind RECEIVE D-UNITDATA


Диалоговый сервис Транспортный уровень

Сервис Примитив интерфейса Примитив интерфейса Данные пользователя

Протокол

Обмен данными в режиме соединения

D-DATA D-DATA req SEND D-DATA TCP, UDP

D-DATA ind RECEIVE D-DATA

Упорядоченное прекращение диалога (по инициативе пользователя)

D-END D-END req SEND D-END TCP, UDP

D-END ind RECEIVE D-END

D-END rsp SEND D-END cnf

CLOSE (пассивное) TCP

D-END cnf RECEIVE D-END cnf TCP, UDP

CLOSE (активное) TCP

Вынужденное прекращение диалога (по инициативе пользователя)

D-ABORT D-ABORT req SEND D-ABORT TCP, UDP

CLOSE (активное) TCP

D-ABORT ind RECEIVE D-ABORT TCP, UDP

CLOSE (пассивное) TCP

Связанное с ошибкой прекращение диалога (по инициативе провайдера)

D-P-ABORT D-P-ABORT ind RECEIVE / SEND (отказ) TCP, UDP

Unexpected CLOSE (пассивное)

TCP

Номера портов

1.5.4 Указанные ниже номера портов TCP и UDP используются для обеспечения поддержки устаревших приложений ATN в ATN/IPS: 5910 Управление контекстом 5911 Связь "диспетчер-пилот" по линии передачи данных 5912 Полетно-информационное обслуживание 5913 Автоматическое зависимое наблюдение Примечание. Эти номера портов зарегистрированы Администрацией адресного пространства Интернет (IANA) по адресу: http://www.iana.org/assignments/port-numbers

Предоставление диалогового обслуживания с использованием UDP Примечание. UDP в основном используется для приложений, требующих широковещательной или многоадресной пересылки, но может также использоваться с простыми приложениями типа "запрос-ответ"


при условии обеспечения дополнительной надежности на самых высоких уровнях. UDP не гарантирует сквозного обслуживания по доставке датаграмм. Поэтому IPS DS использует дополнительные механизмы для компенсации недостатков UDP, связанных главным образом с усечением, утерей или дублированием датаграмм UDP. Подробнее об этих механизмах говорится в нижеследующих пунктах. 1.5.5 Для повышения надежности при работе с UDP DS-провайдер использует механизмы, описанные в таблице II-1-10.

Таблица II-1-10. Механизмы надежности IPS DS UDP

(O = факультативно, M = обязательно)

Обеспечение "диалогового соединения" через UDP — идентификация соединений — блокировка по времени при соединении — блокировка по времени при прекращении

M O O

Обнаружение утери UDP-датаграмм с помощью подтверждений по методу "один к одному" (на базе соединений) — таймер повторной передачи + учет количества повторных попыток — прямое подтверждение — подтверждение в обратном сообщении (максимальная задержка

подтверждения)

M M O

Обнаружение длительных непарных соединений — таймер бездеятельности + таймер поддержания соединения при

передаче M

Действия в случае усечения UDP-датаграмм — сегментация / сборка датаграмм M

ID соединений 1.5.6 Пара ID соединений – ID отправителя и ID получателя – присваивается на этапе соединения (D-START / D-START cnf) каждым участвующим абонентом DS и используется в последующих обменах. Примечание 1. Идентификация DS-соединения выше уровня UDP будет осуществляться путем присвоения такой пары ID соединений. Примечание 2. Двухбитовый размер для таких идентификаторов выбран потому, что это позволит DS-провайдеру ассоциировать конкретную семантику с диалоговым ID, присвоенным с его стороны (без помех для участвующего однорангового пользователя DS). В таком случае идентификатором может быть индекс в таблице контекстов, что сделает его косвенно однозначным, но также позволит принимающему DS-провайдеру определить контекст, не прибегая к использованию критериев множественного поиска и просмотру всей таблицы контекстов.


1.5.7 ID отправителя и ID адресата передаются в изменяемой части пакета ATNPKT на основе примитивов DS, как показано в таблице II-1-11.

Таблица II-1-11. Использование ID отправителя и ID адресата (O = факультативно, M = обязательно)

Поле примитива DS ID отправителя ID адресата

D-START M Идентификатор, присво-енный DS-провайдером, инициировавшим диалог; он позволит пользователю определять контекст диалога на всем протяжении диалога

– В данное время не присвоен

D-START cnf M Идентификатор, присво-енный DS-провайдером, который принимает диалог; он позволяет провайдеру определять контекст диалога на всем протяжении диалога

M Идентификатор DS-провайдера, который инициировал диалог

D-DATA – Нет необходимости передавать его, поскольку он не имеет смысла для DS-провайдера адресата

M Идентификатор DS-провайдера абонента

D-END –- Нет необходимости передавать его, поскольку он не имеет смысла для DS-провайдера адресата


D-END cnf – Нет необходимости передавать его, поскольку он не имеет смысла для DS-провайдера адресата


D-ABORT до получения D-START cnf

M Идентификатор, присво-енный DS-провайдером, который инициировал диалог

– Пока неизвестен

D-ABORT другие случаи – Нет необходимости передавать его, поскольку он не имеет смысла для DS-провайдера адресата


Обнаружение потерянных датаграмм Примечание 1. Для обнаружения потери UDP-датаграмм используется механизм подтверждения по методу "один к одному" на основе DS-соединений, т. е. отправление одного пакета данных и получение одного подтверждения, прежде чем отправлять последующие данные.


Примечание 2. Подтверждение может быть включено в диалоговое сообщение в обратном направлении; это может делаться, например, при подтверждении примитивов. 1.5.8 Для неподтвержденных DS-сервисов принимающий пользователь использует прямое подтверждение, отправляя ATNPKT без данных и с D-ACK в качестве "DS-примитива". Примечание 1. Для целей подтверждения будет использоваться поле "порядковых номеров" в изменяемой части ATNPKT. Примечание 2. Этот порядковый номер требуется для того, чтобы избежать доставки дублированных данных DS-пользователю после повторной передачи (т. е. в случае потери D-ACK), а также в более исключительных обстоятельствах, т. е. когда датаграммы UDP доставляются сетью вне очереди. 1.5.9 DS-провайдер увязывает возрастающий порядковый номер с исходящими ATNPKT и сохраняет порядковый номер последнего ATNPKT, полученного от DS-провайдера абонента, для подтверждения его в последующей передаче. 1.5.10 Исходящие и входящие порядковые номера передаются, соответственно, в подполях N(S) и N(R) поля "порядковые номера". Примечание 1. N(S) соответствует текущему порядковому номеру направленного ATNPKT; N(R) является ожидаемым порядковым номером следующего ATNPKT, который будет получен. Примечание 2. Использование порядковых номеров позволит DS-провайдеру обнаружить недостающие или дублируемые ATNPKT. Может быть не более одного неподтвержденного ATNPKT; по этой причине не используется групповое подтверждение и нет необходимости вводить механизм селективного отказа. Примечание 3. Отсутствие своевременного подтверждения повлечет за собой повторную передачу. В случае чрезмерного количества повторных передач DS-соединение будет прервано. Значения таймаута и максимального количества повторных передач указаны в таблице II-1-12.

Таймаут соединения Примечание. Для того чтобы избежать продолжительных непарных DS-соединений, используется простой механизм обнаружения бездеятельности. После срабатывания таймера "поддержки соединения" с обоих концов DS–соединения будет передаваться пакет поддержки соединения. Таймер поддержки соединения устанавливается отправителем при каждом отправлении данных, с тем чтобы избежать ненужной передачи сообщений поддержки. 1.5.11 Сообщение о поддержке соединения (ATNPKT без данных и со значением D-KEEPALIVE как DS-примитив) направляется каждый раз после срабатывания местного таймера передачи сообщений о поддержке соединения. 1.5.12 Таймер направления сообщения о поддержке соединения может устанавливаться на 1/3 установки таймера бездеятельности DS-провайдера абонента или 1/3 установки таймера бездеятельности по умолчанию. Примечание. В случае неполучения пакета данных или пакета поддержки соединения в течение периода времени, соответствующего периоду бездеятельности, DS-соединение будет прервано. Значения этого периода указаны в таблице II-1-12.


1.5.13 Факультативное поле ATNPKT "время бездеятельности" можно использовать во время инициализации диалога (т. е. при передаче D-START и D-START cnf), с тем чтобы каждый DS-провайдер мог скорректировать свой локальный таймер передачи сообщений о поддержке соединения. Примечание. Отсутствие параметра времени бездеятельности указывает на использование значения времени бездеятельности по умолчанию согласно таблице II-1-12.

Индикатор "больше" Примечание. Длина большинства прикладных сообщений ATN не превышает 1000 байтов. Кроме того, предлагаемое значение 1024 байта не превышает объема полезной IP-нагрузки (1500 байтов) в кадре Ethernet (1518 байтов). 1.5.14 Сообщение D-DATA с объемом части данных пользователя, превышающим 1024 байта, сегментируется с помощью бита "больше", резервируемого в фиксированной части ATNPKT. Примечание. После получения сообщения D-DATA с установленным битом "больше" принимающая сторона несет ответственность за упорядочение и сборку сегментированных данных.

Параметры DS-провайдера 1.5.15 Значения, установленные в таблице II-1-12, применяются в отношении указанных в ней параметров DS-провайдера.

Таблица II-1-12. Параметры DS-провайдера

Параметр Минимум Максимум По умолчанию

Задержка до повторной передачи 1 с 60 с 15 с

Максимальное число передач 1 10 3

Время бездеятельности 3 мин 15 мин 4 мин


1.6 ТАБЛИЦЫ СОСТОЯНИЯ IPS-ДИАЛОГОВОГО СЕРВИСА (DS)

Таблица II-1-13. Таблица состояний IPS DS для TCP

События Состояние

D-IDLE D-CONNECTED D-START-SENT D-START-RECEIVED D-TRANSFER D-END-SENT

D-END-RECEIVED

D-WAIT-CLOSE

На этапе инициализации

OPEN (пассивное)

Собы

тия D

S-пользователя

D-START req OPEN (активное) - увязать D-START req с D-START - SEND (D-START) - ввести состояние D-START-SENT

D-START rsp Увязать D-START cnf с D-START cnf - SEND (D-START cnf) – в случае положительного ответа: - начать tinact - ввести состояние D-TRANSFER – в противном случае: -ввести состояние D-WAIT-CLOSE

D-DATA req Увязать D-DATA req с D-DATA - SEND (D-DATA)

D-END req Отменить tinact - увязать D-END req с D-END - SEND (D-END) - ввести состояние D-END-SENT

D-END rsp Увязать D-END rsp с D-END cnf - SEND (D-END cnf) - в случае положительного ответа: - ввести состояние D-WAIT-CLOSE – в противном случае: - начать tinact - ввести состояние D-TRANSFER

D-ABORT req Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-WAIT-CLOSE

Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-WAIT-CLOSE

Отменить tinact - увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-WAIT-CLOSE



Собы

тия

TCP OPEN

(пассивное) завершено

Ввести состояние D-CONNECTED




D-END-RECEIVED

D-WAIT-CLOSE



RECEIVE (D-START)

Увязать D-START с D-START ind - сообщить D-START ind DS-пользователю - ввести состояние D-START-RECEIVED

RECEIVE (D-START cnf)

Увязать D-START cnf с D-START cnf - сообщить D-START cnf DS-пользователю – в случае положи-тельного ответа: - начать tinact – ввести состояние D-TRANSFER - в противном случае: - CLOSE (активное) –ввести состояние D-IDLE

RECEIVE (D-DATA)

Переустановить tinact - увязать D-DATA с D-DATA ind - сообщить D-DATA ind DS-пользователю

RECEIVE (D-END)

Отменить tinact - увязать D-END с D-END ind - сообщить D-END ind DS-пользователю - ввести состояние D-END-RECEIVED

RECEIVE (D-END cnf)

Увязать D-END cnf с D-END cnf – сообщить D-END cnf DS-пользова-телю – в случае положительного ответа: - CLOSE (активное) - ввести состояние D-IDLE - в противном случае: - начать tinact - ввести состояние D-TRANSFER




D-END-RECEIVED

D-WAIT-CLOSE



Собы

тия T

CP

RECEIVE (D-ABORT)

Увязать D-ABORT с D-ABORT ind -сообщить D-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE

Отменить tinact - увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE

Увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE

Увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE

CLOSE (пассивное)

CLOSE (активное) - ввести состояние D-IDLE

Сообщить D-P-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE


Отменить tinact - сообщить D-P-ABORT ind DS-пользователю - CLOSE (активное) - ввести состояние D-IDLE



CLOSE (активное) – ввести состояние D-IDLE

Собы

тия D

S-провайдера

tinact срабатывает

Сообщить D-P-ABORT ind DS-пользователю - ввести состояние D-IDLE

Таблица II-1-14. Таблица состояний IPS DS для UDP


D-IDLE D-START-SENT D-START-RECEIVED D-TRANSFER D-END-SENT D-END-RECEIVED

Собы

тия D

S-пользователя

D-START req Увязать D-START req с D-START - SEND (D-START) - установить tconnect – ввести состояние D-START-SENT

D-START rsp Увязать D-START cnf с D-START cnf - SEND (D-START cnf) - в случае положительного ответа: - запустить tinact – ввести состояние D-TRANSFER - в про-тивном случае: -ввести состояние D-IDLE

D-DATA req Увязать D-DATA req с D-DATA - SEND (D-DATA)

D-END req Отменить tinact -увязать D-END req с D-END - SEND (D-END) – запус-




тить tterm - ввести состояние D-END-SENT

D-END rsp Увязать D-END rsp с D-END cnf - SEND (D-END cnf) – в случае положитель-ного ответа: - ввести состояние D-IDLE – в противном случае: - запустить tinact – ввести состояние D-TRANSFER

D-ABORT req Отменить tconnect -увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-IDLE

Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) – ввести состояние D-IDLE

Отменить tinact - Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-IDLE

Отменить tterm - Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-IDLE

Увязать D-ABORT req с D-ABORT - SEND (D-ABORT) - ввести состояние D-IDLE

Собы

тия U

DP

RECEIVE (D-START)

Увязать D-START с D-START ind – сооб-щить D-START ind DS-пользователю - ввести состояние D-START-RECEIVED

RECEIVE (D-START cnf)

Отменить tconnect -увязать D-START cnf с D-START cnf – сообщить D-START cnf DS-пользователю - в случае положительного ответа: запустить tinact - ввести состояние D-TRANSFER – в про-тивном случае: - ввести состояние D-IDLE

RECEIVE (D-DATA) Переустановить tinact - увязать D-DATA с D-DATA ind - сообщить D-DATA ind DS-пользователю

RECEIVE (D-END) Отменить tinact -увязать D-END с D-END ind - сообщить D-END ind DS-пользователю - ввести состояние D-END-RECEIVED

RECEIVE (D-END cnf)

Отменить tterm -увязать D-END cnf с D-END cnf - сообщить D-END cnf DS-пользователю – в случае положительного ответа: - ввести состояние D-IDLE – в противном случае: - запустить tinact - ввести состояние D-TRANSFER

RECEIVE (D-ABORT)

Увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю - ввести состояние

Отменить tinact - увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю -

Отменить tterm - увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю -

Увязать D-ABORT с D-ABORT ind - сообщить D-ABORT ind DS-пользователю - ввести состояние D-




D-IDLE ввести состояние D-IDLE

ввести состояние D-IDLE

IDLE

Собы

тия D

S

Срабатывание tconnect

Сообщить D-P-ABORT ind DS-пользователю - ввести состояние D-IDLE

Срабатывание tinact Сообщить D-P-ABORT ind DS-пользователю - ввести состояние D-IDLE

Срабатывание tterm Сообщить D-P-ABORT ind DS-пользователю - ввести состояние D-IDLE

______________________

Часть III

Инструктивный материал

III-1-1

ГЛАВА 1 ВВЕДЕНИЕ

1.1 ОБЩИЙ ОБЗОР

1.1.1 В данной части руководства содержится информация, призванная помочь Договаривающимся государствам ИКАО в применении ATN/IPS для поддержки служб организации воздушного движения (ОрВД). Ниже перечислены минимальные базовые виды обслуживания, которые должны предоставляться сетью ATN/IPS. 1.1.2 Эти базовые виды обслуживания позволяют приложениям ATN обеспечивать речевую связь и передачу данных с использованием соответствующих приоритетов и средств защиты в сети ATN/IPS. 1.1.3 Протоколы, рассматриваемые в настоящем документе, основанные на эталонной модели взаимодействия открытых систем (OSI). На рис. III-1-1 показана взаимосвязь между OSI, ATN/OSI и протоколами ATN/IPS, использующими 4-уровневую модель IETF.

Рис. III-1-1. Эталонная модель протоколов

Прикладнойуровень 7

Сеансовый уровень 5

Транспортныйуровень 4

Сетевой уровень 3

Канальный уровень 2

Физический уровень 1

Представительскийуровень 6

Эталонная модель OSI

Протоколы ATN/ISO ATN/IPS

Fast-byte

Fast-byte

Приложения например,

ATN( CMIP, X.400)

Транспортный уровенькласс 4

LLC/MAC

Ipv6 ICMPv6и

TCP/UDP

Объединенныеприкладныесервисынапример,

и

( SMTP,SNMPv3,FTP, X.400

Telnet)

LAP B (HDLC)

Физический уровеньнапример,( EIA-232,

V.35, X.21)

Физический уровеньнапример,( FDDI, 802.X)

SNDCF

ES-IS/CLNP

X.25 PLP

III-1-2 Руководство по ATN, использующей стандарты и протоколы IPS

1.2 ИСХОДНАЯ ИНФОРМАЦИЯ Сеть ATN/IPS создается с конкретной целью предоставления глобального обслуживания ОрВД на основе серийных коммерческих технологий. В соответствии со Стандартами и Рекомендуемой практикой (SARPS) ИКАО обслуживание ATN может предоставляться с использованием основанных на стандартах ИСО протоколах ИКАО, как указывается в Doc 9705 и Doc 9880 или в настоящем руководстве. В данном руководстве описан технический подход к организации сети на основе IPS, которая позволит Договаривающимся государствам предоставлять обслуживание ОрВД.

1.3 ОБЩИЕ РЕКОМЕНДАЦИИ 1.3.1 Данный раздел содержит информацию об использовании ATN/IPS для приложений ATN, многоадресной передачи и VoIP.

ATN/IPS

Объединенная сеть ATN/IPS 1.3.2 Конкретным и исключительным предназначением объединенной сети ATN/IPS является обеспечение услугами передачи данных организаций, предоставляющих обслуживание воздушного движения (ОВД), и авиационных эксплуатационных агентств в поддержку следующих типов связи: — связь в целях ОВД (ATSC). Связь, относящаяся к обслуживанию воздушного движения,

включая управление воздушным движением, аэронавигационную и метеорологическую информацию, донесения о местоположении и обслуживание, связанное с безопасностью и регулярностью полетов. В такой связи участвуют одна или несколько администраций обслуживания воздушного движения;

— авиационный оперативный контроль (AOC). Связь, необходимая для осуществления

полномочий в отношении начала, продолжения, изменения или прекращения полета, исходя из интересов обеспечения безопасности, регулярности и эффективности полетов;

— авиационная административная связь (AAC). Связь, используемая авиационными

эксплуатационными агентствами в отношении коммерческих аспектов осуществления полетов и предоставления транспортного обслуживания. Такая связь используется с разнообразными целями, включая летную и наземную транспортировку, бронирование, доставку экипажей и воздушных судов или выполнение любых других логистических задач в целях поддержания или повышения эффективности летной работы в целом.

1.3.3 В целях обеспечения этих типов связи в настоящем руководстве оговаривается ряд технических и административных требований для объектов, составляющих объединенную сеть ATN/IPS. См. рис. III-1-2. 1.3.4 Технические требования в настоящем руководстве относятся к маршрутизатору IPS, хосту IPS или узлу IPS, когда соответствующее требование относится к обоим. В руководстве принято определение IPS из RFC 2460, согласно которому узел IPS – это устройство, которое использует IPv6, и проводится различие между маршрутизатором IPS как узлом, который пересылает IP-пакеты другим, и хостом IPS как узлом, который не является маршрутизатором.

Часть III. Инструктивный материал Глава 1. Введение III-1-3

1.3.5 Административные требования в настоящем руководстве адресованы административным доменам. Административный домен представляет собой организационную единицу, которой может быть отдельное государство, группа государств (например, регион ИКАО или региональная организация), поставщик услуг авиационной связи (ACSP), поставщик аэронавигационного обслуживания (ANSP) или другая административная единица, которая управляет ресурсами и услугами сети ATN/IPS.

Рис. III-1-2. Объединенная сеть ATN/IPS

1.3.6 Основное требование заключается в том, что каждый административный домен, являющийся участником объединенной сети ATN/IPS, должен иметь один или несколько IPS-маршрутизаторов, которые осуществляют протокол междоменной маршрутизации, именуемый протоколом граничного шлюза (BGP). Это делается главным образом для того, чтобы можно было сформировать сеть ATN/IPS из различных административных доменов, в которой любой IPS-хост может установить контакт с любым другим IPS-хостом в объединенной сети ATN/IPS. 1.3.7 Протокол междоменной маршрутизации используется для обмена информацией маршрутизации между автономными системами. Согласно определению в RFC 1930 автономная система (AS) представляет собой связанную группу из одного или нескольких префиксов IP, работающих у одного или нескольких сетевых операторов, которые имеют единую и четко определенную политику маршрутизации. Из

ХостIPS

ХостIPS

ХостIPS

ХостIPS

ХостIPS

ХостIPS

ХостIPS

ХостIPS

ХостIPS

МаршрутизаторIPS

Объединеннаясеть ATN/IPS


AD AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

AD












этого определения вытекает наличие двух различных объектов: одним является AS как группа префиксов IP, а вторым являются сетевые операторы, т. е. административные домены. Это различие важно в Интернете, поскольку позволяет нескольким организациям (т. е. административным доменам) пересылать пакеты BGP поставщику обслуживания Интернет (ISP), который в свою очередь устанавливает соединение каждой из этих организаций с сетью Интернет. Настоящее руководство не препятствует такому использованию ISP; тем не менее, как указывалось выше, требования адресованы непосредственно административным доменам. Координация политики административными доменами 1.3.8 Маршрутизаторы IPS будут обмениваться информацией о своих внутренних сетевых префиксах с соседними маршрутизаторами, но могут также пересылать информацию маршрутизации о других сетевых префиксах, полученную от других соседей по BGP. В результате трафик между двумя административными доменами можно пересылать через ряд промежуточных административных доменов. Такой трафик, осуществляемый от имени двух других участников, именуют "транзитным трафиком". 1.3.9 Настоящее руководство не устанавливает, о каких маршрутах должны уведомлять маршрутиза-торы IPS, и не определяет базовую политику управления трафиком в условиях динамической маршрутизации. Однако административные домены должны координировать свою политику в области передачи транзитного трафика с одноранговыми административными доменами. Административные домены, являющиеся участниками ATN/IPS, должны обеспечивать надлежащую обработку транзитного трафика на основе следующих принципов: — административный домен не должен сообщать сетевой префикс, если он не готов

принимать входящий трафик в пункт назначения этого сетевого префикса; — при установлении соединений между двумя административными доменами может быть

согласован механизм взимания сборов для поддержки соответствующей политики в области транзита;

— административные домены, которые передают транзитный трафик, должны обеспечивать

проведение соответствующей политики в области защиты и качества обслуживания трафика.

Межсетевое взаимодействие ATN/IPS с подвижными службами 1.3.10 Сеть ATN/IPS для фиксированной связи или связи "земля – земля", описанную в пп. 1.3.2–1.3.7, можно расширить для поддержки мобильного обслуживания, т. е. связи "воздух – земля". Это делается с помощью мобильного протокола IPv6, рассматриваемого IETF в качестве общего решения в области мобильности. Мобильный IPv6 позволяет мобильным узлам (MN) (т. е. воздушным судам в ATN/IPS) осуществлять транспарентную связь с узлами-корреспондентами (CN) (т. е. наземными автоматизированными системами в ATN/IPS) при движении в пределах сетей связи "воздух – земля". Административный домен в ATN/IPS, предлагающий мобильное обслуживание IPv6, называют поставщиком мобильного обслуживания (MSP). Таким образом, ATN/IPS расширяют для поддержки мобильного обслуживания путем добавления MSP, предоставляющих мобильное обслуживание мобильным узлам. На рис. III-1-3 показана сеть ATN/IPS с MSP. Как видно из этого рисунка, для предоставления мобильного обслуживания MSP должен иметь одного или нескольких домашних агентов. Домашний агент играет ключевую роль, т. к. он осуществляет управление информацией о местоположении (LM) для слежения за движением мобильного узла и локализации мобильного узла для доставки данных, одновременно выполняя функцию междоменного маршрутизатора, обеспечивающего соединение с остальными объектами ATN/IPS. (Следует иметь в виду, что это логический вариант, а в реальной обстановке возможны иные физические конфигурации). Необходимо отметить, что IETF осуществляет модернизацию мобильных IPv6, соответствующих требованиям RFC 3775 (RFC 3775 bis). При реализации протокола RFC 3775 необходимо учитывать эти обновленные требования.


1.3.11 На рис. III-1-3 показана минимальная конфигурация, например для ATSC, когда MSP может быть ACSP. Однако это не единственная возможная конфигурация. ANSP может взять на себя функцию собственного MSP и получить сервис-доступ от ACSP. Аналогичным образом, для поддержки AOC и AAC авиакомпания может стать MSP. Полномочный орган аэропорта также может стать MSP и предлагать обслуживание в ATN/IPS. В этом случае может предоставляться мобильное обслуживание на IP-уровне параллельно и в дополнение к мобильному обслуживанию на канальном уровне. Как отмечается в пп. 1.3.2–1.3.7, сеть ATN/IPS предназначена для поддержки ATSC, AAC и AOC, однако мобильный подход может использоваться другими авиационными организациями. Эти организации могут стать MSP и поддерживать другие типы связи, например авиационная связь для пассажиров (APC). В этом случае может предлагаться расширенная форма мобильного IP-обслуживания, именуемая сетевой мобильностью (NEMO).

Сетевые механизмы перехода 1.3.12 IPv6 был принят IETF и административными органами Интернет в связи со стремительным ростом глобальной сети Интернет. IPv6 позволяет решить многие технические проблемы, связанные с IPv4, в частности с ограниченностью адресного пространства IPv4.

Рис. III-1-3. ATN/IPS с MSP

AD AD

Мобильный узел

Узел-корреспондент

Маршрутизатордоступа

Поставщикмобильного

обслуживания(MSP)

Домашнийагент


MIPv6








1.3.13 Глобальное применение IPv6 уже начато в регионах ИКАО для поддержки приложений, связанных с организацией воздушного движения. Этот протокол является структурным элементом в сети Интернет нового поколения, который обеспечивает определенную гибкость внедрения новых технологий и видов обслуживания. Тот факт, что сеть ATN/IPS основана на IPv6, позволяет оперативно использовать новые серийные коммерческие продукты и технологии. 1.3.14 Внедрение ATN/IPS будет постепенным. Многим организациям придется проделать многоэтапный путь для обеспечения интеграции конечных систем и маршрутизаторов ATN/IPS в существующую среду, в частности при наличии устаревших систем AFTN, AFTN/CIDIN, X.25, ATN/OSI CLNP (главным образом CLNP с Ethernet или "X.25") и IPv4. 1.3.15 Три механизма перехода могут помочь организациям, осуществляющим развертывание ATN/IPS в неоднородной среде: — туннелирование: инкапсуляция одного протокола в другой; — двойной стек: среда, в которой одновременно используется несколько протоколов; — трансляция: преобразование одного протокола в другой. 1.3.16 Детальное описание первых двух механизмов дается в RFC 4213 (Базовые механизмы перехода для хостов и маршрутизаторов IPv6). Аспекты применимости вышеуказанных трех механизмов к ATN/IPS рассматриваются ниже. Туннелирование 1.3.17 IPv6 предназначен для работы с разнообразными интерфейсами нижнего уровня, включая технологии Frame Relay, ATM, HDLC, PPP и LAN. Туннелирование предполагает инкапсуляцию данного протокола в другой; другими словами, IPv6 будет инкапсулирован в другой функционально эквивалентный сетевой протокол. Применительно к ATN/IPS основное преимущество этого механизма заключается в том, что авиационные организации, которые уже используют сети IPv4, дадут возможность хостам и маршрутизаторам ATN/IPS осуществлять связь друг с другом через такую базовую сеть IPv4. Кроме того, этот механизм можно применять, если инфраструктура взаимосвязи между двумя административными доменами ATN/IPS ограничена IPv4. 1.3.18 Следует напомнить, что IPv6 не может функционировать в X.25; туннель IPv6 поверх IPv4 может, в свою очередь, быть туннелирован по сети X.25. Специальный механизм туннелирования, именуемый IP SNDCF, определен для приложений ATN/OSI, причем следует иметь в виду, что это обеспечивает функциональное взаимодействие приложений ATN/OSI в сети IP, но не обеспечивает функциональной совместимости с приложениями ATN/IPS. 1.3.19 Использование механизмов туннелирования ведет к увеличению служебного трафика, а разделение двух маршрутизируемых доменов обусловливает необходимость дополнительного сетевого управления, например, маршрутизация домена IPv6 над базовым маршрутизируемым доменом IPv4 требует управления по параметрам QoS, защиты и оптимизации маршрута. Кроме того, этот механизм предполагает функциональное взаимодействие только между системами ATN/IPS, но не обеспечивает совместимости между системами ATN/OSI или другими системами IPv4 в организации. Тем не менее, он может стать эффективным средством для развертывания ATN/IPS как внутри, так и между двумя административными доменами. 1.3.20 Механизм туннелирования лучше всего подходит для решения проблем связи нижнего уровня между хостами и маршрутизаторами IPv6 в ATN/IPS, но он не обеспечивает функционального взаимодействия с несовместимыми системами ATN/IPS.


Двойной стек 1.3.21 Механизм двойного стека предполагает, что система использует более одного протокола связи для данного приложения или функции. В Интернете значительное количество связных приложений (например, HTTP, FTP, SSH, DNS, SMTP) использую двойной стек, т. е. поддерживают протоколы IPv4 и IPv6. Однако в контексте ATN/IPS механизм двойного стека призван решать аналогичные, но отличающиеся проблемы. 1.3.22 Концепция двойного стека идеально подходит для систем, которые должны поддерживать приложения ATN как для OSI, так и для IPS. В такой среде приложения разрабатываются абстрактным образом так, чтобы они были независимыми от нижней уровней, т. к. неизвестно, какой связной протокол нижнего уровня (OSI или IP) используется для ведения связи с одноранговым партнером. Разработчики X.400 используют этот подход для поддержки как OSI, так и IP, чтобы не создавать сложные специальные связные шлюзы низкого уровня. Обычно в таких системах используются какие-либо директории или "справочные таблицы", позволяющие увязать адрес высокого уровня с адресом конкретного связного протокола. 1.3.23 Концепцию двойного стека можно расширить до нескольких стеков, например, IPv4, IPv6, X.25. Системы ATN AMHS обычно поддерживают несколько протоколов, в частности OSI, TCP/IP и X.25. 1.3.24 Механизм двойного стека обеспечивает максимальный уровень функционального взаимодействия с партнерами при уменьшении сложности шлюзов связных протоколов нижнего уровня и количества точек отказа. Он идеально подходит для таких приложений, как обработка сообщений ОВД (AMHS), где некоторые системы работают на основе OSI, а другие используют TCP/IP. Подход двойного стека можно использовать в наземных системах линии передачи данных "воздух – земля" для поддержки CPDLC по нескольким линиям передачи данных (например, ATN/OSI и ATN/IPS). Трансляция 1.3.25 Механизмы трансляции предполагают конверсию из одного протокола в другой. Этот механизм можно рассматривать как шлюз для связи нижнего уровня между двумя протоколами с высокой степенью общности. Несколько методов трансляции были разработаны в контексте перехода с IPv4 на IPv6, т. к. обе версии имеют ряд общих характеристик; в частности, см. RFC 2766 "Трансляция сетевых адресов – трансляция протоколов (NAT-PT)". 1.3.26 В рамках общего перехода с IPv4 на IPv6 предполагалось, что некоторые системы могут вести связь только с IPv4, а другие только с IPv6. Учитывая аспекты глобальной универсальности Интернета и тот факт, что большинство приложений и систем Интернета работают в режиме двойного стека, потребность в трансляторах уменьшилась. 1.3.27 Тем не менее, применительно к ATN/IPS трансляторы могут сыграть важную роль в краткосрочном плане. Например, хотя существующие средства AMHS используют операционные системы двойного стека, ни одна из них не модернизировала своих прикладных кодов до уровня IPv6. Другими словами, поддерживаются стандарты RFC 1006, но не RFC 2126. В таких конкретных случаях, а также учитывая ограниченное количество систем, использование трансляторов на краткосрочной основе позволяет обеспечить совместимость таких систем с ATN/IPS и взаимодействие с системами, основанными на RFC 2126. 1.3.28 Трансляторы IPv4/IPv6 повышают сложность инфраструктуры IP и управления ею. Подход двойного стека является предпочтительным, однако в отдельных случаях трансляторы могут стать единственным краткосрочным решением для обеспечения совместимости с ATN/IPS.


Комбинации механизмов 1.3.29 Поскольку внедрение ATN/IPS будет постепенным, очевидно, что будут использоваться сочетания трех описанных выше механизмов. 1.3.30 Различные комбинации этих механизмов могут применяться в зависимости от специфики конкретного административного домена.

1.4 СТЕК ПРОТОКОЛОВ

Рекомендации относительно физического и канального уровней 1.4.1 Проблемы физического и канального уровней будут выявляться в ходе регламентного обслуживания и контактов между Договаривающимися государствами. Вопросы физического и канального уровней будут решаться в процессе обслуживания и должны оговариваться в меморандуме о договоренности (MoA).

Сетевой уровень 1.4.2 ATN/IPS работает с протоколом IPv6, который использует 128-битовые адреса по сравнению с 32-битовыми в IPv4. Префиксы IPv6 обмениваются между административными доменами с использованием статических маршрутов или BGP для обеспечения глобальной маршрутизации ATN/IPS. План адресации 1.4.3 В протоколе IPv6 (в отличие от IPv4) не существует понятия частных адресов. По аналогии с практикой X.25 каждый административный домен должен разработать план адресации IPv6 (см. раздел "Сетевая адресация" в пп. 2.3.8–2.3.13 части I). Это предполагает получение уникального префикса IPv6 и использование процедур присвоения для сетей и хостов. Интерфейс приложений на сетевом уровне 1.4.4 Обычно интерфейс приложений при ведении связи осуществляется на транспортном уровне, однако иногда необходимо передавать и получать датаграммы на уровне сети. Это делается с помощью ряда API-расширений сокетов, указанных в RFC 3542 "Расширенный интерфейс прикладного программирования (API) сокетов для IPv6". Междоменная маршрутизация 1.4.5 Междоменная маршрутизация позволяет обмениваться префиксами IPv6 между административными доменами. Такой обмен обеспечивается конфигурацией статической маршрутизации или протоколом граничного шлюза (BGP) между маршрутизаторами ATN/IPS для обеспечения глобальной маршрутизации ATN/IPS. 1.4.6 В зависимости от размеров административного домена могут устанавливаться дополнительные внутренние уровни меж- и внутридоменной маршрутизации или создаваться конфедерации BGP.


План нумерации автономных систем (AS) 1.4.7 Номера AS необходимо присваивать и конфигурировать в маршрутизаторах ATN/IPS для объявления своих автономных систем в пределах маршрутизируемого домена. План нумерации AS представлен в добавлении к части I. ID маршрутизатора ATN/IPS 1.4.8 Для того чтобы установить BGP между двумя соседними объектами, каждый из участников BGP должен определить ID маршрутизатора. Если два маршрутизатора используют одно и тоже значение ID маршрутизатора, сеанс BGP не может быть установлен. Поскольку ID маршрутизатора представляет собой 32-битовое поле, он обычно помещается в IPv4-адресе маршрутизатора. 1.4.9 Маршрутизаторы ATN/IPS могут не иметь IPv4-интерфейса или уникальных IPv4 адресов, и поэтому необходимо рекомендовать какую-либо схему. Хотя уникальность этих значений в глобальном масштабе не является обязательной, для облегчения внедрения ATN/IPS рекомендуется следующая схема (основана на проекте dupont-durand-idr-ipv6-bgp-routerid-01.txt): — 4 бита установлены на 1, 16 битов установлены на номер AS (глобальный план нумерации

AS см. в добавлении к части I); — 12 битов распределяются вручную в пределах домена (допускается 4096 различных

вариантов ID маршрутизаторов в каждом маршрутизируемом домене). Объявление маршрутизации 1.4.10 Маршрутизаторы ATN/IPS должны объявлять сетевые префиксы на основе постоянной длины префикса или агрегированных префиксов маршрута. Разделение типов трафика 1.4.11 BGP-4 в исходном формате не обеспечивает прокладывания разных маршрутов для разных типов трафика в один и тот же пункт назначения. Требования ATN/IPS в отношении разделения типов трафика можно удовлетворять с помощью соответствующих положений плана адресации ATN; если в адресе ATN содержится указание на тип трафика, BGP-4 обеспечит транспарентную передачу информации маршрутизации с разделением маршрутов передачи для разных типов трафика. Приоритеты трафика и дифференцированное обслуживание 1.4.12 Исторически приоритет сетевого уровня выбирался исключительно путем направления запроса в поле типа обслуживания (TOS) в заголовке IP. Хотя при дифференцированном обслуживании (RFC 2474) в поле TOS сохранена семантика очередности IP, такой подход в настоящее время не рекомендуется. Это отчасти связано с тем, что на смену IP-очередности пришла стратегия пошагового поведения на каждом узле (PHB) при дифференцированном обслуживании, а также тем, что сетевые администраторы обычно не доверяют указаниям прикладных параметров. Дифференцированное обслуживание (RFC 2474) предоставляет возможность последовательного указания и реализации QoS в сети ATN/IPS. Такая спецификация осуществляется на базе узлов с указанием поведения индивидуальных узлов применительно к QoS (PHB). Подробнее об общих рамках и существующей практике рассказывается в RFC 2475 "Архитектура дифференцированного обслуживания". Примечание. См. п. 4 "Качество обслуживания (QoS)".


Многоадресная передача 1.4.13 Необходимость направления одной и той же информации нескольким получателям является одним из основных требований рассылки данных наблюдения. Это требование может быть реализовано с помощью функции многоадресной рассылки IPv4 и IPv6. Другие сетевые методы, позволяющие добиться этой же цели многоадресной рассылки, в настоящем документе не рассматриваются. 1.4.14 В ряде Договаривающихся государств для рассылки данных наблюдения используется национальное многоадресное обслуживание IPv4. Однако ограниченный объем адресного пространства в IPv4 для многоадресной передачи, а также отсутствие межсетевых переходов между IPv4 и IPv6 затрудняет их широкое внедрение для ATN/IPS. 1.4.15 В последние годы достигнут значительный технический прогресс в области IP-многоадресной маршрутизации; в частности, разработан метод многоадресной рассылки, зависящей от отправителя (SSM). В отличие от используемой в настоящее время методики PIM-SM (многоадресная рассылка, независимая от протоколов – разреженный режим) метод SSM обеспечивает более простую и надежную маршрутизацию многоадресного IP-трафика и идеально подходит для передачи данных наблюдения. Использование этой технологии с IPv6 рекомендуется в документе Евроконтроля, озаглавленном "Рекомендации Евроконтроля по поддержке внедрения (EGIS), часть 5 "Спецификации связи и наблюдения", глава 12 "Рассылка информации наблюдения в соответствии со списком требуемых профилей (PRL) многоадресной IP-рассылки"; с этим документом можно ознакомиться по следующему адресу: http://www.eurocontrol.int/communications/public/standard_page/com_network.html 1.4.16 Канал передачи данных методом многоадресной рассылки, зависимой от источника (SSM), определяет комбинация группового адреса получателя и единичного адреса отправителя. Это соответствует единичному потоку данных наблюдения, передаваемому из конкретного источника в ATN/IPS (см. рис. III-1-4).

| 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|0011|1110|00000000|00000000| 000……………………000 | group ID | +--------+----+----+--------+--------+----------------+----------+

Рис. III-1-4. SSM групповой IPv6-адрес с глобальной сферой действия IPv6

— IPv6 многоадресный групповой ID устанавливается в диапазоне 0x8000000 – 0xFFFFFFFF,

разрешенном для динамического присвоения хостом, как указано в разделе 4.3 RFC 3307 и разделе 1 RFC 4607;

— результирующий располагаемый диапазон SSM-адресов в IPv6 составляет:

FF3E::8000:0/97 (FF3E:0:0:0:0:0:8000:0 / 97); — при условии надлежащего доступа к обслуживанию для получения потока SSM

необходимы следующие три параметра: 1. Адрес отправителя (единичный адрес). 2. Групповой адрес (как указано в заявке отправителя). 3. Порт (по умолчанию 8600 для данных наблюдения ASTERIX в Европе).


Транспортный уровень 1.4.17 Протоколы транспортного уровня используются для обеспечения надежной или "наилучшей из возможной" связи в ATN/IPS. Существует два обязательных протокола передачи данных – TCP и UDP. Протокол TCP используется для предоставления надежного транспортного обслуживания, а UDP - для предоставления "наилучшего из возможного" обслуживания. Могут использоваться другие транспортные протоколы, которые не должны влиять на качество связи или обслуживания в ATN/IPS. Протокол управления передачей (TCP) 1.4.18 Протокол Интернет (IP) работает путем обмена группами данных, именуемых пакетами. Пакеты представляют собой короткую последовательность байтов, состоящую из заголовка и тела сообщения. Заголовок описывает информацию о маршрутизации пакета, а маршрутизаторы в Интернете используют эти данные для передачи пакета в правильном направлении до прибытия в конечный пункт назначения. Тело содержит прикладную информацию. Протокол TCP ориентирован в первую очередь на точность доставки, а не на ее своевременность, и иногда имеют место длительные задержки из-за ожидания нестандартных сообщений или повторной передачи утерянных сообщений; он не особенно подходит для видов применения в реальном времени, например для Интернет-телефонии (VoIP). Для работы в реальном времени требуются такие протоколы, как протокол передачи в реальном времени (RTP) в сочетании с протоколом пользовательских датаграмм (UDP). 1.4.19 TCP обеспечивает надежное обслуживание по доставке потоков, гарантирующее доставку потока данных от одного хоста другому без дублирования или утери данных. Из-за недостаточной надежности при передаче пакета используется метод, именуемый позитивным подтверждением с повторной передачей, гарантирующий надежность передачи пакетов. Этот основополагающий метод требует, чтобы адресат после получения данных отправил ответное сообщение с подтверждением. Отправитель регистрирует каждый направленный пакет и ждет подтверждения, прежде чем направить следующий пакет. Отправитель также ведет учет времени с момента направления пакета и повторно направляет пакет по истечении времени, отведенного для ожидания подтверждения. Функция таймера необходима для предотвращения утери или повреждения пакета. 1.4.20 В случае перегрузки каналов IP может отклонять пакеты. В интересах эффективности два последовательных пакета в Интернете могут передаваться адресату по разным маршрутам. Пакеты могут прибывать в пункт назначения в неправильном порядке. 1.4.21 Библиотека программ TCP использует IP и предоставляет простой интерфейс для приложений путем укрытия основной части структур пакетов, перекомпоновки нестандартных пакетов, минимизации перегруженности в сети и повторной передачи отклоненных пакетов. Таким образом, TCP значительно упрощает задачу разработки сетевых приложений. 1.4.22 TCP предоставляет обслуживание с соединением и надежной семантикой. Он работает над сетевым уровнем, который не всегда обнаруживает ошибки и сообщает о них (например, повреждение данных, неправильная маршрутизация). С этой целью протокол обеспечивает: — обнаружение ошибки на основе контрольной суммы, охватывающей транспортный

заголовок и полезную нагрузку, а также некоторую необходимую информацию о сетевом уровне;

— устранение ошибок путем повторной передачи ошибочных или утерянных пакетов.


1.4.23 TCP также позволяет обнаружить и устранить заторы в сети и определить максимальные размеры сегментов данных пользователей. Это важно для работы в условиях разнородных подсетей с малой шириной полосы и длительным временем ожидания, например в бортовых или наземных подсистемах реальной ATN/IPS. Протокол пользовательских датаграмм (UDP) 1.4.24 Протокол UDP предоставляет обслуживание без организации соединения с ограниченными возможностями обнаружения ошибок и без механизма восстановления и управления заторами. Он предназначен для обмена данными в небольших объемах, когда допустимы отдельные случаи необнаруженной утери или повреждения пакета, а основной целью является простота использования. Адресация транспортного уровня 1.4.25 Адресация транспортного уровня основана на номерах портов (16-битовые целые значения), которые связаны с конечными пунктами отправления и назначения, для идентификации отдельных потоков данных. Порты классифицируются по трем категориям с соответствующими диапазонами значений: — широко известные порты – от 0 до 1023 включительно, которые присваиваются IANA. В

большинстве систем эти порты могут использоваться только системными (или корневыми) процессами или программами, которые запущены привилегированными пользователями. Такие заранее установленные и хорошо известные номера портов, связанные с конкретными приложениями TCP и/или UDP, делают их видимыми ("широко известными") для клиентских приложений без специфической информации или конфигурации;

— зарегистрированные порты – это порты в диапазоне 1204–49 151, которые зарегистрированы

IANA по запросам пользователей. Такие порты играют ту же роль, что и широко известные порты, однако предназначены для обычных или менее критических программ. Пользование такими портами не требует специальных привилегий;

— динамические и/или частные порты – это порты в диапазоне 49 152–65 535. Они могут

свободно использоваться приложениями. 1.4.26 Назначение порта производит IANA по запросу. Обновляемый список зарегистрированных портов находится по адресу: http://www.iana.org/assignments/port-numbers. 1.4.27 Такой план назначения является обязательным в публичном Интернете. Его следует применять в ATN/IPS (по крайней мере, в отношении широко известных портов) во избежание каких-либо конфликтов. 1.4.28 Кроме того, хосты ATN/IPS должны поддерживать перечисленные ниже зарегистрированные порты: — tcp 102 для ATSMHS; — tcp 8500 для FMTP; — tcp/udp 5910 для CM; — tcp/udp 5911 для CPDLC; — tcp/udp 5912 для FIS; — tcp/udp 5913 для ADS.


Прикладной интерфейс на транспортном уровне 1.4.29 Интерфейс приложений с транспортными уровнями TCP и UDP осуществляется на разнообразных платформах/операционных системах, как указано в RFC 3493 "Основные расширения интерфейса сокетов для IPv6". Этот RFC распространяет интерфейс сокета (первоначально разработанный университетом в Беркли для поддержки IPv4 при распределении BSD Unix) на IPv6. Предотвращение перегрузок 1.4.30 В целях адаптации к меняющимся условиям прохождения трафика в подсетях протокол TCP использует 4 основных механизма: замедленный старт, предотвращение перегрузок, ускоренная повторная передача и ускоренное восстановление. Они описаны в RFC 2581 "Контроль насыщения в TCP". Первые два механизма призваны не допустить потери важных пакетов в условиях перегруженности, а остальные два механизма предназначены для уменьшения задержек при повторной передаче утерянных пакетов. Эти механизмы реализуются независимо в каждой конечной системе; они не дают полной гарантии недопущения утери пакетов. 1.4.31 В подсетях с небольшой шириной полосы (например, бортовые/наземные подсети ATN) приложения TCP могут использовать механизм непосредственного уведомления о перегруженности, что дает существенные преимущества. Этот механизм рассматривается в RFC 3168 "Добавление явных уведомлений о перегрузке (ECN) в IP". Он прогнозирует перегрузку, значительно сокращая число утерянных пакетов. Однако он воздействует на транспортный и сетевой уровни и требует участия значительного количества маршрутизаторов в сетях (предпочтительно, маршрутизаторов на границе низкоскоростных подсетей / подсетей с большим временем ожидания). Обнаружение и устранение ошибок 1.4.32 Обнаружение ошибок в TCP основано на отсутствии своевременных подтверждений. Устранение осуществляется путем повторной передачи потерянных (предположительно) пакетов. Потеря большого числа пакетов за короткий период времени может серьезно отразиться на пропускной способности соединения TCP (и его эффективности). Это может стать критическим фактором в подсетях с большим временем ожидания (например, бортовые/наземные подсети ATN). Поддержка механизма выборочного подтверждения TCP поможет смягчить остроту этой проблемы благодаря выборочной повторной передаче только потерянных пакетов (а не целой последовательности от первого до последнего пакета). Этот вариант рассматривается в RFC 2018 "Варианты выборочного подтверждения TCP". Модули повышения производительности (PEP) 1.4.33 Модули повышения производительности (PEP) часто используют для восстановления характеристик TCP, серьезно ухудшившихся из-за различия особенностей каналов в разнородной среде, например при беспроводной или спутниковой связи, которая распространена в авиации. PEP транспортного или прикладного уровня применяются для адаптации параметров TCP к различным канальным характеристикам. В RFC 3135 "Модули повышения производительности, призванные преодолеть ухудшение характеристик на уровне канала" содержит обзор методов повышения производительности PEP и описывает некоторые последствия использования PEP. Большинство последствий использования PEP связаны с тем, что семантика соединений в сквозной связи между конечными пунктами обычно нарушается. В частности, при использовании PEP блокируется сквозное кодирование IPsec, что отражается на мобильности и процедурах переключения.


Использование транспортного уровня 1.4.34 Виды использования соединений транспортного уровня оказывают большое влияние на качество обслуживания (QoS) приложения. Прикладные сообщения могут иметь различные классы обслуживания (CoS); некоторые из них могут требовать надежной доставки в оговоренном порядке. Существует 4 варианта использования обслуживания транспортного уровня TCP: — I. Повторное установление соединения TCP для каждой передачи и для каждого сервиса. Для каждого сервиса используется специальное соединение TCP. При генерировании

данных прикладного обслуживания устанавливается соединение транспортного уровня, после чего передаются данные. После успешной передачи соединение закрывается.

— II. TCP-соединение устанавливается для каждого сервиса и остается открытым. Для каждого сервиса используется специальное соединение TCP. Соединение

устанавливается во время подключения и первого использования и закрывается в момент отключения или передачи обслуживания.

— III. Повторное установление соединения TCP для каждой передачи многоадресного

сервиса. Устанавливается совместное TCP-соединение для всех сервисов в комплекте (одно

приложение может распоряжаться несколькими сервисами). Датаграммы, подготовленные этими приложениями, передаются через такое совместное соединение. Соединение открывается в момент генерирования сервисной датаграммы и закрывается после ее успешной передачи.

Примечание. Все сервисы в многоадресном комплекте должны требовать одинакового CoS и генерироваться одним и тем же приложением.

— IV. TCP-соединение устанавливается один раз для многоадресного комплекта сервиса

и остается открытым. Устанавливается совместное TCP-соединение для всех сервисов в комплекте (одно

приложение может распоряжаться несколькими сервисами). Датаграммы, подготовленные этими приложениями, передаются через такое совместное соединение. Соединение устанавливается во время подключения и первого использования и закрывается в момент отключения или передачи обслуживания.

Примечание. Все сервисы в многоадресном комплекте должны требовать одинакового CoS и генерироваться одним и тем же приложением.

1.4.35 Передача мультиплексных сервисов, генерируемых одним приложением, но с разными требованиями к CoS (см. варианты III и IV), не рекомендуется, т. к. QoS на сетевом уровне устанавливается на каждое соединение TCP. TCP не имеет возможности предоставлять дифференцированное QoS в рамках одного соединения, так что любая информация CoS может быть утрачена по крайней мере частично. Передача мультиплексных сервисов от одного приложения и с одинаковыми требованиями к CoS не создает такой проблемы. 1.4.36 Рекомендуется использовать по крайней мере одно зарезервированное транспортное соединение для каждого сервиса (варианты I и II). Соединение может устанавливаться для каждого сервиса или приложения.


1.4.37 Если разные сервисы одного приложения мультиплексируются через совместное соединение TCP, все сервисы должны требовать одного и того же CoS (варианты III и IV). 1.4.38 Для связи "воздух – земля" рекомендуется открывать соединение во время начала сеанса или первого использования и держать его открытым до окончания сеанса или передачи обслуживания (варианты II и IV).

Прикладной уровень Расширения ASN.1 для управления контекстом (CM) 1.4.39 Применение функции CM в ATN требует адаптаций ASN.1 для работы в ATN/IPS. Примечание. Ожидается, что в следующем издании Doc 9880 будут рассмотрены эти расширения. Определение CM ASN.1 1.4.40 Для обеспечения доставки адресной информации, специфической для IPS, необходимо обновлять приложение CM ASN.1. В отличие от других возможных методов получения приложений адресной информации CM также предоставляет дополнительные данные, призванные упростить сопоставление информации о воздушном судне с данными плана полета. 1.4.41 Добавлены новые определения ASN.1 с целью сохранения обратной совместимости с предыдущими версиями CM. При обмене прикладной информацией OSI ATN CM использовала элемент AEQualifierVersionAddress. Теперь этот элемент заменен элементом AEEnhancedQualifierVersionAddress, со специфическим новым элементом APEnhancedAddress, как показано ниже:

AEEnhancedQualifierVersionAddress ::= SEQUENCE { aeQualifier AEQualifier, apVersion VersionNumber, apAddress APEnhancedAddress } Элемент APEnhancedAddress позволит пересылать TSAP для использования в сети OSI или IP- адрес для использования с IPS. APEnhancedAddress показан ниже: APEnhancedAddress ::= CHOICE { longTsap [0] LongTsap, shortTsap [1] ShortTsap, ipAddress [2] IPAddress, ... }

1.4.42 Элемент IPAddress новый и используется для передачи фактического адреса IPv6. Специальное определение IPv4 не было включено в это определение. Это сделано для упрощения определений и поощрения перехода на IPv6. Если некоторые схемы реализации требуют адреса IPv4, их можно представить в формате IPv6 с использованием обычной процедуры преобразования IPv4, т. е. первые 80 битов устанавливаются на 0, следующие 16 устанавливаются на 1, а последние 32 представляют адрес IPv4.


1.4.43 Кроме того, включен дополнительный элемент port. Это сделано для того, чтобы можно было указать порт для IP-адреса, который относится к конкретному приложению. Указания порта не требуется, если в схеме реализации использованы стандартные номера портов IANA, присваиваемые приложениям IPS. Элемент IPAddress показан ниже:

IPAddress ::= SEQUENCE { ipHostOrAddr IPHostOrAddress, port Port OPTIONAL, ... }

1.4.44 Элемент IPHostOrAddress предоставляет дополнительную гибкость в плане возможности использования имени хоста или адреса IPv6. Имя хоста определено как строка символов IA5 размером от 2 до 255 знаков, порт – как целое число в диапазоне от 0 до 65 536, а адрес IPv6 – как строка из 16 октетов. Эти элементы показаны ниже:

IPHostOrAddress ::= CHOICE { hostname [0] Hostname, ipv6Address [1] IPv6Address, … } IPv6Address ::= OCTET STRING(16) Port ::= INTEGER(0..65536) Hostname ::= IA5String(SIZE(2..255))

Использование CM ASN.1 1.4.45 Использование IPv6 ASN.1 будет аналогичным использованию версии OSI. Это означает, что, когда функция CM хочет предоставить адресную информацию для поддерживаемых приложений, она должна указать приложение, номер версии приложения и адрес приложения по каждому из приложений, которые могут поддерживаться. Это должно делаться независимо от используемой сетевой технологии. 1.4.46 Для приложения ATN, реализуемого в IPS, адрес IPv6 будет использоваться для адресация каждого поддерживаемого приложения. В настоящее время использование имени хоста не определено, и поэтому в IPv6Address будет использоваться только элемент IPHostOrAddress. Элемент IPv6Address будет иметь значение адреса IPv6 приложения. 1.4.47 Не будет необходимости указывать номер порта, поскольку номера портов уже определены для приложений, и эта информация не требует сквозной передачи. Поэтому элемент IPAddress будет содержать только IPHostOrAddress. 1.4.48 Элемент APEnhancedAddress будет использовать опцию IPAddress, т. к. определения TSAP для IPS не релевантны. И наконец, элементы AEQualifier и VersionNumber необходимо предоставлять как часть элемента AEEnhancedQualifierVersionAddress. Элементы AEQualifier и VersionNumber будут указываться так же, как приложения OSI, т. е. AEQualifier будет обозначаться целым числом, определенным в части III документа Doc 9880, в диапазоне от 0 до 255, которое идентифицирует приложение (например, для ADS принято значение "0"), а VersionNumber будет обозначаться целым числом в диапазоне от 0 до 255, которое идентифицирует версию данного приложения.


1.4.49 После обмена информацией о приложениях эти данные по мере необходимости будут предоставляться другим системам или процессам в бортовых и наземных системах для реализации приложений. Этот подход, использованный в CM версии OSI, не изменился.

1.5 КАЧЕСТВО ОБСЛУЖИВАНИЯ (QoS)

Введение 1.5.1 Группа IETF определила технологию пошагового поведения (PHB) при дифференцированном обслуживании как средство описания, классификации и управления сетевым трафиком для обеспечения предоставления QoS в IP-сетях. Документы RFC не указывают, каким образом реализовать PHB в сети, и эти моменты, как правило, определяются поставщиком систем. 1.5.2 На практике частные и публичные операторы IP-сети предоставляют обслуживание на основе ограниченного числа PHB: — EF (ускоренная пересылка) – определена в RFC 3246 как обслуживание с низким уровнем

потерь, задержек и колебаний. Обычно используется для речевой связи. — AF (гарантированная пересылка) – определена в RFC 2597 с обновлением в RFC 3260.

Гарантированная пересылка позволяет оператору предоставлять гарантии доставки, если параметры трафика не превышают заданных значений. Эти классы будут использоваться для чувствительных к задержкам приложений, обычно помечаемых AFx с указанием уровня очередности удаления. Обычно каждое конкретное приложение увязывается с конкретным классом AF, и один класс AF обычно ассоциируется с мультимедийными приложениями, например видео. Классы AF не зависят друг от друга и обладают преимуществом индивидуальной гарантированной ширины полосы. Это позволяет не допустить ситуации, когда одно критическое приложение забирает весь имеющийся диапазон и блокирует другие критические приложения.

— По умолчанию – класс "наилучшего из возможного" обслуживания, который используется

для решения некритических задач и нечувствительных к задержкам приложений.

Определения классов Контекст 1.5.3 Поставщики услуг связи ATN/IPS, вероятно, будут использовать одну и ту же инфраструктуру IPS для ATN и других не определяемых в ATN приложений, таких, как ATSMHS и данные наблюдения. Совместное использование ресурсов может осуществляться на различных уровнях, т. е. приложения ATN/IPS могут использовать тот же тип класса обслуживания, что и другие не относящиеся к ATN приложения с той же инфраструктурой маршрутизации IP. В качестве альтернативы, поставщики услуг связи ATN/IPS могут только желать использовать одну и ту же физическую инфраструктуру и эксплуатировать виртуальную частную сеть (VPN) для каждого сервиса; в этом случае отдельная модель CoS может применяться для каждого VPN-сервиса, одним из которых является ATN/IPS. В целом поставщики услуг связи ATN/IPS располагают гибкостью в части установления CoS для ATN/IPS в рамках своей инфраструктуры. 1.5.4 Для определений CoS важно, чтобы трафик ATN/IPS был достаточно классифицирован, т. е. путем использования соответствующих номеров портов и/или другими средствами, для надлежащего


обозначения входящего трафика. После поступления IP-пакета в сеть устанавливаются параметры PHB в зависимости от маркировки пакета. Поставщики услуг связи ATN/IPS должны будут работать с немаркированным или предварительно маркированным входящим трафиком и быть готовыми к маркировке или повторной маркировке трафика до его передачи в рамках своей инфраструктуры. Внутренние методы, механизмы и политика реализации PHB в сетях поставщиков услуг связи не относятся к компетенции ATN/IPS. PHBs/CoS в ATN/IPS 1.5.5 Сеть ATN/IPS должна поддерживать устаревшие приложения ATN в IPS. В настоящее время такая предполагаемая поддержка охватывает CM(DLIC), FIS(ATIS), CPDLC, ADS-C, ATSMHS. Справочное обслуживание (DIR) (см. Doc 9880, часть IVA) предусматривается только для ATN/OSI; предполагается, что AIDC будет реализовываться в рамках региональных решений. 1.5.6 Каждое приложение ATN соотносится с конкретным CoS, и поэтому динамическая поддержка различных приоритетов по категориям сообщений пользователя не предусматривается. 1.5.7 В таблице III-1-1 приводится пример административного домена, поддерживающего несколько приложений и классов обслуживания (CoS), которые классифицированы как очень высокий, высокий, нормальный и наилучший из возможных.

Таблица III-1-1. Соотношение приоритетов ATN/IPS с классами

Соотношение приоритетов/приложений Идентификация трафика (входящего)

Класс (тип CoS)

Очередность удаления

Приоритет ATN

Приложение ATN

Порт TCP/UDP IP-адрес

Очень высокий (EF)

Телефония (VoIP) Номера RTP 16384-32767

—

Высокий (AF)

1 0 — — —

1 — — —

2 — — —

3 ADS-C TCP 5913 UDP 5913

Адрес отправителя или получателя будет частью зарезервиро-ванного адреса, присвоенного постав-щикам мобильного обслуживания

CPDLC TCP 5911 UDP 5911

Нормальный (AF)

1 4 AIDC TCP 85001

FIS(ATIS) TCP 5912 UDP 5912


1. Применимо, когда OLDI/FMTP используется для разрешения обслуживания AIDC.


Соотношение приоритетов/приложений Идентификация трафика (входящего)

Класс (тип CoS)

Очередность удаления

Приоритет ATN


Порт TCP/UDP IP-адрес

2 5 METAR — —

3 6 CM(DLIC) TCP 5910 UDP 5910


ATSMHS TCP 102

7

Наилучший из возможных (по умолчанию)

8 – 14 — —

1.5.8 Для маркировки входящего трафика поставщик ATN/IPS имеет несколько средств идентификации: номер порта получателя сообщения, IP-адрес отправителя и/или IP-адрес получателя. Примечание. Использование значений точки кода дифференцированных услуг (DSCP)/типа обслуживания (ToS), установленных приложением или провайдером предыдущего связного обслуживания, возможно, не является оптимальным вариантом, т. к. это значение может быть неправильно сконфигурировано или неизвестно. Значения точки кода дифференцированных услуг (DSCP) 1.5.9 PHB указывается путем кодирования 6-битового значения, называемого точкой кода дифференцированных услуг (DSCP), в 8-битовом поле дифференцированного обслуживания (DS) заголовка IP-пакета. Значение DSCP в этом поле рассматривается как табличный индекс для выбора конкретного механизма обработки пакета. Такое соотношение должно быть реконфигурируемым, и административные домены могут выбирать различные значения при увязывании точек кода с PHB. Вместе с тем общепризнано, что значение DSCP 101110 относится к EF (ускоренная пересылка). 1.5.10 В таблице III-1-2 приводится пример увязывания значений DSCP с ATN/IPS PHB в ситуации, когда несколько приложений используют одну и ту же инфраструктуру IP-сети. В этой таблице приложениям "воздух – земля" присвоены точки кода специального класса, как предусмотрено в Doc 9880, для ATN IP SNDCF, однако в рамках ATN/IPS целесообразнее использовать AF PHB во избежание любого взаимодействия с устаревшими приложениями, которые используют уровни IP-очередности.


Таблица III-1-2. Примеры увязывании DSCP с PHB

Значение DSCP PHB Приложение

000000 CS0 Наилучшее из возможных

001000 CS1

001010 AF11 AIDC

001100 AF12

001110 AF13

010000 CS2 CM

010010 AF21 ATSMHS

010100 AF22

010110 AF23

011000 CS3 FIS

011010 AF31 Речевая запись

011100 AF32

011110 AF33

100000 CS4 CPDLC, ADS-C

100010 AF41 Речевое сообщение

100100 AF42

100110 AF43

101000 CS5

101110 EF Телефония

110000 NC1/CS6

111000 NC2/CS7

Классификация трафика 1.5.11 Классификация трафика представляет собой средство выражения типа трафика, требований к целостности и задержкам. Она предоставляет провайдеру услуг связи дополнительную информацию для более полного удовлетворения потребностей пользователей в рамках конкретной сетевой операции. Обычно данные классификации трафика оговариваются в заключаемых соглашениях об уровне обслуживания, в которых определяются такие дополнительные параметры, как пункты предоставления обслуживания, устойчивость обслуживания, требования к разбивке пакетов при превышении установленного диапазона, метрические пункты обслуживания, среднее время восстановления (MTTR) и скорость портов. 1.5.12 В таблице III-1-3 приведен пример классификации трафика в связи "земля – земля", который взят из спецификаций Общеевропейской сети (PENS).


Таблица III-1-3. Пример классификации трафика


Средняя длина

сообщения Выражение целостности Колебание

Обычная ширина полосы

(между пунктами)

Задержка в сети

(в одном направлении)

Речевая связь (VoIP с использованием G.729)

70 (байтов)

– <15 мс 12 Кбит/с <100 мс

OLDI/FMTP (региональный AIDC)

150 (байтов) 1 поврежденноесообщение

пользователя на 2000

N/A 10 Кбит/с <1 с

ATSMHS 3 Кбайта 10-6 (в единицах1000-байтовых

блоков сообщений)

N/A 20 Кбит/с <5 с

1.6 РЕКОМЕНДАЦИИ ПО МОБИЛЬНОСТИ

Мобильный IPv6 1.6.1 Настоящее руководство устанавливает, что решением для IP-мобильности для ATN/IPS является мобильный IPv6 (MIPv6), как указано в RFC 3775. В мобильном IP мобильный узел (MN) имеет два адреса: домашний адрес (HoA), являющийся постоянным адресом, и динамический временный адрес (CoA), который изменяется после изменения точки подключения мобильного узла (см. рис. III-1-5). Основным методом работы мобильного IP является пересылка. Узел-корреспондент (CN), каковым является любой одноранговый узел, с которым мобильный узел осуществляет связь, направляет пакеты домашнему агенту (HA) мобильного узла. Контакт между CN и HA устанавливается путем нормальной IP-маршрутизации. После получения пакета от CN HA пересылает эти пакеты MN по его нынешнему CoA. HA просто туннелирует оригинальный пакет в другой пакет с его собственным адресом отправителя и адресом получателя, которым является его нынешний CoA. Это возможно благодаря мобильному IP-протоколу, в соответствии с которым MN посылает HA сообщения "обновления привязки" каждый раз, когда изменяется точка подключения. Обновление привязки ассоциирует HoA мобильного узла с его нынешним CoA. HA ведет "кэш привязки", в котором хранится текущий CoA соответствующего MN.

Рис. III-1-5. Мобильный IP

Внешняя сеть

Домашняя сеть Удаленная сеть

MN

CN

AR AR

HA

HoA

CoA1 CoA2

движение


Двунаправленное туннелирование MIPv6 1.6.2 В обратном направлении MN может просто посылать пакеты непосредственно CN с использо-ванием нормальной IP-маршрутизации. Однако это приводит к треугольной маршрутизации и, в зависимости от относительного местоположения HA, возможна ситуация, когда путь в одном направлении (например от CN до HA до MN) значительно длиннее, чем путь в обратном направлении (например, от MN до CN). Еще один момент, который следует учитывать в этом случае, связан с тем, что, если MN использует свой домашний адрес в качестве адреса отправителя, может возникнуть проблема из-за того, что многие сети осуществляют фильтрацию поступающих пакетов на входе и не принимают топологически некорректные пакеты. Именно это произойдет с пакетами от MN, поскольку фактически они отправлены с временного адреса, а адрес отправителя в IP-пакете является домашним адресом. Поэтому MIPv6 разрешает MN следовать тем же путем в обратном направлении до CN через HA с использованием метода двунаправленного туннелирования, при котором HA туннелирует пакеты до MN, а MN туннелирует пакеты в обратном направлении до HA. HA расформирует туннелированный IP-пакет и перешлет его CN. При двунаправленном туннелировании от CN не требуется поддержки мобильного IP. Оптимизации маршрута MIPv6 1.6.3 Метод двунаправленного туннелирования решает проблемы треугольной маршрутизации и фильтрации на входе; тем не менее, сохраняется возможность субоптимальной маршрутизации, т. к. путь от MN до CN через HA может быть относительно долгим, даже если MN и CN расположены поблизости друг от друга. С MIPv6 ситуация, в которой путь через HA длиннее, чем прямой путь до CN, может быть разрешена с помощью метода, именуемого методом оптимизации маршрута. В рамках оптимизации маршрута MN посылает сообщения обновления привязки как HA, так и CN. В этом случае MN и CN могут осуществлять непосредственную связь и вносить коррективы с учетом изменений в CoA данного MN. Процедуры оптимизации маршрута определены в RFC 3775. Для этого требуется, чтобы MN инициировал процедуру обратного маршрута. Эта процедура дает CN определенные гарантии того, что сообщение к MN можно адресовать как заявленным временным адресом, так и домашним адресом. 1.6.4 Признается, что метод оптимизации маршрута имеет недостатки. В RFC 4651 представлены таксономия и анализ усовершенствований метода оптимизации маршрута MIPv6. В этом документе отмечается, что две проверки в рамках процедуры обратного маршрута могут привести к задержке при переключении, неприемлемой для многих приложений, работающих в реальном времени или интерактивном режиме, т. к. гарантии защиты и обратной маршрутизации могут быть недостаточными для приложений, чувствительных к защите, а периодическое обновление регистрации в узле-корреспонденте может предполагать скрытый служебный сигнал. Учитывая издержки и задержки, связанные с процедурой обратной маршрутизации, а также тот факт, что – по крайней мере для ATSC – ожидается, что CN и HN будут находиться сравнительно недалеко друг от друга, настоящее руководство рекомендует, чтобы IPS CN, которые используют режим оптимизации маршрутов мобильного IPv6, разрешали административное включение или выключение режима оптимизации маршрута при значении "выключено" по умолчанию. Ожидается, что созданная IETF Рабочая группа по расширениям мобильности для IPv6 предложит новые решения проблемы оптимизации маршрутов, в том числе требования, относящиеся к авиации.

Усовершенствования MIPv6 1.6.5 Если мобильный узел (MN) меняет свою точку подключения к сети, это изменение может вызвать задержку, потерю пакетов и в целом издержки трафика в сети.


Иерархический мобильный IPv6 (HMIPv6) 1.6.6 Одной из технологий, разработанных для решения этих проблем, является "иерархический мобильный IPv6 (HMIPv6)" (RFC 4140). RFC 4140 представляет расширения мобильного IPv6 и IPv6 "neighbour discovery", позволяющие решать вопросы локальной мобильности. HMIPv6 позволяет сократить объем передаваемых сигналов между MN, его CN и HA. HMIPv6 вводит концепцию точки привязки мобильности (MAP). MAP – это по существу локальный домашний агент для мобильного узла. Мобильный узел при входе в домен MAP (т. е. посещаемую сеть доступа) получает маршрутные уведомления с информацией об одной или нескольких локальных MAP. MN может увязать свое текущее местоположение, т. е. канальный временный адрес (LCoA), с адресом в подсети MAP, именуемым региональным временным адресом (RCoA). Выступая в роли локального HA, MAP будет получать все пакеты от имени обслуживаемого мобильного узла, инкапсулировать их и пересылать непосредственно на текущий адрес данного мобильного узла. Если мобильный узел изменяет свой текущий адрес в пределах локального домена MAP (LCoA), ему нужно лишь зарегистрировать новый адрес в MAP. RCoA не меняется до тех пор, пока MN остается в пределах домена MAP. RFC 4140 отмечает, что применение MAP не предполагает наличия постоянного HA; MN не должен иметь постоянного HoA или HA для того, чтобы знать о наличии HMIPv6 или использовать функции HMIPv6. Мобильный узлы, осведомленные о HMIPv6, могут использовать свои RCoA в качестве адресов отправителя без применения опции домашнего адреса. Таким образом RCoA можно использовать в качестве идентифицирующего адреса для верхних уровней. Благодаря этой технологии мобильный узел будет восприниматься узлом-корреспондентом как фиксированный узел при перемещении в пределах домена MAP. Такое использование RCoA не создает неудобств, связанных с мобильным IPv6 (т. е. не требуется возврата сообщений о привязках или опции домашнего адреса в HA), но позволяет мобильным узлам осуществлять локальное управление мобильностью (MM) при почти оптимальной маршрутизации. Тем не менее, такое использование RCoA не обеспечивает глобальной мобильности. Быстрая передача обслуживания для мобильного IPv6 (FMIPv6) 1.6.7 Еще одним усовершенствованием MIPv6 является "быстрая передача обслуживания для IPv6 (FMIPv6)" (RFC 4068). Режим FMIPv6 является попыткой уменьшить вероятность утери пакета путем использования процедуры переключения с малым временем ожидания. FMIPv6 призван оптимизировать передачу обслуживания путем получения информации для нового маршрутизатора доступа до отключения от предыдущего маршрутизатора доступа. Маршрутизаторы доступа запрашивают информацию у других маршрутизаторов доступа для получения данных о ближайших соседях, что ускоряет передачу обслуживания. После выбора нового маршрутизатора доступа устанавливается туннель между старым и новым маршрутизаторами. Предыдущий временный адрес (pCoA) увязывается с новым временным адресом (nCoA) таким образом, чтобы данные можно было туннелировать от предыдущего маршрутизатора доступа до нового маршрутизатора доступа во время передачи обслуживания. Сочетание HMIPv6 и FMIPv6 позволит улучшить работу MIPv6, но за счет повышения сложности. Мобильный IPv6 с посредником (PMIPv6) 1.6.8 При использовании протокола MIPv6, который описан выше, MN обновляет HA с помощью сообщений обновления привязки. Такой режим работы называют управлением мобильностью на базе узлов. Еще один вариант решений предусматривает управление мобильностью на базе сети провайдерами обслуживания в сети доступа с использованием мобильного IPv6 с посредником (PMIPv6) в каналах доступа, которые поддерживают или эмулируют сквозную доставку. При таком подходе к поддержке мобильности не требуется участия мобильного узла в обмене сигнальными сообщениями между этим узлом и домашним агентом в целях оптимизации предоставления обслуживания в сети доступа. Мобильный агент-посредник в сети связывается с домашним агентом и осуществляет управление мобильностью от имени мобильного узла, подключенного к сети. Базовыми функциональными объектами для PMIPv6 являются локальный узел управления мобильностью (LMA) и шлюз мобильного доступа (MAG). Локальный уровень управления


мобильностью отвечает за поддержание зоны деятельности мобильного узла и является топологической точкой привязки для префикса(ов) домашней сети мобильного узла. MAG является объектом, который осуществляет управление мобильностью от имени мобильного узла и находится в канале доступа, к которому привязан данный мобильный узел. MAG отвечает за отслеживание перемещений мобильного узла относительно канала доступа и за инициирование регистрации привязок в LMA мобильного узла. Сеть доступа, которая поддерживает мобильность на основе сети, не обязана знать об IPv6-возможности обслуживаемых ею узлов. IP-мобильность для узлов, обладающих функцией мобильного IP в стеке IPv6, а также для тех узлов, которые ее не имеют, будет поддерживаться с помощью реализации функции мобильного протокола IPv6 с посредником в сети. Преимущества PMIPv6 заключаются в возможности повторного использования функции домашнего агента и форматов связи для передачи сообщений о мобильности, а единый домашний агент будет выступать в роли мобильного агента для всех типов узлов IPv6. PMIPv6 типа HMIPv6 представляет собой локальное решение в области управления мобильностью, позволяющее уменьшить количество служебных сообщений в связи "воздух – земля". Сетевая мобильность (NEMO) 1.6.9 Мобильный протокол IPv6 поддерживает движение индивидуального узла в сети. Тем не менее, существуют сценарии, при которых необходимо поддерживать движение целой сети в ATN/IPS. Одним из примеров является APC, при которой обеспечение мобильной связи для каждого индивидуального пассажира было бы нерациональным использованием диапазона. Еще одним примером может быть наличие общего бортового маршрутизатора, поддерживающего различные типы трафика, при условии надлежащего решения проблем защиты. Расширение мобильного IPv6, который поддерживает эти сценарии, называется сетевой мобильностью (NEMO). В настоящем руководстве NEMO рассматривается в качестве одного из вариантов реализации в соответствии с RFC 3963. Операционная модель NEMO вводит новый объект - мобильный сетевой узел (MNN), представляющий собой узел в сети, которая движется как единица. Это может быть хост, который движется вместе с другими MNN, или мобильный маршрутизатор. Мобильный маршрутизатор работает как любой мобильный IP-хост в точке выходного интерфейса (с маршрутизатором фиксированного доступа). Мобильный маршрутизатор также согласовывает список префиксов с домашним агентом. Домашний агент использует этот список для пересылки пакетов, прибывающих для MNN, имеющих общий префикс, мобильному маршрутизатору. В точке интерфейса на входе (с мобильной сетью) мобильный маршрутизатор сообщает MNN один или несколько префиксов. Хотя на первый взгляд NEMO представляется достаточно простым расширением мобильного IP, существует ряд моментов, которые до сих пор изучают рабочие группы IETF. Эти моменты включают оптимизацию маршрутов NEMO, делегирование префиксов и управление ими.

1.7 РЕКОМЕНДАЦИИ ПО ЗАЩИТЕ 1.7.1 В настоящем разделе приводится обоснование требований в разделе 2.5 части I. Освещается история вопроса, если есть необходимость в дополнительных уточнениях, и даются общие рекомендации по реализации мер защиты.

Требования к реализации 1.7.2 Требования по реализации мер защиты должны вписываться в общие рамки архитектуры безопасности для IPv6, согласно которой все средства, поддерживающие IPv6, должны соответствовать требованиям RFC 4301. Хотя от всех узлов ATN/IPS требуется реализация протокола защиты сетевого трафика (IPsec) и протокола обмена ключами в Интернете, версия 2 (IKEv2), фактическое использование этих положений должно основываться на анализе угроз и уязвимостей системы.


Защита связи "земля – земля" IPsec в связи "земля – земля" 1.7.3 Базовым для безопасности в связи "земля - земля" является требование обеспечения защиты на сетевом уровне в объединенной сети ATN/IPS, реализуемое с помощью IPsec. IPsec создает границу между незащищенными и защищенными интерфейсами. IPsec обычно используется для формирования виртуальной частной сети (VPN) между шлюзами (NIST 800-77). Шлюзом может быть маршрутизатор или другое средство защиты, например брандмауэр. В таком контексте другими средствами защиты считаются узлы ATN/IPS. Модель "от шлюза до шлюза" защищает связь по сетям ATN/IPS между регионами или между государствами или организациями в конкретном регионе. IPsec может также использоваться в режиме "от хоста до шлюза", обычно для того, чтобы разрешить хостам в незащищенной сети получить доступ к защищенным ресурсам. IPsec также может применяться в конфигурации "от хоста до хоста", когда предоставляется защита приложений в режиме передачи данных между конечными системами. 1.7.4 В качестве мер обеспечения функционального взаимодействия в рамках объединенной сети ATN/IPS настоящее руководство рассматривает поддержку архитектуры безопасности IPsec, протокол инкапсу-ляции защищенных данных (ESP) и использование единого набора криптографических алгоритмов. Архитектура описана в RFC 4301. Вопросы ESP рассматриваются в RFC 4303, а криптографические алгоритмы, которые могут использоваться, оговорены в RFC 4835. Настоящее руководство по ATN/IPS дополнительно уточняет, что кодирование с помощью ESP является факультативным, однако аутентификация выполняется всегда. 1.7.5 Настоящее руководство устанавливает, что узлы ATN/IPS при работе в режиме "земля – земля" могут использовать протокол аутентификации заголовка IP (AH), как указано в RFC 4302. При этом признается, что AH может предусматриваться в отдельных изделиях, однако все реже используется в IPsec. В RFC 4301 говорится: "Статус положения о поддержке протокола AH понижен до "MAY" (факультативного), т. к. опыт показывает, что лишь в очень ограниченном числе случаев ESP не может предоставить требуемых мер защиты. Следует иметь в виду, что ESP можно использовать для обеспечения только целостности (без конфиденциаль-ности), так что он сопоставим с AH в большинстве контекстов". IKEv2 в связи "земля – земля" 1.7.6 Архитектура IPsec (RFC 4301) предполагает поддержку как ручного, так и автоматизированного управления ключами. По мере развития ATN/IPS частота ручного управления ключами будет уменьшаться. Поэтому в настоящем руководстве предусматривается, что узлы в условиях связи "земля – земля" реализуют протокол обмена ключами в Интернете-2 (IKEv2), оговоренный в RFC 4306, для автоматизированного управления ключами. IKEv2 является последней версией этого протокола. Спецификации IKEv2 не так сложны, как в первой версии протокола, что должно способствовать лучшей функциональной совместимости различных схем реализации. 1.7.7 Как и в случае с ESP, протокол IKEv2 требует использования набора обязательных алгоритмов для обеспечения совместимости. Настоящий протокол предусматривает использование узлами при ведении связи "земля – земля" криптографических алгоритмов, определенных в RFC 4307. Альтернативы IPsec/IKEv2 для защиты связи "земля – земля" 1.7.8 При определенных обстоятельствах может быть приемлемым использование альтернативных мер сетевой безопасности. Альтернативы IPsec могут применяться на канальном, транспортном или прикладном


уровнях. Документ NIST SP 800-772 описывает основные альтернативы, характеризует сильные и слабые стороны этих альтернатив и приводит ситуации, в которых они могут использоваться.

Защита связи "воздух – земля" IPsec в связи "воздух – земля" 1.7.9 Как и в отношении связи "земля – земля", для обеспечения функциональной совместимости при связи "воздух – земля" настоящее руководство рекомендует, чтобы узлы ATN/IPS поддерживали архитектуру безопасности IPsec и протокол ESP. Как и для наземной связи, архитектура соответствует положениям RFC 4301, а ESP – требованиям RFC 4835. Тем не менее, вместо того, чтобы использовать все криптографические алгоритмы, которые идентифицированы в RFC 4835, указываются специальные алгоритмы по умолчанию для аутентификации, а также для кодирования и аутентификации. Это делается с учетом ограниченной ширины полосы каналов связи "воздух – земля", а также во избежание появления неиспользованных кодов на платформе авионики. 1.7.10 Алгоритмом аутентификации, выбранным для использования, если также не выбрана функция конфиденциальности, является AUTH_HMAC_SHA2_256-128, указанный в RFC 4868. Этот алгоритм использует 256-битовый ключ для расчета тега хэш-кода аутентификации сообщений (HMAC) с помощью хэш-функции SHA-256. Тег усечен до 128 бит. Этот же алгоритм используется для обеспечения целостности в IKEv2, о чем говорится ниже. 1.7.11 Для шифрования ESP настоящее руководство рекомендует использовать стандарт криптогра-фической защиты (AES) в режиме Galois/Counter Mode (GCM). AES-GCM используется с 8-октетным значением контроля целостности (ICV) и длиной ключа 128, как указано в RFC 4106. AES-GCM является алгоритмом "комбинированного режима", который позволяет в рамках одной операции обеспечивать как конфиденциальность, так и аутентификацию. Алгоритмы комбинированного режима отличает более высокая эффективность по сравнению с методом последовательного применения шифрования и аутентификации. При использовании AES-GCM ICV состоит исключительно из тега аутентификации AES-GCM, а отдельный тег HMAC не применяется. IKEv2 в связи "воздух – земля" 1.7.12 В связи с тем, что при ведении связи "воздух – земля" ручное управление ключами непрактично, данное руководство рекомендует, чтобы узлы ATN/IPS использовали протокол обмена ключами в Интернет-2 (IKEv2), указанный в RFC 4306. Как и в случае с ESP, учитывая ограничения по ширине полосы, а также нежелательность неиспользованных кодов на платформе авионики, настоящее руководство рекомендует набор алгоритмов по умолчанию для использования в IKEv2. При выборе преобразователя следует, насколько это возможно, учитывать рекомендации Ассоциации воздушного транспорта (ATA), Рабочей группы по защите цифровой связи (DSWG), Комитета авиакомпании по электронной инженерии (AEEC) и Рабочей группы по защите линий передачи данных (DSEC), однако в настоящем руководстве указываются только те преобразователи, которые зарегистрированы в IANA. IKEv2 использует пять преобразователей. 1. Псевдослучайная функция (PRF), которая используется в IKEv2 для генерирования

материала ключей и для аутентификации ассоциации защиты IKE. В настоящем руководстве рекомендуется использовать в качестве PRF функцию PRF_HMAC_SHA_256, указанную в RFC 4868.

2. IKEv2 использует протокол обмена ключами Диффи-Хеллмана для получения общего для

участников связи секретного значения. Метод Диффи-Хеллмана предусматривает расчет

2. См. http://csoc.nist.gov/publication/nistpubs/800-77/sp800-77.pdf


дискретного логарифма с использованием арифметики конечного поля или эллиптических кривых. При использовании криптографии на эллиптических кривых обычно выбирают кривые основных характеристик или двоичные кривые. В данном руководстве сделан выбор в пользу кривой основных характеристик и рекомендуется использовать 233-битовую случайную группу ECP, как показано в RFC 4753.

3. Если для аутентификации объекта в IKEv2 используются сертификаты открытых ключей,

определенные данные при обмене IKEv2 должны быть подписаны. Настоящее руководство рекомендует для этого алгоритм эллиптической кривой для создания цифровой подписи (ECDSA) с использованием SHA-256 в качестве хэш-алгоритма на 256-битовой кривой основных характеристик, как указано в RFC 4754.

4. Аутентификационный обмен по IKEv2 имеет полезную нагрузку, которая шифруется с

защитой целостности. Настоящее руководство рекомендует использовать в качестве криптографического преобразователя IKEv2 AES-CBC со 128-битовыми ключами, как указано в RFC 3602.

5. Настоящее руководство рекомендует использовать для защиты целостности зашифрованной

полезной информации MAC-SHA-256-128, как предусмотрено в RFC 4868. 1.7.13 Упомянутый выше пакет алгоритмов вместе с AES-GCM, используемым для ESP-шифрования, составляет комплект "Suite-B-GCM-128", предусмотренный в RFC 4869. Ожидается, что этот комплект поступит в коммерческое серийное производство (COTS) и будет обеспечивать адекватную криптографическую защиту на период до 2030 года и последующие годы. Дополнительные рекомендации по выбору криптографических алгоритмов и размеров ключей см. в документе NIST SP 800-57. 1.7.14 Наряду с преимуществами серийного коммерческого производства, гибкости в выборе алгоритмов связи, механизмов аутентификации и других параметров, использование протокола IKEv2 приводит к увеличению количества служебных сообщений по сравнению со стандартным объемом в авиационных видах применения. IKEv2 требует обмена по крайней мере четырьмя сообщениями для установления сеансового ключа для связи "воздух – земля". Кроме того, алгоритмы шифрования в IKEv2 и ESP требуют увеличения размера сообщений. Это увеличение, возможно, не очень заметно в больших сообщениях, однако для коротких сообщений оно составляет существенную долю. Это немаловажный аспект применительно к линиям передачи данных с ограничениями по диапазону, однако ожидается, что данная проблема будет менее острой после перехода к высокоскоростным линиям передачи данных для передачи сообщений, связанных с безопасностью полетов. Защита сквозной связи "воздух – земля" 1.7.15 На рис. III-1-6 показаны варианты защиты сквозной связи "воздух – земля" в ATN/IPS. Для этого необходимо использовать IKEv2 и ESP IPsec. В настоящем руководстве также определены варианты для TLS и IKEv2 для защиты на прикладном уровне. Для всех случаев настоящее руководство определяет набор криптографических алгоритмов для использования по умолчанию. Защита сквозной связи "воздух – земля" на сетевом уровне 1.7.16 Как отмечается в пп. 1.7.9–1.7.14, для обеспечения защиты сквозной связи "воздух – земля" на сетевом уровне настоящее руководство рекомендует использование ESP вместе с IKEv2 для установления ключей. На рис. III-1-6 показан интерфейс CN с сервером, имеющим сертификат PKI. Выбор метода интерфейса производится на местном уровне. Это может быть интерфейс с базой данных сертификатов X.509 и списков отозванных сертификатов (CRL) с помощью облегченного протокола доступа к каталогам (LDAP) или другого


протокола управления сертификатами. Как отмечалось выше, для ESP и IKEv2 используется пакет алгоритмов "Suite-B", предусмотренный в RFC 4869. Используемый Национальным агентством безопасности Соединенных Штатов Америки профиль сертификатов и CRL "Suite B" идентифицирует сообщения управления сертификатами с помощью протокола CMS, как указано в RFC 2797, который является предпочтительным протоколом. Вопрос о выборе фактического метода аутентификации в административном домене решается на местном уровне и зависит от приложения. IKEv2 допускает применение совместно используемых ключей или цифровых сертификатов, причем более надежным методом считаются цифровые сертификаты. Совместно используемые ключи могут применяться в направлении "вниз", а цифровые сертификаты – в направлении "вверх". Поскольку у MN не существует практического способа независимой проверки CRL, в направлении "вверх" могут использоваться сертификаты с коротким сроком действия. В направлении "вниз" в случае использования цифровых сертификатов рекомендуется, чтобы MN вместо посылки фактического сертификата использовал формат "hash and URL". С помощью этого метода MN посылает URL сервера сертификатов PKI, в котором CN может получить свой сертификат. Этот метод использует сертификаты для аутентификации, если требуется надежная идентификация. Такой подход предпочтителен в условиях сквозной связи, хотя в этом случае можно использовать IKEv2 и расширяемый протокол аутентификации (ESP) с инфраструктурой аутентификации, авторизации и учета (AAA). Ожидается, что концепция моста PKI, выдвинутая Рабочей группой по защите цифровой связи (DSWG) Ассоциации воздушного транспорта (ATA), ускорит внедрение PKI на глобальной основе. Согласно концепции моста PKI каждый административный домен может направлять сертификат на центральный мост вместо проведения каждым административным доменом перекрестной сертификации с другими административными доменами. (В п. 1.7.25 содержатся дополнительные рекомендации относительно профилей PKI и политики сертификации).

Рис. III-1-6. Варианты защиты сквозной связи "воздух – земля"


Поставщикмобильного




IKEv2/IPsec(ESP),TLS,

IKEv2/Appl-Scty


Серверсертификатов

PKI



Защита сквозной связи "воздух – земля" на транспортном уровне 1.7.17 Настоящее руководство допускает использование мобильными узлами и узлами-корреспон-дентами в ATN/IPS протокола защищенной передачи данных (TLS), предусмотренного в RFC 5246. Таким образом, приложения, которые уже используют TLS, могут применяться в связи "воздух – земля" в сети ATN/IPS. При использовании TLS требуется следующий метод шифрования, который определен в RFC 4492: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 1.7.18 Этот метод шифрования предусмотрен для следующих вариантов: 1. Протокол защищенной передачи данных (TLS). Можно использовать версии 1.0 или 1.1. 2. Соглашение об обмене ключами с использованием эллиптической кривой Диффи-

Хеллмана (ECDH). 3. Алгоритм эллиптической кривой для создания цифровой подписи (ECDSA) для

аутентификации клиента. 4. Стандарт криптографической защиты (AES) с размером блока 128 в режиме сцепления

блоков шифртекста (CBC) для конфиденциальности. 5. Алгоритм криптографического хеширования (SHA), версия 1 для целостности (т. е. для

HMAC). 1.7.19 Этот метод шифрования выбран потому, что он имеет общие алгоритмы с предусмотренными для протоколов IPsec и IKEv2 в связи "воздух – земля". Следует учитывать, что этот метод шифрования является обязательным для серверов, и клиенты также могут использовать его для обеспечения соответствия требованиям RFC 4492. Защита сквозной связи "воздух – земля" на прикладном уровне 1.7.20 Настоящее руководство разрешает мобильным узлам и узлам-корреспондентам в ATN/IPS использовать меры защиты прикладного уровня на границе диалогового сервиса IPS. Этот альтернативный вариант предназначен для устаревших приложений ATN, которые уже использовали меры защиты прикладного уровня в сети ATN/OSI. В этом случае мобильные узлы и узлы–корреспонденты включают в сообщение о приложениях код аутентификации сообщений HMAC-SHA-256. Код HMAC-SHA-256 уже требуется для ESP и IKEv2, и поэтому такой вариант не предусматривает дополнительной криптографии. Тег HMAC, усеченный до 32 бит, рассчитывается через конкатенацию данных пользователя с порядковым номером отправления для защиты при повторе. Протокол IKEv2 является стандартным, и поэтому, если в связи "воздух – земля" используются меры защиты на прикладном уровне, IKEv2 также используется для определения ключей. Защита IP-сообщений провайдера сети доступа и мобильного обслуживания 1.7.21 На рис. III-1-7 показаны варианты защиты сообщений провайдера сети доступа (ASP) или провайдера подвижного обслуживания (MSP). Разграничение ASP и MSP используется в рабочих группах IETF для изучения вариантов применения прикладных инфраструктур AAA для защиты мобильной связи. Согласно RFC 4640 ASP – это сетевой оператор, обеспечивающий прямую пересылку IP-пакета конечному хосту и от него. MSP – это провайдер мобильного IPv6-обслуживания. На рисунке "AAA-NA-сервер" обозначает сеть доступа, а "AAA-MIP-сервер" – доступ к мобильному IP-обслуживанию.


Рис. III-1-7. Защита ASP или MSP

Защита сообщений мобильной IP-связи 1.7.22 В соответствии с RFC 3775 настоящее руководство рекомендует использовать IPsec для защиты мобильной IP-связи., как это предусмотрено в RFC 4877. RFC 4877 обновляет RFC 3776 и описывает варианты использования IKEv2 для автоматического управления ключами. В RFC 4877, в частности, описано, как можно использовать IKEv2 с EAP в качестве метода аутентификации. При использовании расширенной аутентификации в IKEv2 требуется дополнительный обмен после обменов IKE_SA_INIT и IKE_SA_AUTH. В этом случае MN не будет включать информацию аутентификации в обмен IKE_SA_AUTH, а включит информацию EAP в следующее сообщение. После этого HA взаимодействует с сервером AAA-MIP для завершения обмена аутентификацией и в случае успеха завершает обмен IKEv2. Защита сети доступа в связи "воздух – земля" 1.7.23 Мобильные узлы применяют меры защиты сети доступа. Меры защиты сети доступа связаны с контролем доступа в сеть и обычно реализуются с помощью инфраструктуры AAA. 1.7.24 Рабочие группы IETF по мобильности и другие организации, разрабатывающие стандарты, признают, что, хотя мобильный IPv6 и мобильный IPv6 с посредником первоначально проектировались без учета интеграции с инфраструктурой AAA, более эффективным было бы идентифицировать пользователей с помощью информации, хранимой на сервере AAA. Кроме того, использование инфраструктуры AAA может упростить выполнение таких функций инициализации, как динамическое конфигурирование других параметров (т. е. домашнего адреса и адреса домашнего агента) в целях регистрации мобильного обслуживания. EAP между MN и аутентификатором может осуществляться с помощью протокола канального уровня сети доступа или в связи с IKEv2, как было описано в отношении защиты сообщений IP-связи. EAP между аутентификатором и сервером AAA работает через протоколы RADIUS (RFC 2865) или DIAMETER (RFC 3588).


AAA-MIP-сервер

AAA-NA-серверЗащита сетевого

доступа

Провайдермобильного


Провайдерсети доступа

(ASP) ЗащитаMIPv6



Профиль инфраструктуры открытых ключей и политика в области сертификатов 1.7.25 Настоящее руководство рекомендует, чтобы узлы ATN/IPS использовали профиль сертификатов инфраструктуры открытых ключей и списка отозванных сертификатов (CRL) в формате Интернет X.509, как указано в RFC 5280, и политику в области сертификатов инфраструктуры открытых ключей и рамки практики сертификатов в формате Интернет X.509, как указано в RFC 3647. В настоящем руководстве отмечается, что Рабочая группа по защите цифровой связи (DSWG) Ассоциации воздушного транспорта (ATA) разработала политику в области сертификатов (Спецификация 42 ATA) для использования авиационным сообществом. Спецификация 42 ATA указывает профили сертификатов и CRL, подходящие к применению в авиации. Эти профили являются более конкретными, чем в RFC 5280, но не противоречат этому документу. Профили в спецификации 42 ATA совместимы с PKI-мостом аэрокосмической отрасли. Функциональная совместимость с операционным PKI-мостом авиационно-космической и оборонной отраслей позволит загрузить существующую инфраструктуру вместо того, чтобы создавать уникальную инфраструктуру для ATN/IPS, и более эффективно обеспечивать интероперабельность и единообразие политики в многонациональной и многоэлементной среде, характерной для деятельности авиационно-космической и оборонной отраслей. Общие рекомендации по реализации мер защиты 1.7.26 Многие государственные учреждения разрабатывают дополнительные рекомендации и профили для реализации мер защиты. Серия рекомендаций NIST 800 в Соединенных Штатах Америки является примером общих рекомендаций по защите, охватывающих широкий диапазон вопросов. 1.7.27 Многие проекты IETF, касающиеся Интернета, посвящены мерам безопасности. Особый интерес в этой связи представляют два информационных RFC: RFC 4942 и RFC 4864. В RFC 4942 дается обзор проблем защиты, связанных с IPv6. Эти проблемы сгруппированы по трем общим категориям: проблемы, связанные с самим протоколом IPv6, проблемы механизмов перехода и проблемы, связанные с применением IPv6. В RFC 4864 отмечается, что в IPv6 не требуется трансляции сетевых адресов (NAT), и описано, как использование механизмов локальной защиты сети (LNP) поможет реализовать выгоды, связанные с NAT. В частности, RFC 4864 рассказывает о том, как можно использовать инструменты IPv6 – конфиденциальные адреса, уникальные локальные адреса, делегирование DHCPv6-префиксов и не оставляющие следа IPv6-адреса – для реализации предполагаемых преимуществ NAT в области защиты, включая следующие: шлюз между Интернетом и внутренней сетью; простые меры защиты (производные от фильтрации пакетов на основе данных о состоянии соединения); отслеживание пользователя/приложения; сокрытие конфиденциальной информации и топологии; независимый контроль адресации в частной сети; сохранение пула глобальных адресов; и множественная нумерация и перенумерование. RFC 4864 описывает дополнительные преимущества собственно IPv6 и универсальной уникальной адресации, включая следующие: универсальные соединения "каждого с каждым", автоконфигурация, заложенная функция многоадресного обслуживания, повышенный уровень защиты, мобильность и объединение сетей.

1.8 ПРОТОКОЛ РЕЧЕВОЙ СВЯЗИ В ИНТЕРНЕТЕ (VoIP) Примечание. EUROCAE выпускает серию документов по VoIP для ОрВД, которые можно использовать в качестве дополнительных спецификаций. Этим документам присвоены номера ED 136, ED 137, ED 138. 1.8.1 Основными преимуществами использования сети коммутации пакетов для передачи оцифрованных речевых сообщений являются: — эффективность распределения полосы частот; — возможность использования современных методов сжатия речевого сигнала;


— экономические выгоды в результате совместного использования сетевых ресурсов; — сокращение затрат; — повышение надежности сетей коммутации пакетов; — возможность использования множественных логических соединений на одном физическом

канале.

Стандарты и протоколы 1.8.2 Существует два рамочных протокола для стандартизации VoIP – ITU-T H.323 и IETF SIP. Хотя оба протокола могут использоваться для приложений VoIP, основная направленность этих протоколов различается. В H.323 акцент делается на обработку речевых и мультимедийных сообщений, включая дополнительные сервисы, тогда как SIP создавался как общий протокол транзакций для установления сеансов без увязки с какой-либо конкретной средой (аудио или видео). Соответствующие протоколы более подробно рассматриваются ниже. ITU-T H.323 1.8.3 Как видно из рис. III-1-8, протокол H.323 работает на прикладном уровне для поддержки мультимедийных протоколов, протоколов передачи данных и сигнализации. На рис. III-1-8 также показаны различные протоколы, используемые для передачи мультимедийного трафика в сетях TCP/UDP/IP.

Рис. III-1-8. Базовая архитектура H.323

Аудиокодеки

G.711G.728G.729

Видеокодеки

H.261H.263

RTCP(

)

протоколуправленияпередачейв реальномвремени

T.120(

)в реальномвремени

T.130(

)

аудио-визуальныйконтроль

H.225.0RAS

Q.931(

)сигнализация

вызова

H.235( )

H.245(

)

защита

сигнализацияконтроля

RTP

Мультимедийные сообщения Передача данных Сигнализация

TCP ( )протокол управления передачей

IP ( ) v4 v6протокол Интернет или

Серия H.450.1 (дополнительные

сервисы)


Мультимедийные 1.8.4 Эта группа протоколов осуществляет преобразование аналоговых (например, речевых) и цифровых сигналов, которые подаются или принимаются из UDP/IP сети. Некоторые из этих протоколов включают: — аудио кодеки – они сжимают цифровой речевой сигнал для передачи при малой пропускной

способности полосы частот и разворачивают цифровые речевые сообщения, полученные из сети, для ввода в аудиоустройства пользователя (например, колонки, наушники);

— видео кодеки – они сжимают цифровой видеосигнал для передачи в условиях ограничений

по ширине полосы и разворачивают цифровые видеосообщения, полученные из сети, для ввода в видеоустройства пользователя; и

— RTP (протокол передачи в реальном времени) и протокол управления RTP (RTCP) – это

протоколы управления для полезной информации, подаваемой в сеть. RTP регулирует сквозную доставку аудио- и видеосообщений в реальном времени по IP-сети. RTCP регулирует контрольные сервисы при мультимедийных передачах и отслеживает качество их распределения, включая синхронизацию приемников.

Передача данных 1.8.5 Этот класс протоколов обеспечивает многоадресную передачу данных в реальном времени и прикладное обслуживание в IP-сетях (например, коллективное принятие решений с обменом видео- информацией, речевыми сообщениями и данными). Данные, передаваемые между универсальными приложениями и IP-сетью, обрабатываются с помощью протокола ITU-T T.120, который может работать с различными видами транспортировки, включая PSTN и ISDN. 1.8.6 ITU-T T.130 – это разрабатываемый в настоящее время протокол, предназначенный для управления аудиовизуальными сеансами при мультимедийных конференциях в реальном времени, а также для обеспечения высокого уровня QoS. 1.8.7 Сигнализация — ITU-T H.225.0 сигнализация вызова используется для установления соединений и

сигнализации вызовов между оконечными точками H.323 (терминалами и шлюзами), которые передаются в виде данных в реальном времени по сети TCP/UDP/IP. H.225.0 использует ITU-T Q.931 для инициализации и завершения вызова.

— ITU-T H.245 контрольная сигнализация используется для обмена в сквозном режиме

сообщениями между оконечными точками H.323. Контрольные сообщения передаются по каналам логического контроля H.245 и ретранслируются между оконечными точками конференц-связи.

— ITU-T H.235 обеспечивает в рамках H.323 такие меры защиты, как аутентификация,

шифрование, целостность и неотказуемость. ITU-T H.450.1 занимается процедурами и сигнализацией между объектами H.323 для контроля дополнительных сервисов. Другие протоколы серии ITU-T H.450 (например, H.450.2-12) предоставляют специальные дополнительные сервисы (например, перевод соединения, удержание вызова, ожидание вызова и приоритизация вызова).


MGCP/MEGACO 1.8.8 На рис. III-1-9 показан пакет протоколов SIP. SIP – это протокол управления прикладного уровня, предоставляющий расширенную функциональность сигнализации и контроля для широкомасштабной мультимедийной связи. SIP является альтернативой H.323 и позволяет устанавливать, модифицировать и прекращать сеансы мультимедийной связи, которые могут использоваться для IP-телефонии. В контексте других протоколов SIP является важным компонентом построения законченной мультимедийной архитектуры, как показано на рис. III-1-10. К ним относятся RTP для передачи данных в реальном времени и обеспечения QoS, RTSP для управления потоковой средой, MEGACO для управления шлюзами в PSTN и SDP для описания сеансов мультимедийной связи. Эти сеансы включают мультимедийные Интернет-конференции, телефонные вызовы через Интернет и мультимедийное распределение с помощью TCP/UDP/IPv4 или IPv6, как показано на рис. III-1-11.

1.9 СХЕМЫ РЕАЛИЗАЦИИ IPS

Обмен данными онлайн (OLDI) 1.9.1 Процедура обмена данными онлайн (OLDI) в сочетании с протоколом передачи сообщений о полете (FMTP) позволяет удовлетворять эксплуатационные требования AIDC в части координации и передачи управления воздушными судами между соседними органами управления воздушным движением. Взаимосвязь между сообщениями AIDC и OLDI описана в добавлении к главе 1 части VI "Руководства по применению линий передачи данных в целях обслуживания воздушного движения (Doc 9694)". Спецификации OLDI не делают применение сообщений OLDI обязательным, но устанавливают требования, которые должны выполняться при реализации таких средств. Если сообщения OLDI используются в результате мер регулирования или на основе двустороннего соглашения между органами управления воздушным движением, то требования, указанные как обязательные в спецификациях этих сообщений, становятся обязательными для выполнения. Это делается для того, чтобы выполнить функцию таких сообщений и обеспечить совместимость систем. Процедура координации требует, чтобы системы определяли, осуществляется ли передача данных в соответствии с письмами о договоренности (LoA). В спецификации OLDI процесс проверки такого соответствия назван "фильтрацией". База данных, используемых для фильтрации, может включать следующие элементы: — согласованные точки координации; — допустимые (или недопустимые) эшелоны полета, которые могут также ассоциироваться с

координационными точками; — аэродромы вылета; — пункты назначения; — согласованные прямые маршруты; — лимиты времени и/или расстояния до COP, после превышения которых любое

координационное сообщение считается нестандартным; и — любые другие условия, согласованные в двустороннем порядке.


Рис. III-1-9. Пакет протоколов SIP

Рис. III-1-10. Интерфейс VoIP с PSTN через MEGACO

PSTN

ШлюзMEGACO

IP-сеть

Пакет SIP

Управление приложениями и системойПередачаданных

например, сиспользо-ванием

(

RTSP)

PINT

(

PSTNSs7,

ATS – QSIG)

интерфейс ссигнализацией

, например

ОборудованиеAV I/O

SIP Методы

Передача вызова конференции задержкавызова контроль вызовов и другиедополнительные сервисы

/ //

Заголовкирасширения

Тело сообщения например, ( SDP) RTP

Аудио Видео

TCP UDP

IP


Рис. III-1-11. VoIP с SIP

1.9.2 Все элементы в этом списке можно комбинировать для определения более сложных условий. Формат сообщений, подлежащих передаче и получению (см. документ ИКАО "Правила аэронавигационного обслуживания. Организация воздушного движения (PANS-ATM)" (Doc 4444) или документ стандартов Евроконтроля для представления обмена данными ОВД (ADEXP)), должен согласовываться на двусторонней основе. Адреса органов ОВД, предоставляющих обслуживание, должны согласовываться на двустороннем уровне и отличаться от адресов других подразделений, с которыми данные органы ОВД уже связаны или планируют быть связанными. Адреса подразделений ОВД являются частью сообщения OLDI. Протокол передачи сообщений о полете (FMTP) 1.9.3 Протокол передачи сообщений о полете (FMTP) представляет собой коммуникационный стек, основанный на TCP/IPv6 и предназначенный для поддержки передачи сообщений OLDI. FMTP является машиной состояний, которая обеспечивает установление соединений и управление сеансами. Каждая система FMTP требует значение идентификации, подлежащее обмену при установлении соединения. Такие значения идентификации должны согласовываться на двустороннем уровне и отличаться от значений других подразделений, с которыми органы ОВД уже соединены или планируют быть соединенными. 1.9.4 Спецификация FMTP предполагает передачу символов ASCII, однако конкретные схемы реализации этого протокола могут включать и другие наборы символов или двоичные передачи. Более полный инструктивный материал по FMTP можно получить в Евроконтроле на следующем веб-сайте: http://www.eurocontrol.int/communications/public/standard_page/com_network.html

SIP-сервер

SIP/TCP UDPили

RTP/UDP

IP-сеть IP-сеть

IP-сеть


Тестирование OLDI/FMTP 1.9.5 Евроконтроль разработал программу тестирования "EUROCONTROL inter centre test tool (ETIC)" для оценки схем реализации OLDI/FMTP и составления проверочных сценариев. Эту программу можно получить по запросу по следующему адресу: [email protected]. AMHS 1.9.6 Система AMHS уже получила эксплуатационный статус с TCP/IP в Европейском и Североамериканском регионах. Следует иметь в виду, что европейские схемы реализации предусматривают использование IPv6 для взаимодействия на межсетевом уровне в соответствии с частью II настоящего документа.

______________________

III-ДОБ-1

ДОБАВЛЕНИЕ к части III

СПРАВОЧНЫЕ ДОКУМЕНТЫ

СТАНДАРТЫ И ПРОТОКОЛЫ IETF Перечисленные ниже документы имеются в открытом доступе по адресу http://www.ietf.org и являются частью настоящего руководства в той мере, в какой это в нем определено. В случае расхождений между указанными здесь документами и содержанием настоящего руководства положения руководства имеют преобладающую силу. Запросы комментариев (RFC) netlmm-mn-ar-if Сетевой локализованный интерфейс управления мобильностью между мобильным узлом и

шлюзом доступа к мобильной связи, май 2007 RFC 768 Протокол пользовательских датаграмм, август 1980 RFC 793 Протокол управления передачей (TCP), сентябрь 1981 RFC 1006 Функционирование протокола транспортного уровня по ISO над протоколом TCP, май 1987 RFC 1122 Требования к хостам Интернет – коммуникационные уровни RFC 1123 Требования к хостам Интернет – прикладные и служебные протоколы RFC 1323 Расширения TCP для повышения производительности, май1992 RFC 1981 Поиск путей передачи максимального пакета (MTU) для IP, версия 6, август 1996 RFC 2126 Функционирование протокола транспортного уровня по ISO над протоколом TCP, март 1997 RFC 2385 Защита сеансов BGP с использованием варианта Signature TCP MD5 RFC 2460 Спецификация протокола Интернет, версия 6 (IPv6), декабрь 1998 RFC 2474 Определение поля дифференцированного обслуживания (поля DS) в заголовках IPv4 и IPv6,

декабрь 1998 RFC 2475 Архитектура дифференцированного обслуживания RFC 2488 Расширение возможностей TCP в каналах спутниковой связи, январь 1999 RFC 2597 PHB при гарантированной пересылке RFC 2858 Многопротокольные расширения для протокола граничного шлюза (BGP-4), июнь 2000 RFC 3095 Устойчивое сжатие заголовков (ROHC): рамки и четыре профиля; RTP, UDP, ESP и несжатый RFC 3241 Устойчивое сжатие заголовков (ROHC) при использовании PPP RFC 3246 PHB (пошаговое поведение) при ускоренной пересылке RFC 3602 Криптографический алгоритм AES-CBC и его использование с IPsec RFC 3647 Политика в области сертификатов инфраструктуры открытых ключей формата Интернет X.509

и рамки практики сертификации RFC 3775 Поддержка мобильности в IPv6, июнь 2004 RFC 3963 Базовый протокол поддержки сетевой мобильности (NEMO) RFC 4106 Применение режима вычисления в поле Galois (GCM) при инкапсуляции защищенных данных

(ESP) IPsec RFC 4213 Базовые механизмы перехода для хостов и маршрутизаторов IPv6 RFC 4271 Протокол граничного шлюза 4 (BGP-4), январь 2006 RFC 4291 Архитектура адресации IP версии 6, февраль 2006 RFC 4301 Архитектура защиты для Интернет-протокола, декабрь, 2005 RFC 4302 Заголовок аутентификации Интернет-протокола (IP), декабрь 2005 RFC 4303 IP-инкапсуляция защищенных данных (ESP), декабрь 2005

III-ДОБ-2 Руководство по ATN, использующей стандарты и протоколы IPS

RFC 4306 Протокол обмена ключами в Интернете, версия 2 (IKEv2), декабрь 2005 RFC 4307 Криптографические алгоритмы для использования с протоколом обмена ключей в Интернете,

версия 2 (IKEv2), декабрь 2005 RFC 4443 Протокол управляющих сообщений в Интернете (ICMPv6) для протокола Интернет, версия 6

(IPv6), март 2006 RFC 4492 Пакеты шифров криптографии эллиптической кривой (ECC) для протокола защищенной

передачи данных (TLS), май 2006 RFC 4555 Протокол мобильности и множественной адресации (MOBIKE) IKEv2, июнь 2006 RFC 4753 Группы протокола управления шифрованием (ECP) для IKE и IKEv2 RFC 4754 Аутентификация IKE и IKEv2 с использованием алгоритма эллиптической кривой для создания

цифровой подписи (ECDSA) RFC 4830 Изложение проблемы локализованного управления мобильностью на основе сетей (NETLMM),

апрель 2007 RFC 4831 Цель локализованного управления мобильностью на основе сетей (NETLMM), апрель 2007 RFC 4835 Требования к использованию криптографического алгоритма для инкапсуляции защищенных

данных (ESP) и заголовка аутентификации (AH), апрель 2007 RFC 4843 IPv6-префикс для немаршрутизируемых криптографических хэш-идентификаторов (ORCHID) RFC 4868 Использование HMAC-SHA-256, HMAC-SHA-384 и HMAC-SHA-512 с IPsec RFC 4877 Использование мобильного IPv6 с IKEv2 и пересмотренная архитектура IPsec RFC 4996 Устойчивое сжатие заголовков (ROHC): профиль для TCP/IP (ROHC-TP) RFC 5246 Протокол защищенной передачи данных (TSL), версия 1.2 RFC 5280 Профиль сертификата инфраструктуры открытых ключей формата Интернет X.509 и списка

отозванных сертификатов (CRL) СООТВЕТСТВУЮЩИЕ ИЗДАНИЯ ИКАО В случае расхождений между настоящим руководством и положениями Приложения 10 положения Приложения 10 имеют преобладающую силу. Приложение 1. "Правила полетов". Приложение 3. "Метеорологическое обеспечение международной аэронавигации". Приложение 10. "Авиационная электросвязь", том III "Системы связи", часть I "Системы передачи цифровых

данных". Приложение 11. "Обслуживание воздушного движения". Правила аэронавигационного обслуживания "Организация воздушного движения" (PANS-ATM) (Doc 4444). Руководства ИКАО Руководство по применению линий передачи данных в целях обслуживания воздушного движения (Doc 9694) Руководство по техническим положениям для сети авиационной электросвязи (ATN) (Doc 9705) Комплексное руководство по сети авиационной электросвязи (ATN) (Doc 9739) Руководство по подробным техническим спецификациям для сети авиационной электросвязи (ATN), использующей стандарты и протоколы ISO/OSI (Doc 9880) (подготавливается)

Часть III. Инструктивный материал Добавление. Справочные документы III-ДОБ-3

СПЕЦИФИКАЦИИ ЕВРОКОНТРОЛЯ Перечисленные ниже документы находятся в открытом доступе по адресу: http://www.eurocontrol.int/ses и являются частью настоящего руководства в той мере, в какой это в нем определено. В случае расхождений между указанными здесь документами и содержанием настоящего руководства положения руководства имеют преобладающую силу. EUROCONTROL-SPEC-0100-EUROCONTROL Спецификации функциональной совместимости и требования к характеристикам для протокола передачи сообщений о полете (FMTP), издание 2.0, июнь 2007 EUROCONTROL-SPEC-0106-EUROCONTROL Спецификации для обмена данными онлайн (OLDI), издание 4.1, январь 2008

— КОНЕЦ —

�

�

Documents

C : > 2 > 4 A B 2 > ? > A 5 B 8 0 2 8 0 F 8 > = = > 9 ATN ...dspk.cs.gkovd.ru/library/data/9896_ru.pdf · AMHS Система обработки сообщений ОВД ... IPS