Механизм аутентификации NTP

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

Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0.

Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.

Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения. Системная переменная peer.hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована.

Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна).

Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования.

Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование.

Метки потоков

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

Поток это последовательность пакетов, посылаемых отправителем определенному адресату, при этом предполагается, что все пакеты данного потока должны быть подвергнуты определенной обработке. Характер этой специальной обработки может быть передан маршрутизатору посредством протокола управления или внутри самих пакетов, например, в опции hop-by-hop.

Допускается несколько потоков между отправителем и получателем, а также обмен, не ассоциированный ни с одним из потоков. Поток однозначно описывается комбинацией адреса отправителя и ненулевой меткой потока. Пакеты, не принадлежащие ни одному из потоков, имеют метку равную нулю.

Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - FFFFFF. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.

Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации.
Маршрутизаторы и узлы- адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными.

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

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

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

Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.

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

Международное соглашение об именах почтовых ящиков

Согласно договоренности имена международных почтовых ящиков специфицированы в соответствии модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7:

UTF-7 использует символ "+" для смещения; это вызывает конфликт с обычным применением "+" в именах почтовых ящиков, в частности в именах групп новостей USENET.

Кодировка UTF-7 базируется на BASE64, где используется символ "/", что вступает в конфликт с применением "/" в качестве популярного иерархического разделителя.

UTF-7 запрещает использование "\"; что противоречит применению "\" в качестве популярного разделителя.

UTF-7 запрещает использование "~", это вступает в конфликт с тем, что некоторые серверы рассматривают этот символ, как указатель на базовый каталог (home).

UTF-7 допускает разнообразные формы представления одних и тех же строк, в частности, печатные символы US-ASCII могут использоваться в закодированной форме.

В модифицированном UTF-7, печатные символы US-ASCII за исключением "&" представляются в исходном виде; то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7e. Символ "&" (0x26) представляется в виде двух октетной последовательности "&-". Все другие символы (значения октетов 0x00-0x1f, 0x7f-0xff, и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя.

Символ "&" используется для перехода к модифицированной кодировке BASE64 а "-" для возврата назад к US-ASCII. Все имена начинаются с US-ASCII, и должны завершаться US-ASCII (то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом "-"). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках: ~peter/mail/&ZeVnLIqe-/&U,BTFw-

Вся управляющая информация для контроля

4.4.13.1 Управляющая база данных MIB

Семенов Ю.А. (ГНЦ ИТЭФ)

Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks).

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

Согласно нормативам MIB управляющая информация делится на восемь категорий (см. также рис. 4.4.13.1.1):

MIB-категория включает в себя информацию о

MIB-категория	Описание	Код
system	Операционная система ЭВМ или маршрутизатора.	1
Interfaces	Сетевой интерфейс.	2
addr.trans	Преобразование адреса (напр., с помощью ARP).	3
IP	Программная поддержка протоколов Интернет.	4
ICMP	Программное обеспечение ICMP-протокола.	5
TCP	Программное обеспечение TCP-протокола.	6
UDP	Программное обеспечение UDP-протокола.	7
EGP	Программное обеспечение EGP-протокола.	8
SNMP	Программное обеспечение SNMP-протокола.	11

Таблица 4.4.13.1.1. Системные переменные MIB

Системная переменная	Описание	Код
Sysdescr	Текстовое описание объекта;	1
Sysobjectid	Идентификатор производителя в рамках дерева 1.3.6.1.4.1	2
Sysuptime	Время с момента последней загрузки системы (timeticks);	3
Syscontact	Имя системного менеджера и способы связи с ним;	4
Sysname	Полное имя домена;	5
Syslocation	Физическое местоположение системы;	6
Sysservice	Величина, которая характеризует услуги, предоставляемые узлом (сумма номеров уровней модели OSI);	7

Таблица 4.4.13.1.2. Переменные IFtable (интерфейсы)

Переменная описания интерфейсов (iftable)	Тип данных	Описание	ifEntry
IFindex	integer	Список интерфейсов от 1 до ifnumber.	1
IfDescr	displaystring	Текстовое описание интерфейса.	2
IfType	integer	Тип интерфейса, например, 6 - ethernet; 9 - 802.5 маркерное кольцо; 23 - PPP; 28 - SLIP.	3
IfNumber	integer	Число сетевых интерфейсов.
IfMTU	integer	mtu для конкретного интерфейса;	4
IfSpeed	gauge	Скорость в бит/с.	5
IfPhysaddress	physaddress	Физический адрес или строка нулевой длины для интерфейсов без физического адреса (напр. последовательный).	6
IfAdminStatus	[1...3]	Требуемое состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.	7
IfOperStatus	[1...3]	Текущее состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.	8
IfLastchange	timeticks	Sysuptime, когда интерфейс оказался в данном состоянии.	9
IfInOctets	counter	Полное число полученных байтов.	10
IfInUcastpkts	counter	Число пакетов, доставленных на верхний системный уровень (unicast).	11
IfInNUcastpkts	counter	Число пакетов, доставленных на верхний системный уровень (unicast).	12
IfInDiscads	counter	Число полученных но отвергнутых пакетов.	13
IfInErrors	counter	Число пакетов, полученных с ошибкой;	14
IfInUnknownProtos	counter	Число пакетов, полученных с ошибочным кодом протокола;	15
IfOutOctets	counter	Число отправленных байтов;	16
IfOutUcastPkts	counter	Число unicast- пакетов, полученных с верхнего системного уровня;	17
IfOutNucastPkts	counter	Число мультикастинг- и широковещательных пакетов, полученных с верхнего системного уровня;	18
IfOutDiscads	counter	Количество отвергнутых пакетов из числа отправленных;	19
IfOutErrors	counter	Число отправленных пакетов, содержащих ошибки;	20
IfOutQlen	gauge	Число пакетов в очереди на отправку;	21

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

Название объекта	Цифра-точечное представление
org	1.3
dod	1.3.6
internet	1.3.6.1
directory	1.3.6.1.1
mgmt	1.3.6.1.2
experimental	1.3.6.1.3
private	1.3.6.1.4
enterprises	1.3.6.1.4.1
security	1.3.6.1.5
snmpV2	1.3.6.1.6
snmpDomains	1.3.6.1.6.1
snmpProxys	1.3.6.1.6.2
snmpModules	1.3.6.1.6.3
snmpMIB	1.3.6.1.6.3.1
snmpMIBObjects	1.3.6.1.6.3.1.1
snmpTraps	1.3.6.1.6.3.1.1.5
mib-2	1.3.6.1.2.1
ifMIB	1.3.6.1.2.1.31
interfaces	1.3.6.1.2.1.2
ifMIBObjects	1.3.6.1.2.1.31.1
ifConformance	1.3.6.1.2.1.31.2
ifTableLastChange	1.3.6.1.2.1.31.1.5
ifXTable	1.3.6.1.2.1.31.1.1
ifStackTable	1.3.6.1.2.1.31.1.2
ifStackLastChange	1.3.6.1.2.1.31.1.6
ifRcvAddressTable	1.3.6.1.2.1.31.1.4
ifTestTable	1.3.6.1.2.1.31.1.3
ifXEntry	1.3.6.1.2.1.31.1.1.1
ifName	1.3.6.1.2.1.31.1.1.1.1
ifInMulticastPkts	1.3.6.1.2.1.31.1.1.1.2
ifInBroadcastPkts	1.3.6.1.2.1.31.1.1.1.3
ifOutMulticastPkts	1.3.6.1.2.1.31.1.1.1.4
ifOutBroadcastPkts	1.3.6.1.2.1.31.1.1.1.5
ifLinkUpDownTrapEnable	1.3.6.1.2.1.31.1.1.1.14
ifHighSpeed	1.3.6.1.2.1.31.1.1.1.15
ifPromiscuousMode	1.3.6.1.2.1.31.1.1.1.16
ifConnectorPresent	1.3.6.1.2.1.31.1.1.1.17
ifAlias	1.3.6.1.2.1.31.1.1.1.18
ifCounterDiscontinuityTime	1.3.6.1.2.1.31.1.1.1.19
ifStackEntry	1.3.6.1.2.1.31.1.2.1
ifStackHigherLayer	1.3.6.1.2.1.31.1.2.1.1
ifStackLowerLayer	1.3.6.1.2.1.31.1.2.1.2
ifStackStatus	1.3.6.1.2.1.31.1.2.1.3
ifRcvAddressEntry	1.3.6.1.2.1.31.1.4.1
ifRcvAddressAddress	1.3.6.1.2.1.31.1.4.1.1
ifRcvAddressStatus	1.3.6.1.2.1.31.1.4.1.2
ifRcvAddressType	1.3.6.1.2.1.31.1.4.1.3
ifTestEntry	1.3.6.1.2.1.31.1.3.1
ifTestId	1.3.6.1.2.1.31.1.3.1.1
ifTestStatus	1.3.6.1.2.1.31.1.3.1.2
ifTestType	1.3.6.1.2.1.31.1.3.1.3
ifTestResult	1.3.6.1.2.1.31.1.3.1.4
ifTestCode	1.3.6.1.2.1.31.1.3.1.5
ifTestOwner	1.3.6.1.2.1.31.1.3.1.6
ifGroups	1.3.6.1.2.1.31.2.1
ifCompliances	1.3.6.1.2.1.31.2.2
ifGeneralInformationGroup	1.3.6.1.2.1.31.2.1.10
ifFixedLengthGroup	1.3.6.1.2.1.31.2.1.2
ifHCFixedLengthGroup	1.3.6.1.2.1.31.2.1.3
ifPacketGroup	1.3.6.1.2.1.31.2.1.4
ifHCPacketGroup	1.3.6.1.2.1.31.2.1.5
ifVHCPacketGroup	1.3.6.1.2.1.31.2.1.6
ifRcvAddressGroup	1.3.6.1.2.1.31.2.1.7
ifStackGroup2	1.3.6.1.2.1.31.2.1.11
ifCounterDiscontinuityGroup	1.3.6.1.2.1.31.2.1.13
ifGeneralGroup	1.3.6.1.2.1.31.2.1.1
ifTestGroup	1.3.6.1.2.1.31.2.1.8
ifStackGroup	1.3.6.1.2.1.31.2.1.9
ifOldObjectsGroup	1.3.6.1.2.1.31.2.1.12
ifCompliance2	1.3.6.1.2.1.31.2.2.2
ifCompliance	1.3.6.1.2.1.31.2.2.1
ifNumber	1.3.6.1.2.1.2.1
ifTable	1.3.6.1.2.1.2.2
ifEntry	1.3.6.1.2.1.2.2.1
ifIndex	1.3.6.1.2.1.2.2.1.1
ifDescr	1.3.6.1.2.1.2.2.1.2
ifType	1.3.6.1.2.1.2.2.1.3
ifMtu	1.3.6.1.2.1.2.2.1.4
ifSpeed	1.3.6.1.2.1.2.2.1.5
ifPhysAddress	1.3.6.1.2.1.2.2.1.6
ifAdminStatus	1.3.6.1.2.1.2.2.1.7
ifOperStatus	1.3.6.1.2.1.2.2.1.8
ifLastChange	1.3.6.1.2.1.2.2.1.9
ifInOctets	1.3.6.1.2.1.2.2.1.10
ifInUcastPkts	1.3.6.1.2.1.2.2.1.11
ifInNUcastPkts	1.3.6.1.2.1.2.2.1.12
ifInDiscards	1.3.6.1.2.1.2.2.1.13
ifInErrors	1.3.6.1.2.1.2.2.1.14
ifInUnknownProtos	1.3.6.1.2.1.2.2.1.15
ifOutOctets	1.3.6.1.2.1.2.2.1.16
ifOutUcastPkts	1.3.6.1.2.1.2.2.1.17
ifOutNUcastPkts	1.3.6.1.2.1.2.2.1.18
ifOutDiscards	1.3.6.1.2.1.2.2.1.19
ifOutErrors	1.3.6.1.2.1.2.2.1.20
ifOutQLen	1.3.6.1.2.1.2.2.1.21
ifSpecific	1.3.6.1.2.1.2.2.1.22

Таблица 4.4.13.1.3. Переменные IP-группы

Переменная IP-группы	Тип данных	Описание	Код
ipForwarding	integer	Указание на то, что данный объект осуществляет переадресацию (работает как маршрутизатор).	1
IPdefaultTTL	integer	Значение, которое использует IP в поле TTL.	2
IPinreceives	counter	Число полученных дейтограмм.	3
ipInHdrErrors	counter	Число дейтограмм, отвергнутых из-за ошибок формата или неверных адресов или опций, из-за истекшего TTL.	4
ipInHdrErrors	counter	Число дейтограмм, отвергнутых из-за неверного IP-адреса, например, 0.0.0.0, или неподдерживаемого класса, например Е.	5
ipForwDatagrams	counter	Число дейтограмм, для которых данный объект не является местом назначения (маршрутизация отправителя).	6
ipInUnknownProtos	counter	Число дейтограмм с неподдерживаемым кодом протокола.	7
ipInDiscards	counter	Число дейтограмм, отвергнутых из-за переполнения буфера.	8
ipInDelivers	counter	Полное число входных дейтограмм, успешно обработанных на IP-уровне.	9
ipOutRequests	counter	Полное число IP и ICMP дейтограмм, переданных для отправки.	10
ipOutRequests	counter	Полное число IP и ICMP дейтограмм, переданных для отправки.	11
IPoutNoroutes	counter	Число неудач при маршрутизации.	12
ipReasmTimeout	counter	Максимальное число секунд ожидания сборки фрагментов.	13
ipReasmReqds	counter	Число полученных фрагментов	14
ipReasmOKs	counter	Число полученных и успешно собранных IP-дейтограмм	15
ipReasmFails	counter	Число полученных IP-дейтограмм, которые по тем или иным причинам не удалось собрать	16
IPFragOKs	counter	Число успешно фрагментированных IP- дейтограмм.	17
ipFragFails	counter	Число IP- дейтограмм, которые нужно фрагментировать, но сделать это нельзя (например, из-за флага).	18
ipFragCreates	counter	Число IP-дейтограмм фрагментов, сформированных данным объектом.	19
ipAddrTable	counter	Таблица адресной информации данного объекта.	20
ipRouteTable	Последовательность записей маршрутной таблицы	Запись в маршрутной таблице	21
ipAddrEntry
IPAdEntAddr	IPaddress	IP-адрес для данного ряда	1
IPadentifindex	integer	Число интерфейсов.	2
IPadentnetmask	IPaddress	Маска субсети для данного IP-адреса;	3
IPAdEntBcastAddr	[0...1]	Значение младшего бита широковещательного адреса (обычно 1);	4
IPAdEntReasmMaxsize	[0...65535]	Размер наибольшей IP-дейтограммы, полученной интерфейсом, которая может быть собрана.	5

Помимо простых переменных объектами MIB могут быть таблицы. Для каждой таблицы имеется один или несколько индексов.

Таблица 4.4.13.1.4. Переменные TCP-группы

Переменные TCP-группы	Тип данных	Описание	Код
tcpRtoAlgorithm	integer	Алгоритм выявления таймаута для повторной передачи TCP-пакетов: 1 - ни один из следующих; 2 - постоянное RTO; 3 - стандарт MIL-std-1778; 4 - алгоритм Ван Джакобсона	1
tcpRtoMin	integer	Минимальное допустимое время повторной передачи tcp- пакетов.	2
tcpRtoMax	integer	Максимальное значение тайм-аута в миллисек.	3
tcpMaxConn	integer	Максимальное допустимое число tcp-соединений.	4
tcpActiveOpens	integer	Число TCP-соединений Active-Open	5
tcpPassiveOpens	integer	Число TCP-соединений Passive-Open (из состояния LISTEN)	6
tcpAttemptFails	integer	Число неудачных TCP-соединений	7
tcpEstabResets	integer	Число разрывов TCP-соединений из состояний ESTABLISHED или CLOSE-WAIT	8
tcpCurrEstab	Gauge	Число TCP-соединений, для которых текущее состояние ESTABLISHED или CLOSE-WAIT	9
tcpInSegs	counter	Полное число полученных tcp-сегментов.	10
tcpOutSegs	counter	Полное число посланных сегментов, исключая повторно пересылаемые.	11
tcpRetransSegs	counter	Полное число повторно пересланных сегментов.	12
tcpConnTable	counter	Таблица данных специфичных для соединения	13
tcpInErrs	counter	Полное число сегментов, полученных с ошибкой.	14
tcpOutRsts	counter	Полное число посланных сегментов с флагом rst=1.	15
tcpconntable. tcp-таблица связей
tcpconnstate	[1...12]	Состояние соединения: 1 - closed; 2 - listen; 3 - syn_sent; 4 - syn_rcvd; 5 - established, 6 - fin_wait_1; 7 - fin_wait_2; 8 - close_wait; 9 - last_ack; 10 - closing; 11 - time_wait;, 12 - delete TCB. Только последняя переменная может устанавливаться менеджером, немедленно прерывая связь.
tcpconnlocal address	ipaddress	Местный IP-адрес. 0.0.0.0 означает, что приемник готов установить связь через любой из интерфейсов.
tcpconnlocal port	[0...65535]	Местный номер порта.
tcpconnlocal address	ipaddress	Удаленный ip-адрес.
tcpconnrem port	[0...65535]	Удаленный номер порта.

Таблица 4.4.13.1.5. Переменные ICMP-группы (тип данных - counter)

Переменная icmp-группы	Описание	Код
icmpInMsgs	Полное число полученных ICMP-сообщений.	1
icmpInErrors	Число ICMP-сообщений, полученных с ошибками.	2
icmpInDestUnreach	Число ICMP-сообщений о недостижимости адресата.	3
icmpintimeexcds	Число ICMP-сообщений об истечении времени.	4
icmpInParmProbs	Число полученных ICMP-сообщений о проблемах с параметрами.	5
icmpInSrcQuench	Число ICMP-сообщений с требованием сократить или прервать посылку пакетов из-за перегрузки.	6
icmpInRedirects	Число ICMP-сообщений о переадресации.	7
icmpInEchos	Число полученных ICMP-запросов отклика.	8
icmpInEchoReps	Число полученных ICMP-эхо- откликов.	9
icmpInTimestamps	Число ICMP-запросов временных меток.	10
icmpInTimestampReps	Число ICMP-откликов временных меток.	11
icmpInAddrMasks	Число ICMP-запросов адресных масок.	12
icmpInAddrMaskReps	Число ICMP-откликов на запросы адресных масок.	13
icmpOutMsgs	Число отправленных ICMP- сообщений.	14
icmpOutErrors	Число не отправленных ICMP- сообщений из-за проблем в ICMP (напр. нехватка буферов).	15
icmpOutDestUnreachs	Число ICMP-сообщений о недоступности адресата.	16
icmpOutTimesExcds	Число посланных ICMP-сообщений об истечении времени.	17
icmpOutParmProbs	Число посланных ICMP-сообщений о проблемах с параметрами.	18
icmpOutSrcQuench	Число посланных ICMP-сообщений об уменьшении потока пакетов.	19
icmpOutRedirects	Число посланных ICMP-сообщений о переадресации.	20
icmpOutEchos	Число посланных ICMP-эхо-запросов.	21
icmpOutEchoReps	Число посланных ICMP-эхо-откликов.	22
icmpOutTimestamps	Число посланных ICMP-запросов временных меток.	23
icmpOutTimestampReps	Число посланных ICMP-откликов на запросы временных меток.	24
icmpOutAddrMasks	Число посланных ICMP-запросов адресных масок.	25

Таблица 4.4.13.1.6. Переменные AT-группы (attable, преобразование адресов).

Переменные at-группы	Тип данных	Описание	atEntry
atIfIndex	integer	Число интерфейсов.	1
atPhysAddress	physaddress	Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует.	2
atNetAddress	networkaddress	IP-адрес.	3

Каждый протокол ( например IP) имеет свою таблицу преобразования адресов. Для IP это ipnettomediatable. Способ пропечатать эту таблицу с помощью программы SNMPI описан ниже.

MIB II содержит управляемые объекты, принадлежащие к группе snmp. SNMP-группа предоставляет информацию о SNMP-объектах, информационных потоках, о статистике ошибок:

Название объекта	Описание	Код
snmpInPkts	Число пакетов, полученных от слоя, расположенного ниже SNMP.	1
snmpOutPkts	Число пакетов доставленных от SNMP к нижележащему слою.	2
snmpInBadVersions	Индицирует число PDU, полученных с ошибкой в поле версия.	3
snmpInBadCommunityNames	Индицирует число PDU, полученных с нечитаемым или нелегальным именем community.	4
snmpInBadCommunityUses	Полное число SNMP-пакетов, полученных с нечитаемым или нелегальным значение операции для данного имени community.	5
snmpInAsnParsErrs	Указывает полное число ошибок ASN.1 или BER, которые не могут быть обработаны во входных SNMP-сообщениях	6
snmpInTooBigs	Указывает число полученных PDU со слишком большим значением поля статус ошибки.	8
snmpInNoSuchNames	Указывает число PDU, полученных с индикацией ошибки в поле nosuchname.	9
snmpInBadValues	Указывает число PDU, полученных с индикацией ошибки в поле badvalue.	10
snmpInReadOnlys	Указывает число PDU, полученных с индикацией ошибки в поле readonly.	11
snmpNnGenErrs	Указывает число PDU, полученных с generr-полем.	12
snmpInTotalReqVar	Указывает число объектов MIB, которые были восстановлены.	13
snmpInTotalSetVars	Указывает число объектов MIB, которые были изменены.	14
snmpInGetRequests	Указывает число соответствующих pdu, которые были получены.	15
snmpInGetNexts	Указывает полное число pdu с запросами GetNext	16
snmpInSetRequests	Указывает полное число pdu, полученных с запросами SET	17
snmpInGetResponses	Указывает полное число pdu, полученных c откликами на запросы	18
snmpInTraps	Указывает полное число, полученных и успешно обработанныз TRAP	19
snmpOutTooBig	Указывает число посланных PDU с полем toobig.	20
snmpOutNoSuchNames	Указывает число посланных PDU с полем nosuchname.	21
snmpOutBadValues	Указывает число посланных PDU с полем badvalue.	22
snmpOutGenErrs	Указывает число посланных PDU с полем genErrs.	24
snmpOutGetRequests	Указывает число посланных PDU Get-Request	25
snmpOutGetNexts	Указывает число посланных PDU Get-NEXT	26
snmpOutSetRequests	Указывает число посланных PDU SET	27
snmpOutGetResponses	Указывает число посланных PDU откликов	28
snmpOutTraps	Указывает число посланных PDU TRAPs	29
snmpEnableAuthTraps	Говорит о том, разрешены или нет ловушки (TRAPS).	30

Стандарт на структуру управляющей информации (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ASN.1 (abstract syntax notation 1, формализованный синтаксис). ASN.1 является формальным языком, который обладает двумя основными чертами:

используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. В SMI не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: integer, octet string, object identifier и null. Практически в протоколе SNMP фигурируют следующие виды данных:

integer. Некоторые переменные объявляются целыми (integer) с указанием начального значения или с заданным допустимым диапазоном значений (в качестве примера можно привести номера UDP- или TCP-портов).

octet string (последовательность байтов). В соответствии с требованиями BER (basic encoding rules, ASN.1) последовательность октетов должна начинаться с числа байт в этой последовательности (от 0 до n).

object identifier (идентификатор объекта). Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5.

null. Указывает, что соответствующая переменная не имеет значения.

displaystring. Строка из 0 или более байт (но не более 255), которые представляют собой ASCII-символы. Представляет собой частный случай octet string.

physaddress. Последовательность октетов, характеризующая физический адрес объекта (6 байт для Ethernet). Частный случай object identifier.

Сетевой адрес. Допускается выбор семейства сетевых протоколов. В рамках ASN.1 этот тип описан как choice, он позволяет выбрать протокол из семейства протоколов. В настоящее время идентифицировано только семейство протоколов Интернет.

IP-адрес. Этот адрес используется для определения 32-разрядного Интернет-адреса. В нотации ASN.1 - это octet string.

time ticks (такты часов). Положительное целое число, которое используется для записи, например, времени последнего изменения параметров управляемого объекта, или времени последней актуализации базы данных.

Время измеряется в сотых долях секунды.

gauge (масштаб). Положительное целое число в диапазоне 0 - (232-1), которое может увеличиваться или уменьшаться. Если эта переменная достигнет величины 232-1, она будет оставаться неизменной до тех пор пока не будет обнулена командой сброс. Примером такой переменной может служить tcpcurresta, которая характеризует число TCP соединений, находящихся в состоянии established или close_wait.

counter (счетчик). Положительное целое число в диапазоне 0 - (232-1), которое может только увеличиваться, допуская переполнение.

sequence. Этот объект аналогичен структуре в языке Си.

Например, MIB определяет sequence с именем udpentry, содержащую информацию об активных UDP-узлах. В этой структуре содержится две записи:

1. UDPlocaladdress типа ipaddress, содержит местные IP-адреса.

2. UDPlocalport типа integer, содержит номера местных портов.

SEQUENCE OF. Описание вектора, все элементы которого имеют один и тот же тип. Элементы могут представлять собой простые объекты, например, типа целое. В этом случае мы имеем одномерный список. Но элементами вектора могут быть объекты типа SEQUENCE, тогда этот вектор описывает двумерный массив.

В Интернет MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.

Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT. Структура имен носит иерархический характер, отображенный на рис. 4.4.13.1.1.

Рис. 4.4.13.1.1 Структура идентификаторов переменных в MIB

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

Имя переменной	Тип данных	Описание	Код
udpInDatagrams	counter	Число UDP-дейтограмм, присланных процессам пользователя.	1
udpNoPorts	counter	Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения.	2
udpInErrors	counter	Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы).	3
udpOutDatagrams	counter	Число посланных UDP-дейтограмм.	4
udpTable	counter	Таблица, содержащая данные о принимающей стороне	5

Ниже приведено описание таблицы (udptable; index = <udplocaladdress>, <udplocalport>), состоящей из двух простых переменных (read-only).

Имя переменной	Тип данных	Описание
udplocaladdress	ipaddress	Местный IP-адрес для данного приемника;
udplocalport	(0 - 65535)	Местный номер порта приемника.

Согласно этой иерархии переменные, соответствующие ICMP, должны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символьном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хотите узнать значение какой-то переменной, следует послать запрос, содержащий соответствующий префикс и суффикс, последний определяет имя конкретной переменной. Для простой переменной суффикс имеет вид .0. Ветвь структуры на рис. 4.4.13.1.1, завершающейся узлом Interfaces (2) имеет продолжение в виде ifTable(2) и ifEntry(1). Таким образом переменная ifInUcastPkts будет иметь представление 1.3.6.1.2.1.2.2.1.11.

Помимо стандартного набора переменных и таблиц MIB возможно использование индивидуальных расширений этой базы данных. Это можно продемонстрировать на примере MIB маршрутизаторов Cisco (рис. 4.4.13.1.2).

Рис. 4.4.13.1.2. Расширение базы данных mib маршрутизаторов Cisco

Префикс 1.3.6.1.4.1. является стандартным, далее следует расширение, индивидуальное для маршрутизаторов компании Cisco. Например, группа IPcheckpoint accounting позволяет контролировать поток байтов с определенных адресов локальной сети, что бывает важно при работе с коммерческими провайдерами услуг.

Коды-префиксы для различных производителей телекоммуникационного оборудования приведены в таблице 4.4.13.1.7.

Таблица 4.4.13.1.7 Коды-префиксы производителей

Код префикса	Название фирмы
0	Зарезервировано
1	Proteon
2	IBM
3	CMU
4	UNIX
5	ACC
6	TWG
7	Cayman
8	PSI
9	Cisco
10	NSC
11	HP
12	Epilogue
13	U of Tennessee
14	BBN
15	Xylogics, inc.
16	Unisys
17	Canstar
18	Wellfleet
19	TRW
20	MIT

Группа локальных переменных IP checkpoint accounting (1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в каждом рекорде по четыре переменных (в скобках указан суффикс адреса MIBдля переменной):

ckactbyts [4] - число переданных байт,

ckactdst [2] - адрес места назначения,

ckactpkts [3] - число переданных пакетов

ckactsrc [1] - адрес отправителя

Маршрутизаторы Cisco поддерживают две базы данных: active accounting и checkpoint accounting. В первую заносятся текущие результаты измерения входящего и исходящего трафика. Эти результаты копируются в базу данных checkpoint accounting и, если там уже имеются предыдущие данные, они объединяются. Для очистки базы данных checkpointed database выдается команда clear IP accounting, а для базы checkpoint - clear IP accounting checkpoint (для использования этих команд необходимы системные привилегии). Объем памяти, выделяемой для этих баз данных задается командой IP accounting-threshold , по умолчанию максимальное число записей в базе данных равно 512.

Лучшим способом закрепить в памяти все вышесказанное является использование программы SNMPI (SNMP initiator) или ее аналога. Если в вашем распоряжении имеется ЭВМ, работающая под unix, например SUN, вы можете попутно узнать много полезного о вашей локальной сети. Ниже описан синтаксис обращения к SNMPI.

snmpi [-a agent] [-c community] [-f file] [-p portno] [-d] [-v] [-w]

SNMPI - крайне простая программа, используемая для тестирования SNMPD. Для того чтобы проверить, работает ли она, выдайте команду:

% SNMPI dump

Следует отметить, что в ответ на эту операцию будет произведена весьма объемная выдача.

Опция -a предлагает возможность ввести адрес SNMP-объекта - имя ЭВМ, IP-адрес или транспортный адрес. По умолчанию это местная ЭВМ. Аналогично опция -p позволяет задать номер UDP-порта. По умолчанию это порт 161.

Опция -c позволяет задать групповой пароль (community) для snmp-запроса. По умолчанию - это public, т.е. свободный доступ.

Опция -f позволяет выбрать файл, содержащий откомпилированные описания mib-модулей. По умолчанию - это objects.defs.

Опция -w включает режим наблюдения, осуществляя выдачу на терминал всех служебных сообщений. Уход из программы по команде quit (q).

Если вы работаете на IBM/PC, и ваша машина подключена к локальной сети, получите допуск к одной из UNIX-машин в сети (если вы его не имели) и приступайте. Можно начать с обращения типа:

SNMPI -a 193.124.224.33 (адрес или символьное имя надо взять из вашей локальной сети)

Машина откликнется, отобразив на экране SNMPI>, это означает, что программа имеется и вы можете вводить любые команды.

Начать можно со знакомства с системными переменными системы (в дальнейшем курсивом выделены команды, введенные с клавиатуры):

SNMPI> get sysdescr.0

snmpi> sysdescr.0="GS software (gs3-k), version 9.1(4) [fc1], software copyright (c) 1986-1993 by cisco systems, inc. compiled thu 25-mar-93 09:49 by daveu"

snmpi> get sysobjectid.0

snmpi> sysobjectid.0=1.3.6.1.4.1.9.1.1

snmpi> get sysuptime.0

snmpi> sysuptime.0=14 days, 7 hours, 0 minutes, 15.27 seconds (123481527 timeticks)

snmpi> get sysservices.0

snmpi> sysservices.0=0x6

Код 0x06 (sysservices.0) представляет собой сумму кодов уровней модели iso, поддерживаемых системой. Для справок: 0x01 - физический уровень; 0x02 - связной уровень; 0x04 - Интернет; 0x08 - связь точка-точка; 0x40 - прикладной уровень.

Если вы хотите получить информацию о состоянии интерфейсов на одной из ЭВМ, подключенных к вашей локальной сети (команды вызова snmpi далее не повторяются; в ниже приведенных примерах в круглых скобках помещены комментарии автора), выдайте команды:

SNMPI> next iftabl (команда next в данном случае соответствует запросу get-next, здесь понятие "следующий" подразумевает порядок переменных в MIB)

snmpi> ifindex.1=1

snmpi> get ifdescr.1

snmpi> ifdescr.1="ethernet0"

snmpi> get iftype.1

snmpi> iftype.1=ethernet-csmacd(6)

snmpi> get ifmtu.1

snmpi> ifmtu.1=1500

snmpi> get ifspeed.1

snmpi> ifspeed.1=10000000 (10Мб/с ethernet)

snmpi> get ifphysaddress.1

snmpi> ifphysaddress.1=0x00:00:0c:02:3a:49 (физический адрес интерфейса)

snmpi> next ifdescr.1 iftype.1 ifmtu.1 ifspeed.1 ifphysaddress.1

snmpi> ifdescr.2="serial0"

iftype.2=proppointtopointserial(22)

ifmtu.2=1500

ifspeed.2=2048000 (2 Мбит/ c радиорелейный последовательный канал, спутниковый канал был бы охарактеризован точно также).

ifphysaddress.2=

В приведенном примере размеры пересылаемых блоков для Ethernet и радиорелейного последовательного канала идентичны и равны 1500. Помните, что SLIP-канал характеризуется как pointtopointserial, а не slip. Скорость обмена по SLIP-каналу не сообщается.

Теперь просмотрим некоторые UDP-переменные. Например:

SNMPI> next UDP

SNMPI> udpindatagrams.0=98931

SNMPI> next udpindatagrams.0 (обратите внимание на суффикс простой переменной)

SNMPI> udpnoports.0=60009

SNMPI> next udplocaladdress.0

SNMPI>udplocaladdress.193.124.137.14.7=193.124.137.14

(Идентификатор этого объекта - 1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.)

SNMPI> next udplocalport

SNMPI> udplocalport.193.124.137.14.7=7

Если у вас возникла необходимость просмотреть таблицу, например, udptable, это

также можно сделать, используя snmpi:

SNMPI> next udptable

SNMPI> udplocaladdress.193.124.137.14.7=193.124.137.14

SNMPI> next udplocaladdress.193.124.137.14.7

SNMPI> udplocaladdress.193.124.224.33.67=193.124.224.33

SNMPI> next udplocaladdress.193.124.224.33.67

SNMPI> udplocaladdress.193.124.224.33.161=193.124.224.33

SNMPI> next udplocalport.193.124.224.33.67

SNMPI> udplocalport.193.124.224.33.161=161

Ниже показана методика выяснения алгоритма и параметров задания величины тайм-аута:

SNMPI> get tcprtoalgorithm.0 tcprtomin.0 tcprtomax.0 tcpmaxconn.0

SNMPI> tcprtoalgorithm.0=vanj(4) (vanj - алгоритм Ван Джакобсона для расчета времени тайм-аута)

tcprtomin.0=300	(минимальное значение тайм-аута = 300 мс)
tcprtomax.0=60000	(максимальное - 60 сек)
tcpmaxconn.0=-1	(никаких ограничений на число соединений)

Чтобы получить информацию о состоянии таблицы адресных преобразований, выдайте команду: SNMPI -a 193.124.224.33 dump at (процедуры с использование субкоманды dump требуют определенного времени для своего исполнения)

atifindex.1.1.193.124.224.33=	1
atifindex.1.1.193.124.224.35=	1
atifindex.3.1.192.148.166.203=	3
atifindex.3.1.192.148.166.205=	3
atifindex.5.1.145.249.30.33=	5
atifindex.5.1.192.148.166.98=	5
atphysaddress.1.1.193.124.224.33=	0x00:00:0c:02:3a:49
atphysaddress.1.1.193.124.224.35=	0x08:00:20:12:1b:b1
atphysaddress.1.1.193.124.224.40=	0x00:00:cd:f9:0d:e7
atphysaddress.1.1.193.124.224.50=	0x00:00:0c:02:fb:c5
atnetaddress.1.1.193.124.224.33=	193.124.224.33
atnetaddress.1.1.193.124.224.35=	193.124.224.35
atnetaddress.1.1.193.124.224.40=	193.124.224.40
atnetaddress.1.1.193.124.224.50=	193.124.224.50
atnetaddress.1.1.193.124.224.60=	193.124.224.60

Текст выдачи с целью экономии места сокращен.

Обычно элементы таблицы расположены в порядке колонка-ряд. Если вы дошли до края колонки или всей таблицы ЭВМ выдаст вам, в зависимости от реализации программы, имя и значение следующего элемента или сообщение об ошибке.

Чтобы получить полный текст адресной таблицы в рамках SNMPI достаточно выдать команду:

SNMPI> dump ipaddrtable

snmpi> ipadentaddr.192.148.166.222=	192.148.166.222
ipadentaddr.192.168.1.1=	192.168.1.1
ipadentaddr.192.168.1.2=	192.168.1.2
ipadentaddr.193.124.224.33=	193.124.224.33
ipadentaddr.193.124.224.190=	193.124.224.190
ipadentifindex.192.148.166.222=	3
ipadentifindex.192.168.1.1=	4
ipadentifindex.192.168.1.2=	6
ipadentifindex.193.124.224.33=	1
ipadentifindex.193.124.224.190=	5

(Маски субсетей)

ipadentnetmask.192.148.166.222=	255.255.255.224
ipadentnetmask.192.168.1.1=	255.255.255.0
ipadentnetmask.192.168.1.2=	255.255.255.0
ipadentnetmask.193.124.224.33=	255.255.255.224
ipadentnetmask.193.124.224.190=	255.255.255.224

ipadentbcastaddr.192.148.166.222= 1 (Все эти субсети используют для широковещательной адресации одни и те же биты).

ipadentbcastaddr.192.168.1.1=	1
ipadentbcastaddr.192.168.1.2=	1
ipadentbcastaddr.193.124.224.33=	1
ipadentbcastaddr.193.124.224.190=	1

ipadentreasmmaxsize.192.148.166.222= 18024 (С точки зрения фрагментации и последующей сборки дейтограмм данные субсети эквивалентны).

ipadentreasmmaxsize.192.168.1.1=	18024
ipadentreasmmaxsize.192.168.1.2=	18024
ipadentreasmmaxsize.193.124.224.33=	18024
ipadentreasmmaxsize.193.124.224.190=	18024

Данная пропечатка совместно с приведенной для IFtable позволяет получить достаточно полную картину о данной конкретной локальной сети. Чтобы познакомиться с ARP таблицей, можно воспользоваться командой:

sun> arp -a

itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49

nb.itep.ru (193.124.224.60) at 0:80:ad:2:24:b7

и дополнить полученные данные с помощью SNMPI:

SNMPI> dump ipnettomediatable

SNMPI> ipnettomediaifindex.1.193.124.224.33= 1

ipnettomediaifindex.1.193.124.224.35= 1

ipnettomediaifindex.3.192.148.166.193= 3

ipnettomediaifindex.3.192.148.166.196= 3

ipnettomediaifindex.3.193.124.226.110= 3

ipnettomediaifindex.5.145.249.30.33= 5

ipnettomediaifindex.5.192.148.166.100= 5

ipnettomediaphysaddress.1.193.124.224.33= 0x00:00:0c:02:3a:49

ipnettomediaphysaddress.3.192.148.166.196= 0xaa:00:04:00:0c:04

ipnettomediaphysaddress.3.192.148.166.198= 0xaa:00:04:00:0e:04

ipnettomediaphysaddress.3.192.148.166.203= 0x00:00:01:00:54:62

.........................................

ipnettomediaphysaddress.5.145.249.30.33= 0x00:00:0c:02:69:7d

ipnettomediaphysaddress.5.192.148.166.100= 0x00:20:af:15:c1:61

ipnettomediaphysaddress.5.192.148.166.101= 0x08:00:09:42:0d:e8

ipnettomedianetaddress.1.193.124.224.33= 193.124.224.33

ipnettomedianetaddress.1.193.124.224.35= 193.124.224.35

ipnettomedianetaddress.3.192.148.166.193= 192.148.166.193

ipnettomedianetaddress.3.193.124.226.110= 193.124.226.110

ipnettomedianetaddress.5.145.249.30.33= 145.249.30.33

ipnettomediatype.1.193.124.224.33= other(1)

ipnettomediatype.1.193.124.224.35= dynamic(3)

ipnettomediatype.1.193.124.224.37= dynamic(3)

ipnettomediatype.3.192.148.166.195= dynamic(3)

ipnettomediatype.3.192.148.166.222= other(1)

ipnettomediatype.5.193.124.224.190= other(1)

ipnettomediatype.5.193.124.225.33= other(1)

ipnettomediatype.5.193.124.225.35= dynamic(3)

Синтаксис каждого объекта описывается в рамках ASN.1 и показывает побитовое представление объекта. Кодирование объекта характеризует то, как тип объекта отображается через его синтаксис и передается по телекоммуникационным каналам. Кодирование производится в соответствии с базовыми правилами кодирования asn.1. Все описания объектов базируются на типовых шаблонах и кодах asn.1 (см. RFC-1213). Формат шаблона показан ниже:

object (Объект):

Имя типа объекта с соответствующим ему идентификатором объекта (object identifier)

syntax (Синтаксис):

asn.1 описание синтаксиса типа объекта.

definition (Определение):

Текстовое описание типа объекта.

access (доступ):

Опции доступа.

status (состояние):

Статус типа объекта.

Маршруты также являются объектами mib. Согласно требованиям к mib, каждому маршруту в этой базе соответствует запись, схема которой приведена ниже на рис. 4.4.13.1.3:

Рис. 4.4.13.1.3 Формат записи маршрутной таблицы в MIB

Поле место назначения представляет собой IP-адрес конечной точки маршрута. Поле индекс интерфейса определяет локальный интерфейс (физический порт), через который можно осуществить следующий шаг по маршруту. Следующие пять полей (метрика 1-5) характеризуют оценку маршрута. В простейшем случае, например для протокола RIP, достаточно было бы одного поля. Но для протокола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг представляет собой IP-адрес следующего маршрутизатора. Поле тип маршрута имеет значение 4 для опосредованного достижения места назначения; 3 - для прямого достижения цели маршрута; 2 - для нереализуемого маршрута и 1 - для случаев отличных от вышеперечисленных.

Поле протокол маршрутизации содержит код протокола. Для RIP этот код равен 8, для OSPF - 13, для BGP - 14, для IGMP - 4, для прочих протоколов - 1. Поле возраст маршрута описывает время в секундах, прошедшее с момента последней коррекции маршрута.

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

Новым расширением MIB является система удаленного мониторинга сетей (RMON; RFC-1513, -1271). RMON служит для мониторирования сети в целом, а не отдельных сетевых устройств. В RMON предусмотрено 9 объектных групп (см. табл. 4.4.13.1.8).

Таблица 4.4.13.1.8. Функциональные группы RMON

Группа	Назначение
statistics	Таблица, которая отслеживает около 20 статистических параметров сетевого трафика, включая общее число кадров и количество ошибок
history	Позволяет задать частоту и интервалы для измерений трафика
alarm	Позволяет установить порог и критерии, при которых агенты выдают сигнал тревоги
host	Таблица, содержащая все узлы сети, данные по которым приводятся в сетевой статистике
hostTopN	Позволяет создать упорядоченные списки, которые базируются на пиковых значениях трафика группы ЭВМ
matrix	Две таблицы статистики трафика между парами узлов. Одна таблица базируется на адресах узлов-отправителей, другая - на адресах узлов-получателей
filter	Позволяет определить конкретные характеристики кадров в канале. Например, можно выделить TCP-трафик.
packet capture	Работает совместно с группой filter. Позволяет специфицировать объем ресурса памяти, выделяемой для запоминания кадров, которые отвечают критериям filter.
event	Позволяет специфицировать набор параметров или условий, которые должен контролировать агент. Когда условия выполняются, информация о событии записывается в специальный журнал

Для того чтобы реализовать функционирование RMON-агента, сетевая карта должна быть способна работать в режиме 6 (promiscuous mode), когда воспринимаются все пакеты, следующие по кабельному сетевому сегменту.

Модель ЭВМ

Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

H1	Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress.
H2	Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress.
H3	Приложение получателя принимает сообщение Path.
H4	Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков.
H5	Приложение отправителя получает сообщение Resv.
H6	Отправитель начинает посылать информационные пакеты.

Существует несколько соображений, касающихся синхронизации.

H1 и H2 могут произойти в любом порядке.

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

Предположим, что новый отправитель начинает рассылку сообщений Path (H2) и данных (H6) одновременно, и имеется некоторое число получателей, но сообщения Resv пока не достигли отправителя (напр., потому что его сообщения Path еще не дошли до получателей). Тогда исходные данные могут прийти к получателю без желаемого уровня QoS. Отправитель может немного облегчить эту проблему, подождав прибытия первого сообщения Resv (H5). Однако получатели, которые достаточно далеко, могут еще не получить необходимого резервирования.

Если получатель начинает посылать сообщения Resv (H4) до получения какого-либо сообщения Path (H3), RSVP пришлет получателю сообщение об ошибке.

Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.

Модификации существующих типов запроса

Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.

Мульткаст-адреса

Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.4.1.1.13):

Рис. 4.4.1.1.13

11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.

Рис. 4.4.1.1.14

Старшие 3 флага зарезервированы и должны быть обнулены.

t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет.

T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient").

Поле scope представляет собой 4-битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения:

0 зарезервировано

1 Область действия ограничена локальным узлом

2 Область действия ограничена локальным каналом

3 (не определено)

4 (не определено)

5 Область действия ограничена локальной сетью

6 (не определено)

7 (не определено)

8 Область действия ограничена локальной организацией

9 (не определено)

A (не определено)

B (не определено)

C (не определено)

D (не определено)

E глобальные пределы (global scope)

F зарезервировано

Идентификатор группы идентифицирует мультикастинг-группы, постоянной или переходной (transient), в пределах заданных ограничений (scope).

Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда:

FF01:0:0:0:0:0:0:43 означает, что все ntp серверы одного и того же узла рассматриваются как отправители.

FF02:0:0:0:0:0:0:43 означает, что все NTP серверы работают с тем же каналом, что и отправитель.

FF05:0:0:0:0:0:0:43 означает, что все NTP серверы принадлежат той же сети, что и отправитель.

FF0E:0:0:0:0:0:0:43 означает, что все NTP серверы находятся в Интернет.

Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID.

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

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

L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений. Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле.

Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK.

Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB.

Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB.

Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения.

Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы.

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

Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений.

Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым.

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

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

Не специфицированный адрес

Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.

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

Необходимые адреса узлов

ЭВМ должна распознавать следующие адреса, как обращенные к нему:

Её локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов

Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.

Маршрутизатор должен распознавать следующие адреса (as identifying itself):

Его локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.

Все другие эникастные адреса, которые использовались при маршрутизации.

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес для обращения ко всем маршрутизаторам

Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.

Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.

Приложение должно предопределить только следующие адресные префиксы:

Не специфицированный адрес

Адрес обратной связи

Мультикаст-префикс (FF)

Локально используемые префиксы (link-local и site-local)

Предопределенные мультикаст-адреса

Префиксы, совместимые с IPv4

Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса).

Необходимые эникаст-адреса

Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:

Рис. 4.4.1.1.12

Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю.

Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.

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

New_tcp

4.4.3.3 Новый протокол TCP

Семенов Ю.А. (ГНЦ ИТЭФ)

Современная версия протокола ТСР (RFC-793, -1323) имеет ряд недостатков (см. , а также RFC-2525 или [1]):

Практически не защищена от атак злоумышленников (подбор ISN, “человек по середине”, посылка ложного флага FIN

или RST, переполнение буфера SYN-запросами, прерывание сессии с помощью сообщения ICMP "адресат недоступен" и т.д.)

Не обеспечивает оптимального использования виртуального соединения в условиях перегрузки (управление CWND)

Имеет неэффективность процедуры установления соединения (три операции обмена) и разрыва связи (4 операции обмена)

Логика работы протокола плохо адаптируется к изменениям ситуации в сети

Протокол плохо приспособлен для работы со скоростными каналами (10Гбит/c и больше, в частности из-за ограничений размера окна или поля идентификатора пакета)

Попытки адаптировать действующую версию протокола имели существенный, но ограниченный успех (модели Tahoe, Reno (см. также RFC-2582), Vegas, Т/ТСР (см. RFC-1644), SACK (см. RFC-2018, -2883, -3517) и другие (см., например, RFC-2309, -3042, -3168)), а также альтернативный протокол XTP. Некоторые недостатки были частично устранены (синдром узкого окна, алгоритм Нагля).

Следует, впрочем, заметить, что радикальные изменения протокола ТСР не предпринимались неслучайно. Программные продукты, используемые на сотнях миллионов ЭВМ не поменять в одночасье. И нужно искать решение, которое позволяло бы работать со старыми версиями программного обеспечения, базирующегося на протоколе ТСР (Tahoe или Reno).

В данной статье предлагается принципиально иная модель таботы транспортного протокола ТСР (NTCP). В запросе SYN этого протокола должен присутствовать код опции NTCP (код поля опции вид может равняться, например, 20) и, если поддерживающий NTCP объект получает такой сегмент, он должен послать соответствующий отклик отправителю.

Сначала рассмотрим, что мешает традиционному ТСР работать в сверхскоростных каналах. Здесь наиважнейшими параметрами являются window > RTT×B/MSS и поле идентификатора пакета, где В - полоса пропускания канала, измеряемая в битах в сек, максимальный размер сегмента MSS здесь и далее задан в битах), а RTT-сумма времен доставки сегмента от отправителя до получателя и отклика от получателя до отправителя.
По умолчанию величина MSS равна 1460*8 = 11680бит. О проблеме работы протокола ТСР в режиме больших произведений RTT на В см. [2].

Высокопроизводительные каналы (³1 Гбит/с) уже сегодня могут исчерпать разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух пакетов с равными идентификаторами может породить неразрешимые трудности. Для передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные протоколы, размеры окон и пр. могут свести на нет преимущества скоростного, дорогостоящего канала. Пропускная способность такого канала определяется уже не его полосой, а задержкой. Понятно также, что необходимо расширить эффективное поле размера окна с 16 до 32 бит (это делается сегодня с привлечением опции ТСР). Чтобы не изменять формат TCP-сегментов, можно сделать код размера окна в программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным (см. RFC-2414, -2415). Размер окна в этом случае задается как бы в формате с плавающей запятой. При установлении канала определяется масштабный коэффициент n (порядок) лежащий в интервале 0-14. Передача этого коэффициента (один байт) осуществляется сегментом SYN в поле опций. В результате размер окна оказывается равным 65535*2n. Если один из партнеров послал ненулевой масштабный коэффициент, но не получил такого коэффициента от своего партнера по каналу, то n считается равным нулю. Эта схема позволяет сосуществовать старым и новым системам. Выбор n возлагается на TCP-модуль операционной системы.

Увеличение размера окна в свою очередь приводит к проблемам, возникающим при перегрузке. Каноническое поведение протокола TCP в случае потери пакета (это может быть сегмент данных или отклик) заключается в повторной пересылке всех посланных пакетов, начиная с потерянного. Если считать, что о потере пакета отправитель узнает в среднем спустя RTT/2, то для рассмотренного выше примера за это время будет передано 2 мегабайта, которые и должны быть переданы повторно.

Для 10Гигабитного канала этот объем увеличится до 20Мбайт.

Время RTT складывается из задержки распространения электромагнитных волн по каналу и из времени пребывания пакетов в очередях и их обработки в сетевых устройствах. Вторая составляющая преобладает (если это не спутниковый канал). Время распространения волны по кабелю длиной 5000 км составляет около 25 мсек, задержка в современном маршрутизаторе варьируется от 2 до 20 мсек. Число же маршрутизаторов на пути такой длины равно 10-15. Дополнительной вклад в задержку внесут переключатели локальной сети, а также системы отправителя и получателя. Таким образом, приведенное выше значение RTT является типичным, и, следовательно, нужно искать пути выхода из тупика, сопряженного с повторной передачей больших массивов данных.

Можно рассматривать варианты, где исключается или сводится к минимуму вероятность потери пакета (тогда ничего повторно передавать не нужно). В некоторых моделях реализации ТСР предусмотрен режим “исключения перегрузки”, что подразумевает исключение потери пакетов. Но, к сожалению, полностью исключить потери пакетов невозможно, хотя бы из-за конечной вероятности их повреждения при транспортировке.

Можно задуматься о снижении величины RTT. Это делает бесперспективным использование скоростных спутниковых каналов связи, где составляющая, сопряженная с временем распространения электромагнитных волн, составляет около 400мсек. Время пребывания пакета в очереди и длительность его обработки в маршрутизаторе пока сократить нельзя. Можно ли сократить число маршрутизаторов в виртуальном соединении точка-точка?

Если следовать требованиям современного протокола ТСР, то нельзя, так как конечные точки заданы сессией (отправитель-получатель), а промежуточные узлы - топологией Интернет и протоколом маршрутизации.

Далее рассматривается принципиально новый вариант протокола ТСР, который будем называть NTCP. Все сетевые объекты, поддерживающие протокол NTCP, должны анализировать и модифицировать TCP-заголовки откликов не только адресованных им пакетов, но и всех транзитных.

Для широкомасштабной реализации протокола NTCP необходима адаптация сетевых маршрутизаторов (в настоящее время они обрабатывают только IP-заголовки) и крайне желательна переделка переключателей уровня L2.

Если исключить виртуальное соединение точка-точка и сделать так, чтобы виртуальный путь состоял из цепочки сегментов маршрута, то RTT можно сократить в разы, а для протяженных маршрутов на порядок. Традиционный виртуальный ТСР-маршрут превращается в цепь туннелей, соединяющих последовательные маршрутизаторы, поддерживающие NTCP. Здесь не имеются в виду IP-туннели с вложением IP-дейтограммы в IP-пакет. Примеры таких туннелей можно видеть на рис. 3 между узлами А и 1, а также между 3 и 4. Для каждого из туннелей RTT становится равным времени транспортировки и обработки пакета для одного шага, что может составлять 1-5 мсек (или даже меньше). 16-битного поля окна заголовка при RTT>5мсек хватит до скоростей передачи данных ~20Гбит/c. Можно предполагать, что для 100Гигабитного оборудования будут характерны меньшие значения RTT, что позволит во многих случаях исключить использование опции ширины окна. При потере пакета проблема улаживается локально в данном сегменте-туннеле, объем повторно пересылаемых данных будет минимальным. В случае минимизации RTT потребуется большая точность измерения этого времени (~10-100мксек). Сокращение среднего значения RTT пропорционально снизит требования, предъявляемые к объему буферов во всех сетевых устройствах по пути от отправителя к получателю.

В отличие от обычного протокола ТСР (рис. 1 верх) в такой схеме взаимодействует не конечный отправитель с конечным получателем, а только отправитель с ближайшим маршрутизатором (поддерживающим протокол NTCP), соседние маршрутизаторы между собой и конечный маршрутизатор с получателем (см. рис. 1, низ; случай, когда все маршрутизаторы поддерживают NTCP). Предусматривается возможность диалога с соседним маршрутизатором на предмет проверки, поддерживает ли он NTCP. Понятно, что в этом варианте маршрутизаторы должны научиться работать на уровне L4 (сейчас они работают только на уровне L3), различать сессии, установленные между одними и теми же конечными агентами (анализировать номера портов или идентификаторы сокетов).

Разбивка единого виртуального соединения отправитель- получатель на последовательность соединений соседних сетевых устройств снизит транзитный трафик, так как в случае потери пакета, повторная его транспортировка будет осуществляться лишь для одного сегмента пути (того, где произошла потеря), а не всего маршрута отправитель-получатель..

Рис. 1.

Рис. 1.а

Возможны две модели реализации протокола NTCP, ориентированного на соединение (аналог ТСР).

1. Обработка сегментов уровня L4 (TCP) осуществляется не только маршрутизаторами, но и переключателями уровня L2 (рис. 1 верх). При этом они выделяют из потока сегменты-отклики и укладывают в их поле данных свой идентификатор, полную емкость буфера и уровень его заполнения на текущий момент. Это не должно создать проблем, ведь поле данных отклика свободно и там достаточно места для практически любого объема записей, характеризующих состояние буферов. Отправитель, получив такой отклик, записывает содержащиеся в нем данные, сравнивает их с ранее полученными, методом экстраполяции вычисляет вероятность перегрузки и на основании этой оценки определяет, когда следует послать очередной пакет. Данный алгоритм исключает перегрузку в принципе, хотя вероятность потери из-за порчи пакетов все равно остается. О состоянии виртуального соединения при этом исчерпывающую информацию могут иметь все участники. Если какой-то отправитель, несмотря на неблагоприятный прогноз, осуществит передачу, этот пакет будет отвергнут ближайшим маршрутизатором и не создаст проблем для сетевых устройств, расположенных за ним. Таким образом, такое “антиобщественное” поведение не будет поощрено. Напомню, что в существующих моделях ТСР допускается “агрессивное” использование ресурсов канала в ущерб остальным участникам обменов. RTT здесь будет тем же, что и в традиционном протоколе ТСР со всеми вытекающими последствиями. Но отправитель, владея полной информацией о состоянии буферов в промежуточных узлах, может делать более точный прогноз и корректно выбрать значение окна.

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

Следует заметить, что современная технология позволяет создать переключатели уровня L2 не только способные сообщать о состоянии очередей в своих буферах, но и реализовывать приоритетное обслуживание (DiffServ), учитывающее код DSCP в заголовке IP-дейтограммы. Разработка таких переключателей даст возможность обеспечивать требуемый уровень обслуживания для локальных сетей, что принципиально поменяет характер работы многих приложений.

Структура рекорда в поле данных отклика может иметь формат, показанный на рис. 2. Число рекордов в отклике зависит от числа шагов между отправителем и получателем.

Рис. 2.

В поле идентификатор может размещаться IP-адрес сетевого объекта, а в случае прибора L2 - номер по порядку. Поля заполнение

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

Эти данные затем переносятся получателем в рекорды состояния буферов отклика. Размер MSS при этом немного сократится. Следует учитывать и возможность переполнения очередей откликами. Но так как отклики посылаются лишь на присланный сегмент, а посылка сегмента обусловлены состоянием буферов по пути следования, то правильный выбор параметров алгоритма, полностью исключит такую возможность.

2. Отклик на получение сегмента выдает ближайший маршрутизатор. В его задачу будет входить отправка сегмента очередному маршрутизатору и получение подтверждающего отклика от него. Маршрутизатор n посылает отклик подтверждения маршрутизатору n-1 немедленно, по получении сегмента.

Приняв и подтвердив получение сегмента, маршрутизатор берет на себя ответственность за последующую доставку сегмента следующему маршрутизатору, и так далее вплоть до конечного адресата (см. рис. 1а). Может возникнуть вопрос, а если в этой цепочке возникнет ситуация, когда сегмент не может быть доставлен. Что произойдет? Могут быть переполнены буферы промежуточных маршрутизаторов. Но главное, как об этом узнает исходный отправитель? Поскольку виртуальное соединение строится из цепочки туннелей, IP-адрес исходного отправителя известен всем участникам, и после нескольких неудач (максимальное число их должно быть оговорено) исходный отправитель может быть уведомлен о том, что адресат недоступен с помощью ICMP-сообщения. Если отправитель продолжает передачу, это ICMP-сообщение через некоторое время дублируется. Не переданные сегменты уничтожаются. Процедура эта может быть реализована прекращением подтверждения сегментов или посылкой ICMP-сообщения своему соседу отправителю. Одновременно с этим по цепочке маршрутизаторов будет от заблокированного устройства в направлении отправителя будет распространяться волна неподтверждений и прерываний передачи. Можно предусмотреть специальный отклик, уведомляющий соседа-отправителя о блокировке маршрута.

Алгоритм усложняется лишь в случае проблем в канале, при нормальной ситуации задержка (RTT) в цепочке отправитель-получатель минимальна.

Если пакет оказался поврежден, по истечении таймаута он будет послан повторно (RTO=RTTm +4 D, как и обычном ТСР, только RTT и его дисперсия D в несколько раз меньше; см. также RFC-2988).

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

Возможен вариант предварительного формирования цепочки туннелей, примерно так, как это делается при создании виртуального канала в ATM (см. http://book.itep.ru/4/43/atm_435.htm рис. 4.3.5.1). У такого подхода имеются привлекательные стороны, так как все участники получат исчерпывающую информацию обо всех адресах. Но и в случае разрыва связи, как в АТМ, придется формировать цепь туннелей заново. Но это неизбежная процедура в любом случае.

Здесь следует рассматривать несколько фаз работы протокола и соответствующие им угрозы.

1. Установление соединения.

2. Аутентификация

3. Работа после аутентификации

4. Завершение сессии, разрыв соединения.

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

При установлении соединения могут быть использованы идеи, изложенные в RFC-1644.

Вначале процесса установления соединения отправитель (А) посылает дейтограмму по IP-адресу конечного получателя (Б). Ближайший к отправителю узел, который поддерживает протокол NTCP, перехватывает посланный пакет, заносит его в буфер, и немедленно посылает исходному отправителю подтверждение получения. Это подтверждение перехватывается ближайшим NTCP-маршрутизатором, уведомляя его о том, что посланный им сегмент благополучно доставлен. Этот процесс будет продолжаться до тех пор, пока дейтограмма не будет получена конечным адресатом.

В результате будет сформирована цепочка туннелей с номерами i=1,…,n, каждый из которых содержит от одного до k шагов (см. рис. 3). Первый шаг на рисунке соответствует туннелю A-1, содержащему К шагов.

Выигрыш в эффективности использования полосы каналов тем больше, чем больше узлов вдоль пути поддерживают NTCP (в идеале k º1). Если таких узлов вообще нет - выигрыша не будет.

Рис. 3.

Для каждого из туннелей (А-1), (1-2), (2-3), (3-4), (4-5), … и (n-1 - n) на маршруте от А до Б реализуется традиционный протокол ТСР. Если буфер в одном из промежуточных узлов оказывается близок к переполнению, он будет посылать отклики, которые уведомляют соседа-отправителя о сложившейся ситуации (это справедливо для сегментов (1-2), (2-3),. (4-5), … и (n-1 - n)). Отправитель перестанет посылать очередные пакеты. В свою очередь его сосед выше по течению (в направлении к А) может оказаться в режиме близком к переполнению и будет вынужден уведомить об этом своего предшественника. Для сегментов (А-1) и (3-4) модель работы идентична традиционному протоколу ТСР. В области узлов А и Б могут присутствовать переключатели уровня L2, не поддерживающие протокол NTCP.

Но в данной схеме, так же как и во всех моделях ТСР нет механизма подавления потери пакетов из-за их искажения. Если вероятность такого искажения существенна, нужно рассмотреть возможность оптимального определения MTU (см. например, RFC-2923). Впрочем при полной информации о состоянии буферов вдоль маршрута, отправитель может легко идентифицировать причину потери.

Не следует забывать о возможности “агрессивного” поведения одного из агентов по пути от А к Б. Имеется в виду игнорирование предупреждения о близости переполнения, ведь помимо узлов, показанных на рисунке, могут быть агенты, которые подключены к этим же узлам и осуществляют через них передачу данных.

Обе эти проблемы не могут быть решены методами управления CWND. Но ситуация, когда партнер, которому послано уведомление о предкритическом состоянии, продолжает посылать пакеты, разрешается простым игнорированием (отбрасыванием) таких пакетов.

Следует иметь в виду, что “ потеря пакета” может быть связана не только с реальной потерей кадра (из-за переполнения буфера или искажения пакета), но и с потерей подтверждения получения, вызванного теми же причинами. Отправитель может знать, что буфер получателя пуст, но не получив своевременно подтверждения на посланный ранее сегмент, будет вынужден запустить процедуру медленного старта (или повторной передачи неподтвержденного сегмента). Реально это может быть объяснено переполнением, например буфера в одном из промежуточных сетевых устройств, не поддерживающих NTCP. Если k =1, потеря пакета в такой ситуации может не сопровождаться процедурой медленного старта, так как очевидно, что переполнения буфера у получателя не произошло, а потеря носит случайный характер и достаточно ограничиться повторной передачей сегмента (значение CWND сохраняется неизменным). При k>1 такая стратегия недопустима и следует использовать одну из стандартных моделей реализации протокола ТСР. При этом необходим механизм контроля наличия буферизующих сетевых устройств между двумя узлами, поддерживающими NTCP. Иными словами нужен механизм определения, равно ли k единице.

Можно конечно предложить NTCP-отправителю посылать IP-дейтограммы с заданным значением TTL (например, 30). Тогда, если очередной узел, поддерживающий NTCP, получит пакет с TTL=29, то k=2. Каждый сетевой прибор, поддерживающий NTCP, должен присваивать перед отправкой полю TTL указанное значение.

Беда в том, что по дороге могут быть включены устройства уровня L2, не посылающие никаких откликов (что, собственно, характерно в настоящее время для всех приборов L2) и не изменяющие значение TTL. Тогда придется использовать традиционные механизмы управления перегрузкой с помощью медленного старта. Для сервис-провайдеров, которые знают структуру своих каналов (отсутствие приборов L2), можно использовать контроль по TTL. Мониторирование TTL может быть полезно и с точки зрения безопасности (выявление ложных маршрутизаторов).

Заполнение буфера получателя происходит за счет разности между входным потоком сегментов Iin и темпом обработки сегментов Iout (отправки последующим узлам).

Рис. 4.

На рисунке 4 показана временная зависимость заполнения буфера (b) сетевого устройства. Темп заполнения буфера определяется производной db/dt. Если уровень заполнения достигает Вmax, следующий пришедший сегмент будет потерян. Значение Вmax в общем случае определяется неравенством Вmax > B ×RTT/MSS. Сетевое устройство должно отслеживать уровень заполнения своего буфера. И, если после получения очередного сегмента оказывается, что

(b(t) + db/dt ×RTT + d) ³Вmax,

то всем отправителям-соседям, которые используют данное устройства для передачи данных, должен быть послан отклик с window=0 (сигнал прекращения передачи). d - конфигурационный параметр. Выполнение данного условия делает переполнение буфера практически маловероятным. Если после получения window=0 клиент все равно посылает сегмент (“агрессивное” поведение), такой сегмент отбрасывается и в буфер не попадает, даже если там имеется свободное место. Если значение db/dt=0 или отрицательно, а уровень заполнения буфера невелик, то CWND делается равным window. Window ¹0 посылается клиентам, например, при выполнении условия b(t) < (Вmax -2d). Алгоритм управления значением CWND отправителей по возможности не должен допускать такого развития событий. При получении отклика, в котором содержится уведомление, что b(t) ³ (Вmax -2d) значение CWND должно быть уменьшено на 1 (при двух таких уведомлениях подряд - на 4 и т.д.). Стратегия может варьироваться. Так как и отправитель и получатель владеют полной информацией, можно даже ввести наказание для отправителей, нарушающих принятые правила (отбрасывание пакетов в течение заданного времени или установка window=0).

В традиционной версии TCP для установления оптимального значения window предусмотрен режим медленного старта. Это делается через механизм управления CWND. Для оптимального использования канала должно выполняться очевидное условие window > RTT×B/MSS. В любой момент времени window = min(window,CWND), то есть почти всегда меньше оптимального значения.

А при медленном старте CWND варьируется от 1 до максимально возможного значения, которое может быть меньше window. Связано это с тем, что ни отправитель, ни получатель обычно не владеет информацией о заполнении буферов и поиск допустимой величины window осуществляется на ощупь.

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

Если буфер свободен (b=0, что нормально в начале передачи), и RTT× B/MSS < Вmax, то реализуется значение CWND=window= RTT ×B/MSS и, тем самым, исключается этап медленного старта. Значение RTT предполагается определенным на фазе установления соединения. Алгоритмы вычисления среднего значения RTT и величины RTO остаются теми же, что и в традиционном протоколе ТСР.

Проблемы безопасности

Аутентификация должна производиться в соответствии с общепринятыми способами сразу после установления соединения в процессе открытия прикладной сессии. Вообще говоря, эта процедура не должна быть частью протокола ТСР (см. также RFC-2873). На фазе аутентификации клиент и сервер обмениваются ключами, которые могут использоваться в процессе обмена в рамках протокола ТСР. Коды эти могут быть подтверждены сертификатами.

На фазе 3 в поле данных отклика (или в специально выделенное поле опций заголовка) может включаться код, присланный отправителем и закодированный (одноключевая схема шифрования) получателем, так что в случае вторжении злоумышленника в разрыв соединения он сможет прервать сессию, но подменить собой клиента или сервер ему не удастся. Атака с подбором ISN станет бессмысленной. Нельзя будет реализовать и атаку с посылкой флагов FIN, RST или ICMP в пакете, посланном не одним из партнеров соединения. Получатель принимает только ключ своего непосредственного соседа, а свой ключ посылает только соседу ”вниз по течению” (в направлении узла Б).

Ссылки

RFC0793 Transmission Control Protocol. J. Postel. Sep-01-1981.

RFC1323 TCP Extensions for High Performance. V.

Jacobson, R. Braden, D. Borman. May 1992.

RFC1644 T/TCP -- TCP Extensions for Transactions Functional Specification. R. Braden. July 1994.

RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.

RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. April 1998.

RFC2414 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. September 1998.

RFC2415 Simulation Studies of Increased Initial TCP Window Size. K. Poduri, K. Nichols. September 1998.

RFC2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T. Shepard, C. Partridge. September 1998.

RFC2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. March 1999.

RFC2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999.

RFC2582 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson. April 1999.

RFC2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan, V. Paxson, E. Crabbe. June 2000.

RFC2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000.

RFC2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.

RFC2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000.

RFC3042 Enhancing TCP's Loss Recovery Using Limited Transmit. M. Allman, H. Balakrishnan, S. Floyd. January 2001.

RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001.

RFC3390 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge.

October 2002.

RFC3448 TCP Friendly Rate Control (TFRC): Protocol Specification. M. Handley, S. Floyd, J. Padhye, J. Widmer. January 2003.

RFC3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002.

RFC3465 TCP Congestion Control with Appropriate Byte Counting (ABC). M. Allman. February 2003

RFC3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. E. Blanton, M. Allman, K. Fall, L. Wang. April 2003.

1. Ю.А.Семенов “Протоколы Интернет. Энциклопедия”, Горячая линия - Телеком, М, 2001.

2. T. V. Lakshman, Upamanyu Madhow, “The performance of TCP/IP for networks with high bandwidth-delay products and random loss” Infocom ’97, апрель, 1997, IEEE/ACM Trans. Networking, V5, N3, p.336-350, June 1997. (http://www.ece.ucsb.edu/Faculty/Madhow/publications.html/)

NIL

Специальный атом "NIL" представляет собой указание на отсутствие каких-то определенных данных типа строка или “список в скобках”. Его следует отличать от пустой строки "" или пустого “списка в скобках” ().

NSAP адреса

Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):

Рис. 4.4.1.1.7

О протоколе верхнего уровня Контрольные суммы верхнего уровня

Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):

Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP

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

Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.

В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.

В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на FFFF для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.

IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.

О размере пакетов

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.

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

Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать.

В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.

Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел “думает”, что адресат находится на том же канале что и сам узел.

Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.

Обязательные AVP

Получение неизвестной AVP, которая имеет бит M=1, является катастрофическим для сессии или туннеля, с которым она ассоциирована. Таким образом, бит M должен быть определен только для AVP, которые критичны для нормальной работы сессии или туннеля. Далее, в случае, когда LAC или LNS получают неизвестную AVP с M-битом равным 1 и закрывают сессию или туннель, ответственность за это полностью несет партнер, пославший обязательную AVP. Прежде чем определить AVP с M=1, в особенности AVP специфичное для данного производителя, убедитесь в том, что вы именно этого хотите.

Когда имеется адекватная альтернатива использованию M-бита, ей следует воспользоваться. Например, вместо того, чтобы посылать AVP с M=1 для определения существования специфического расширения, можно решить проблему путем посылки AVP в сообщении-запросе в расчете на получение соответствующего AVP в отклике.

Использование M-бита с новыми AVP (не определенными в этом документе) должно предоставить возможность сконфигурировать программу так, чтобы AVP либо не посылалась, или посылалась с M-битом равным нулю.

Области, не поддерживающие RSVP

Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP вероятно никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако, если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг реального времени.

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

Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP' и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210].

При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.

Обозначения

Алгоритмы фильтрации и селекции NTP используют несколько переменных для хранения значений сдвига часов, RTT и дисперсии. Переменные, относящиеся к партнерам, обычно обозначаются строчными греческими буквами, а для первичного эталона времени используются прописные буквы. Эти алгоритмы базируются на параметре, называемом расстояние синхронизации

(l) и вычисляемом с использованием rtt и дисперсии.

Дисперсия партнера (e) содержит вклады от ошибок измерения (r) и накопления ошибок дрейфа (skew-error).

Каждый раз, когда соответствующие переменные партнеров изменяются, значения дисперсии корректируются. Ниже приводятся основные определения переменных и формулы их вычисления:

q = peer.offset,

d = peer.delay,

e = peer.dispersion = r + jt + es,

l = e + |d|/2,

где d = rtt, q - сдвиг часов, jt - накопление сбоя, j = ntp.maxskew/ntp.maxage, t - момент времени передачи исходной временной метки (на основе t вычисляется q и d), e

- дисперсия фильтра. Переменные, относящиеся к партнеру i, определяются следующим образом:

q i = j i,

d i = peer.rootdelay + d i,

e i = peer.rootdispersion + e

i + j ti

(максимальная дисперсия часов партнера),

li= ei + |di|/2,

Окончательно, предполагая, что для синхронизации выбран i-ый партнер, система переменных определяется следующим образом:

q = комбинированное окончательное смещение (combined final offset),

d = di,

e = ei + ex + q,

l = li,

где ex дисперсия выбора (select dispersion).

Приводимые ниже тексты программ, реализующие вычисления переменных, записаны на условном языке, напоминающем СИ.

Обработка событий

Существенные события с точки зрения протокола NTP происходят при истечении времени таймеров партнера (peer.timer), один из которых ориентирован специально на данного партнера в активной ассоциации, а также при получении NTP-сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой как отказ первичного эталона.

Общий формат сообщений

Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.

В данном документе определены форматы для следующих сообщений ICMPv6:

Сообщения об ошибках ICMPv6:

1 destination unreachable (место назначения недоступно)

2 packet too big (пакет слишком велик)

3 time exceeded (время превышено)

4 parameter problem (проблема с параметрами)

Информационные сообщения ICMPv6:

128 echo request (Запрос эхо)

129 echo reply (Эхо-отклик)

130 group membership query (запрос участия в группе)

131 group membership report (отчет об участии в группе)

132 group membership reduction (сокращение числа участников в группе)

Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)

Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):

Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6

Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.

Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:

Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.

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

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

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

Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.

Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.

Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.

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

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

В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6.

Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

(e.1) сообщения об ошибке ICMPv6, или

(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) - чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.

(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.

Существует много способов ограничения частоты посылки сообщений, например:

(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).

Общий заголовок

Рис. 4.4.9.6.8. Формат общего заголовка

В общем заголовке имеются следующие поля:

Vers. 4 бита - Номер версии протокола. В данном описании = 1.

Флаги: 4 бита - 0x01-0x08. Зарезервированы.

Флаги пока не определены.

Тип Msg. Тип сообщения (8 бит).

1 = Path

2 = Resv

3 = PathErr

4 = ResvErr

5 = PathTear

6 = ResvTear

7 = ResvConf

Контрольная сумма RSVP: 16 бит

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

Send_TTL: 8 бит

Значение TTL для протокола IP, с которым было послано сообщение.

Длина RSVP: 16 бит

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

Обсуждение реализации

Базовая модель надежности NTP предполагает, что не должно быть никаких других способов изменения показаний кроме предусмотренных самим протоколом NTP. Системы с часами-календарем, имеющие питание от батареи или аккумулятора, считаются надежными, но менее точными, чем использующие NTP-синхронизацию. При последовательных коррекциях, если величина поправки превышает конфигурационный параметр (напр., 1000 секунд), поправка отбрасывается и посылается сообщение об ошибке. Некоторые реализации периодически записывают содержимое регистра Skew-Compensation (компенсация дрейфа) в системный файл или в NVRAM (память, сохраняемая при отключении питания).

Преобразование из формата NTP в обычный информационный формат осуществляется прикладными программами. В день накануне добавления/вычитания секунды из показаний времени значение sys.leap устанавливается на первичном сервере вручную. Следует иметь в виду, что большинство радио-часов не имеет автоматических или ручных средств добавления/вычитания секунд. Но даже в случае некорректного добавления/вычитания секунды локальные часы будут вновь синхронизованы не позднее чем через число секунд, заданное CLOCK.MINSTEP.

Обзор AVP

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

Одновременное исполнение нескольких команд

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

Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента.

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

Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:

FETCH + NOOP + STORE

STORE + COPY + FETCH

COPY + COPY

CHECK + FETCH

Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций:

FETCH + STORE + SEARCH + CHECK

STORE + COPY + EXPUNGE

Опции

Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):

Рис. 4.4.1.1.16 Формат опций

Тип опции	8-битовый идентификатор типа опции.
Длина опции	8-битовое целое число без знака. Длина поля данных опции в октетах.
Данные опции	Поле переменной длины. Данные зависят от типа опции.

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

Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:

00	обойти эту опцию и продолжить обработку заголовка.
01	выбросить данный пакет.
10	выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции.
11	выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции.

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

0 - Данные опции не меняют маршрута

1 - Информация опции может изменить маршрут.

Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:

2n	означает любое двухоктетное смещение от начала заголовка.
8n+2	означает любое 8-октетное смещение от начала заголовка плюс 2 октета.

Существует две опции заполнения, которые используются, когда необходимо выровнять последующие опции и вывести границу заголовка на значение кратное 8 октетам. Эти заполняющие опции должны распознаваться всеми приложениями IPv6:

Опция Pad1 (выравнивание не требуется)

Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.

Опция padn (выравнивание не требуется)

Рис. 4.4.1.1.17

Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов

Опции заголовка Hop-by-Hop (шаг за шагом)

Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):

Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop

Следующий заголовок	8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком опций hop-by-hop. Использует те же значения поля протоколов, что и IPv4 [RFC-1700]
HDR EXT LEN	8-битовое число без знака. Длина заголовка поля опций hop-by-hop в октетах, исключая первые 8 октетов.
Опции	Поле переменной длины. Содержит один или более TLV-закодированных опций.

В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:

Опция Jumbo Payload

(необходимо выравнивание: 4n + 2)

Рис. 4.4.1.1.19.

Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload.

Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции.

Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента.

Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных).

Операции клиента SNTP

Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.

Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp. В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.

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

Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.

Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток.

Таблица 4.4.16.5. Типы временных меток

Имя временной метки	ID	Когда генерируется
Originate Timestamp (исходная метка)	T1	Время отправки запроса клиента
[ZEBR_TAG_td style=text-align:center>T2	Время получения запроса сервером
Transmit Timestamp (метка посылки)	T3	Время посылки отклика сервером
Destination Timestamp (метка назначения)	T4	Время получения отклика клиентом

Циклическая (roundtrip) задержка d и смещение локальных часов t определяются как:

d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.

В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы “Отклик” и “Мультикаст”. Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой “Игнорируется”, зависит от конкретной реализации программы.

Таблица 4.4.16.6. Операции клиента и значения полей заголовка

Имя поля	Уникаст/Эникаст	Мультикаст
Запрос	Отклик
LI	0	0-2	0-2
VN (номер версии)	1-4	копируется из запроса	1-4
Режим	3	4	5
Слой	0	1-14	1-14
Запрос	0	Игнорируется	Игнорируется
Точность	0	Игнорируется	Игнорируется
Root Delay	0	Игнорируется	Игнорируется
Root Dispersion	0	Игнорируется	Игнорируется
Reference Identifier	0	Игнорируется	Игнорируется
Reference Timestamp	0	Игнорируется	Игнорируется
Originate Timestamp	0	(смотри текст)	Игнорируется
Receive Timestamp	0	(смотри текст)	Игнорируется
Transmit Timestamp	(смотри текст)	не равно нулю	не равно нулю
Аутентификатор	опционно	опционно	опционно

Операции сервера SNTP

Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.

Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме.

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

Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой - 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.

Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса. В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.

Таблица 4.4.16.7

Имя поля	Уникаст/Эникаст	Мультикаст
Запрос	Отклик
LI	игнорируется	0 или 3	0 или 3
VN	1-4	копия из запроса	4
Режим	3	2 или 4	5
Слой	игнорируется	1	1
Регистрация	игнорируется	копия из запроса	log2 периода запросов
Точность	игнорируется	-log2 числа значащих бит сервера	-log2 числа значащих бит сервера
Root Delay	игнорируется	0	0
Root Dispersion	игнорируется	0	0
Идентификатор эталона	игнорируется	Идентификатор эталона	Идентификатор эталона
Reference Timestamp	игнорируется	время последней коррекции по радио-часам	время последней коррекции по радио-часам
Originate Timestamp	игнорируется	копируется из поля transmit timestamp	0
Receive Timestamp	игнорируется	время дня	0
Transmit Timestamp	(см. текст)	время дня	время дня
Аутентификатор	опционно	опционно	опционно

Наиболее важным индикатором неисправности сервера является поле LI, в котором код 3 указывает на отсутствие синхронизации. Когда получено именно это значение, клиент должен проигнорировать сообщение сервера вне зависимости от содержимого других полей.

Операционные соображения Присвоение имени почтовому ящику

Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере" (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.

Определение частоты

В течение многих лет наиболее важным использованием времени и частоты были всемирная навигация и космическая наука, которые зависят от наблюдений солнца, луны и звезд. За стандартную секунду (в 1957 году) принята 1/31,556,925.9747 периода вращения Земли вокруг Солнца (тропический год). Согласно этой шкалы тропический год длится 365.2421987 дней, а лунный месяц 29.53059 дней. Однако тропический год может быть определен лишь с точностью около 50 мсек.

С древнейших времен человечеству были известны три осциллятора (процесса задающих временную шкалу) - вращение земли вокруг своей оси, вращение Луны вокруг Земли и вращение Земли вокруг Солнца. К сожалению, с точки требований современных технологий все эти три осциллятора не обладают достаточной стабильностью. В 1967 стандартная секунда была переопределена и теперь равняется 9,192,631,770 периодов перехода в атоме цезия-133. С 1972 стандарты времени и частоты базируются на международном атомном времени TAI (International Atomic Time). Точность таких часов составляет около микросекунды в сутки. Важно то, что новая шкала абсолютно однородна и не подвержена дрейфам.

Определение новой ресурсной записи и домена

Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.

Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).

128-битовый IPv6-адрес записывается в информационной части ресурсной записи aaaa, придерживаясь порядка байт, используемого в сети (старший байт первый).

Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.

Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.

Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.

IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу

4321:0:1:2:3:4:567:89ab

будет выглядеть как

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.

Определение времени и необходимости добавления/вычитания секунды

Международное бюро мер и стандартов IBWM (International Bureau of Weights and Measures) использует астрономические наблюдения, выполненные морской обсерваторией США и другими обсерваториями для определения UTC.

Для более точной временной привязки событий после 1972 года необходимо знать, когда вставлялись или удалялись секунды коррекции (удаление пока никогда не производилось). Как определено в докладе 517 CCIR, который воспроизведен в [BLA74], дополнительные секунды вставляются после 23:59:59 в последний день июня или декабря. Неоднородность во временную шкалу (TAI) помимо добавляемых секунд вносят также 100 миллисекундные коррекции UT1, называемые DUT1, которые служат для повышения точности при навигации. Следует признать, что момент добавления секунды является началом новой (однородной) временной шкалы.

Временная шкала NTP базируется на шкале UTC, но необязательно всегда совпадает с ней. В 0 часов 1 января 1972 начинается эра UTC, часы NTP были установлены на 2,272,060,800 стандартных секунд после 0 часов 1 января 1900.

Определения

Поле данных RTP: Информация, пересылаемая в пакете RTP, например фрагменты звука или сжатые видео данные.

Пакет RTP: Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет, но это требование не является обязательным. Поле источников информации может быть пустым.

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

Транспортный адрес: Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP: Период с момента установления группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.

Источник синхронизации (SSRC): Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации образуют часть с идентичной временной привязкой и нумерацией. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Участник сессии не должен использовать один и тот же SSRC-идентификатор для всех RTP-сессий мультимедийного набора. Если участник формирует несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), каждый участник должен быть снабжен уникальным SSRC-идентификатором.

Информационный источник CSRC (contributing source): Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

Оконечная система: Приложение, которое генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Оконечная система может выступать в качестве одного или нескольких источников синхронизации для конкретной сессии.

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

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

Монитор: Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [3]. Если не оговорено обратного все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4.

Октеты-заполнители содержат нули.

Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 [4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит целочисленная часть и 16 бит дробная).

Заголовок RTP-пакета имеет следующий формат (см. рис. 4.4.9.2.1).

Рис. 4.4.9.2.1. Заголовок пакета RTP

Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:

v (Версия): 2 бита

Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 - в аудио приложении "vat".

p (Заполнитель): 1 бит

Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

x (Расширение): 1 бит

Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.

CC(CSRC count - число CSRC): 4 бита

Число CSRC содержит код количества csrc-идентификаторов, которые записаны в пакете.

M (маркер): 1 бит

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

PT(Тип данных): 7 бит

Это поле идентифицирует формат поля данных RTP-пакета и определяет интерпретацию его приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft draft-ietf-avt-profile, и может быть расширен в следующих редакциях стандарта assigned numbers (RFC-1700) [5].

Номер по порядку: 16 бит

Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [6].

Временная метка: 32 бита

Временная метка соответствует времени стробирования для первого октета в информационном RTP-пакете. Время стробирования должно быть получено от часов, показания которых увеличиваются монотонно и линейно, чтобы обеспечить синхронизацию и вычисление временного разброса. Разрешающая способность часов должна быть достаточной для обеспечения приемлемой точности синхронизации (одного тика на видео кадр обычно не достаточно). Частота часов зависит от формата данных и задается статически в профайле, в спецификации поля данных, или динамически средствами, выходящими за пределы спецификации протокола RTP. Если RTP-пакеты генерируются периодически, используется временная привязка, определенная задающим генератором стробирования, а не показаниями системных часов.

Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к и тому же видео кадру).

SSRC: 32 бита

Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список: от 0 до 15 элементов, по 32 бита каждый

CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

Для эффективной реализации протокола число точек мультиплексирования должно быть минимизировано. В RTP, мультиплексирование осуществляется по транспортным адресам мест назначения, которые определены RTP-сессией. Использование пакетов с различным типом поля данных но с идентичным ssrc создает определенные проблемы:

1. Если один из типов данных будет изменен в ходе сессии, нет универсальных средств для определения, какое из старых значений следует заменить на новое.

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

3. RTCP-сообщения отправителя и получателя могут описать только одно пространство номеров и временных меток для каждого SSRC и не имеют поля типа данных.

4. RTP-смеситель не сможет объединять перекрывающиеся потоки при условии их несовместимости.

5. Работа со многими средами в пределах одной RTP-сессии предполагает: использование различных сетевых путей или разного размещения сетевых ресурсов; приема только одного субнабора, например аудио, когда видео недоступно из-за недостатка широкополосности.

Использование различных ssrc для каждого вида среды, при посылке их в пределах одной RTP-сессии позволяет преодолеть первые три проблемы.

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

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

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

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

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

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

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

Рис. 4.4.9.2.2. Формат расширения заголовка

Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список csrc. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Для того чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров.

Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение.

Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, ip/udp), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий.

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

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

Следствием первого правила является то, что области не должны быть соединены более чем одним смесителем или транслятором.

Аналогично все оконечные системы RTP, которые взаимодействуют через один или более трансляторов или смесителей, принадлежат одной и той же ssrc-области, т.е., ssrc-идентификаторы должны быть уникальными для задействованных оконечных систем. Существует большое разнообразие трансляторов и смесителей, спроектированных для решения различных задач и приложений. Некоторые служат для шифрования/дешифрования несущих дейтограмм. Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители объединяют несколько потоков в один.

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

Приемник не может заметить присутствия транслятора.

Смеситель. Принимает потоки RTP-данных от одного или нескольких источников, может изменять формат данных, определенным образом объединяет потоки и затем формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Смеситель является источником синхронизации. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести свои SSRC-идентификаторы в список CSRC-идентификаторов, который следует за фиксированным RTP-заголовком пакета. Смеситель, который, кроме того, вносит в общий поток свою составляющую, должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета.

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

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

Рис. 4.4.9.2.3 Пример RTP сети с оконечными системами, смесителями и трансляторами

Некоторый набор смесителей и трансляторов представлен на рис. 4.4.9.2.3. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены желтым цветом. Трансляторы обозначены буквами TRS (на рисунке овалы голубого цвета) и смесители обозначены как MUX (прямоугольники сиреневого цвета). Запись "M1:13(1,17)" обозначает пакет отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2.

Последовательное включение смесителей

В RTP- сессии могут быть задействованы несколько смесителей и трансляторов, как это показано на рис. 4.4.9.2.3. Если два смесителя включены последовательно, так как MUX2 и MUX3, пакеты полученные смесителем могут быть уже объединены и включать CSRC-список со многими идентификаторами. Cмеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36). Если число идентификаторов в списке CSRC превышает 15, остальные не могут быть туда включены.

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

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

Не приемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации.

Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N число источников, а L длина идентификатора (в нашем случае, 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [8]) составляет 1 - exp(-N2 / 2(L+1)). Для N=1000, вероятность примерно равна 10-4.

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

Рассмотрим случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L длина идентификатора, вероятность столкновения равна N / 2L. Для N=1000, вероятность составит около 2*10-7.

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

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

Хотя вероятность столкновения идентификаторов SSRC довольно мала, все RTP реализации должны быть готовы обнаруживать столкновения и предпринимать адекватные меры для их преодоления. Если источник обнаруживает в какой-либо момент, что другой источник использует тот же идентификатор SSRC, он посылает пакет RTCP BYE для старого идентификатора и выбирает новый. Если получатель обнаруживает, что два других источника имеют равные идентификаторы (столкновение), он может воспринимать пакеты от одного и игнорировать от другого до тех пор, пока это не будет зарегистрировано отправителями или CNAME.

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

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

Два транслятора некорректно поставленные в параллель, т.е., с одними и теми же мультикастными группами на обеих сторонах будут направлять пакеты от одной мультикастной группы к другой. Однонаправленные трансляторы могут создать две копии; двунаправленные трансляторы могут образовать петлю.

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

Это может быть выполнено непосредственно, через смеситель или через транслятор.

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

Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор с тем, чтобы ситуация не была интерпретирована, как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако, столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола ).

Для того чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако, когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание. Это требуется для того, чтобы избежать потока пакетов BYE.

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

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

Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC, или когда достаточно долго не приходит вообще никаких пакетов.

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

Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников.

IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:

THEN создать новую запись и внести туда транспортный адрес источника и SSRC или

CSRC вместе с кодом состояния.

CONTINUE (продолжить) обычную процедуру обработки.

Идентификатор найден в таблице

IF транспортный адрес источника из пакета совпадает с одним из записанных в таблице:

THEN CONTINUE Продолжить обычную процедуру обработки.

Обнаружено столкновение идентификаторов или зацикливание

IF идентификатор источника не совпадает с собственным идентификатором участника:

THEN IF идентификатор источника совпадает с тем, что содержится в фрагменте RTCP SDES содержащем элемент CNAME, который отличается от CNAME из рекорда таблицы:

THEN (опционно) Случилось столкновение посторонних идентификаторов.

ELSE (опционно) Случилось зацикливание.

ABORT Прервать обработку информационного или управляющего пакета.

Столкновение для идентификатора участника или зацикливание его пакетов

IF транспортный адрес найден в списке конфликтных адресов:

THEN IF идентификатор источника не найден во фрагменте RTCP SDES, содержащем CNAME, или если CNAME принадлежит участнику:

THEN (опционно) случилось зацикливание собственного трафика.

Записать текущее время в соответствующую запись таблицы конфликтных адресов.

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

Зафиксировать факт столкновения.

Внести новую запись в таблицу конфликтных адресов и зафиксировать время записи.

Послать пакет RTCP BYE с идентификатором SSRC.

Выбрать новый идентификатор.

Внести новую запись в таблицу идентификаторов источников со старым SSRC, транспортным адресом источника обработанного пакета.

CONTINUE Продолжить обычную процедуру обработки.

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

Когда из-за столкновения выбран новый SSRC-идентификатор, кандидат-идентификатор должен быть сверен с содержимым таблицы идентификаторов. Если такой код там уже имеется, должен быть выбран другой кандидат и процедура сверки повторена.

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

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

Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC 1423 [9], за исключением того, что используется заполнение кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10]. Приложения, которые используют шифрование должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио и видео приложениями в Интернет. Возможно применение и других криптографических средств.

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

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

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

Если RTP-пакеты переносятся посредством протокола, который поддерживает поточный метод передачи, должен быть определен механизм вложения. Механизм вложения должен быть детализован и в случае, когда транспортный протокол использует в поле данных заполнители.

Механизм вложения может быть определен в профайле даже в случае, когда для транспортировки RTP используется не поточный протокол, это позволяет укладывать несколько RTP-пакетов в одну дейтограмму транспортного протокола (например, UDP).

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

Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом а не самим протоколом. Однако, значение октета RTP-заголовка, который содержит бит(ы) маркера не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), для того чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.

Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, использования различных расширений (см. рис. 4.4.9.2.2) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.

В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный):

Заголовок поля данных RTP. Октет RTP заголовка, содержащий маркер тип поля данных, может быть переопределен с помощью профайла (например, можно изменить число маркерных битов).

Типы поля данных. Профайл обычно определяет набор форматов поля данных (напр., типов кодирования исходных данных) и соответствие между этими форматами и кодами типа поля данных. Для каждого описанного типа поля данных должна быть определена частота временных меток.

Дополнения к заголовку RTP. К стандартному RTP-заголовку могут быть добавлены новые поля, расширяющие функциональность приложения.

Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. рис. 4.4.9.2.2).

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

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

Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов.

Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам.

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

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

Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC-1889 на примере кодов, написанных на языке СИ.

Нижеприведенные определения заимствованы целиком из RFC, ссылка на который приведена в начале данного раздела. Все цифра представлены в формате, где первым является старший октет. Предполагается, что битовые поля размещаются без заполнителей в том же порядке, что и октеты.

/*

* rtp.h -- Файл заголовка RTP (RFC 1889)

*/

#include <sys/types.h>

/*

* Нижеприведенные определения предполагают 32-битовое представление, а в случаях

* 16- или 64-битового представлений необходимы соответствующие модификации.

*/

typedef unsigned char u_int8;

typedef unsigned short u_int16;

typedef unsigned int u_int32;

typedef short int16;

/*

* Текущая версия протокола.

*/

#define RTP_VERSION 2

#define RTP_SEQ_MOD (1<<16)

#define RTP_MAX_SDES 255 /* максимальная длина текста для SDES */

typedef enum {

RTCP_SR = 200,

RTCP_RR = 201,

RTCP_SDES = 202,

RTCP_BYE = 203,

RTCP_APP = 204

} rtcp_type_t;

typedef enum {

RTCP_SDES_END = 0,

RTCP_SDES_CNAME = 1,

RTCP_SDES_NAME = 2,

RTCP_SDES_EMAIL = 3,

RTCP_SDES_PHONE = 4,

RTCP_SDES_LOC = 5,

RTCP_SDES_TOOL = 6,

RTCP_SDES_NOTE = 7,

RTCP_SDES_PRIV = 8

} rtcp_sdes_type_t;

/*

* Заголовок RTP-пакета

*/

typedef struct {

unsigned int version:2; /* версия протокола */

unsigned int p:1; /* флаг заполнителя */

unsigned int x:1; /* Флаг расширения заголовка */

unsigned int cc:4; /* число CSRC */

unsigned int m:1; /* Бит маркера */

unsigned int pt:7; /* тип поля данных */

u_int16 seq; /* номер по порядку */

u_int32 ts; /* временная метка */

u_int32 ssrc; /* источник синхронизации */

u_int32 csrc[1]; /* опционный список CSRC */

} rtp_hdr_t;

/*

* Общее слово RTCP-заголовка

*/

typedef struct {

unsigned int version:2; /* версия протокола */

unsigned int p:1; /* флаг заполнителя */

unsigned int count:5; /* варьируется в зависимости от типа пакета */

unsigned int pt:8; /* тип пакета RTCP */

u_int16 length; /* Длина пакета в словах */

} rtcp_common_t;

/*

* Маска версии, бита заполнителя и типа пакета

*/

#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)

#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)

/*

* Блок отчета о приеме

*/

typedef struct {

u_int32 ssrc; /* Источник, для которого составлен отчет */

unsigned int fraction:8; /* доля потерянных пакетов с момента последнего SR/RR */

int lost:24; /* полное число потерянных пакетов */

u_int32 last_seq; /* номер последнего полученного пакета */

u_int32 jitter; /* разброс времени прихода пакетов */

u_int32 lsr; /* последний SR-пакет от этого источника */

u_int32 dlsr; /* задержка с момента последнего SR пакета */

} rtcp_rr_t;

/*

* элемент SDES

*/

typedef struct {

u_int8 type; /* тип элемента (rtcp_sdes_type_t) */

u_int8 length; /* Длина элемента (в октетах) */

char data[1]; /* текст */

} rtcp_sdes_item_t;

/*

* One RTCP packet

*/

typedef struct {

rtcp_common_t common; /* общий заголовок */

union {

/* sender report (SR) */

struct {

u_int32 ssrc; /* Отправитель, генерирующий этот отчет */

u_int32 ntp_sec; /* временная метка NTP */

u_int32 ntp_frac;

u_int32 rtp_ts; /* временная метка RTP */

u_int32 psent; /* послано пакетов */

u_int32 osent; /* послано октетов */

rtcp_rr_t rr[1]; /* список переменной длины */

} sr;

/* Отчет о приеме (RR) */

struct {

u_int32 ssrc; /* приемник, формирующий данный отчет */

rtcp_rr_t rr[1]; /* список переменной длины */

} rr;

/* описание источника (SDES) */

struct rtcp_sdes {

u_int32 src; /* первый SSRC/CSRC */

rtcp_sdes_item_t item[1]; /* список элементов SDES */

} sdes;

/* BYE */

struct {

u_int32 src[1]; /* список источников */

/* can' t express trailing text for reason */

} bye;

} r;

} rtcp_t;

typedef struct rtcp_sdes rtcp_sdes_t;

/*

* Информация состояния источников

*/

typedef struct {

u_int16 max_seq; /* наибольший зарегистрированный номер */

u_int32 cycles; /* shifted count of seq. number cycles */

u_int32 base_seq; /* основной порядковый номер */

u_int32 bad_seq; /* последний 'плохой' порядковый номер + 1 */

u_int32 probation; /* sequ. packets till source is valid */

u_int32 received; /* пакетов получено */

u_int32 expected_prior; /* пакет, ожидаемый в последнем интервале */

u_int32 received_prior; /* пакет, полученный за последний интервал */

u_int32 transit; /* относительное время передачи для предыдущего пакета */

u_int32 jitter; /* оценка временного разброса */

/* ... */

} source;

Получатель RTP-пакета должен проверить корректность заголовка. Здесь следует учитывать, что пакет может быть зашифрован. Если пакет не пройдет данную проверку (например, неверно дешифрован, ошибка в адресе или обнаружен неизвестный тип поля данных), должно быть выработано соответствующее сообщение. Ограниченная проверка допустима только для нового источника:

В поле версии RTP должен быть записан код 2.

Тип поля данных должен быть из числа известных, в частности он не должен быть равным SR или RR.

Если бит P=1, тогда последний октет пакета должен содержать правильное число октетов, в частности оно должно быть меньше полной длины пакета минус размер заголовка.

Бит X должен быть равен нулю, если профайл не указывает на использование механизма расширения.

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

Длина пакета должна согласовываться с CC и типом поля данных (если длина поля данных известна).

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

Программа update_seq, приведенная ниже гарантирует, что источник декларирован правильно после получения MIN_SEQUENTIAL последовательно пронумерованных пакетов. Она также проверяет номера пакетов SEQ и актуализует состояние источника пакетов в структуре, на которую указывает S.

Когда новый источник дает о себе знать впервые (т.е. его SSRC-идентификатор отсутствует в таблице), и для описания его состояния выделено место в памяти, S->probation должно быть сделано равным числу последовательных пакетов, которые должны быть зарегистрированы до того, как источник будет объявлен легальным (параметр MIN_SEQUENTIAL ), а переменной s->max_seq присваивается значение SEQ-1. s->probation помечает источник как еще нелегальный, так что описание его состояния может быть выброшено после короткой выдержки.

После того как источник признан легальным, номер по порядку считается корректным, если он не больше чем на MAX_DROPOUT впереди S->max_seq и не больше на MAX_MISORDER после.

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

Приведенные типовые значения параметров базируются на максимальном времени сбоя нумерации равном 2 секундам при скорости 50 пакетов/сек и времени таймаута 1 минута. Параметр таймаута MAX_DROPOUT должен соответствовать небольшой доле от 16-битового диапазона нумерации. Таким образом, после рестарта новый номер пакета с большой вероятностью не должен попасть в допустимый диапазон.

void init_seq(source *s, u_int16 seq)

{

s->base_seq = seq - 1;

s->max_seq = seq;

s->bad_seq = RTP_SEQ_MOD + 1;

s->cycles = 0;

s->received = 0;

s->received_prior = 0;

s->expected_prior = 0;

/* other initialization */

}

int update_seq(source *s, u_int16 seq)

{

u_int16 udelta = seq - s->max_seq;

const int MAX_DROPOUT = 3000;

const int MAX_MISORDER = 100;

const int MIN_SEQUENTIAL = 2;

*

* Источник нелегален до тех пор, пока не будет получено MIN_SEQUENTIAL пакетов

* с последовательно нарастающими номерами.

*/

if (s->probation) {

/* пакет соответствует последовательности */

if (seq == s->max_seq + 1) {

s->probation--;

s->max_seq = seq;

if (s->probation == 0) {

init_seq(s, seq);

s->received++;

return 1;

}

} else {

s->probation = MIN_SEQUENTIAL - 1;

s->max_seq = seq;

}

return 0;

} else if (udelta < MAX_DROPOUT) {

/* в порядке, с допустимым зазором */

if (seq < s->max_seq) {

/*

* Порядковый номер переполнен - начинаем новый 64K цикл.

*/

s->cycles += RTP_SEQ_MOD;

}

s->max_seq = seq;

} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {

/* порядковый номер изменился слишком сильно */

if (seq == s->bad_seq) {

/*

* Два последовательных пакета - предполагается, что другая сторона рестартовала, не

* предупредив нас об этом. re-sync (т.е., считаем, что получили первый пакет).

*/

init_seq(s, seq);

}

else {

s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);

return 0;

}

} else {

/* задублированные пакеты или пакеты с перепутанным порядком прихода */

}

s->received++;

return 1;

}

Проверка корректности может быть и жестче, требуя более двух пакетов с последовательными номерами подряд.

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

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

Для того чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов получается простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета (s->max_seq) и номером первого пакета в последовательности (S->base_seq). При этом нужно учитывать то, что номера имеют 16 бит, и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles).

extended_max = s->cycles + s->max_seq;

expected = extended_max - s->base_seq + 1;

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

lost = expected - s->received;

Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета:

expected_interval = expected - s->expected_prior;

s->expected_prior = expected;

received_interval = s->received - s->received_prior;

s->received_prior = s->received;

lost_interval = expected_interval - received_interval;

if (expected_interval == 0 lost_interval <= 0) fraction = 0;

else fraction = (lost_interval << 8) / expected_interval;

Результирующее значение доли равно 8-битовому числу с фиксированной запятой, расположенной слева.

Ошибки

Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.

Однако для синтаксически верных запросов резервирования имеется много способов быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема "резервирования килера", в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.

Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0. Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.

Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняется даже в случае не прохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю, установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.

Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, "состояние блокады", в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование.
Состояние резервирования Q1 считается в данном случае заблокированным.

Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако, эти резервирования были сохранены по следующим причинам:

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

Заказываемый ресурс доступен по всей длине пути, или

Нужно получить желаемый уровень QoS вдоль оговоренного пути так далеко, как это возможно. Конечно, во втором случае, а может быть и в первом, получатель захочет настаивать на резервировании, осуществленном вплоть до точки блокировки.

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

Если бы мы не обновляли резервирование в предшествующих узлах каждые Tb секунд, они могли бы быть удалены по таймауту (Tb время таймаута состояния блокады).

алгоритмы предложены Дикстрой) является альтернативой

4.4.11.2 Протокол OSPF (алгоритм Дикстры)

Семенов Ю.А. (ГНЦ ИТЭФ)

Протокол OSPF (Open Shortest Pass First, RFC-1245-48, RFC-1583-1587, алгоритмы предложены Дикстрой) является альтернативой RIP в качестве внутреннего протокола маршрутизации. OSPF представляет собой протокол состояния маршрута (в качестве метрики используется - коэффициент качества обслуживания). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (переключателей) автономной системы. Протокол OSPF реализован в демоне маршрутизации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP.

Автономная система может быть разделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный (designated) маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. На иллюстративном рис. 4.2.11.2.1 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они оказываются выбранными в результате рассмотрения графа (“кратчайшие пути“).

Рис. 4.2.11.2.1 Иллюстрация работы алгоритма Дикстры

Ниже дается формальное описание алгоритма. Сначала вводим некоторые определения.

Пусть D(v) равно сумме весов связей для данного пути.

Пусть c(i,j) равно весу связи между узлами с номерами i и j.

Далее следует последовательность шагов, реализующих алгоритм.

Устанавливаем множество узлов N = {1}. Для каждого узла v не из множества n устанавливаем D(v)= c(1,v).

Для каждого шага находим узел w не из множества N, для которого D(w) минимально, и добавляем узел w в множество N.

Актуализируем D(v) для всех узлов не из множества N

D(v)=min{D(v), D(v)+c(w,v)}.

Повторяем шаги 2-4, пока все узлы не окажутся в множестве N.

Топология маршрутов для узла a приведена на нижней части рис. 4.2.11.2.1. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3.

Таблица 4.2.11.2.1. Реализация алгоритма

	Множество	Метрика связи узла a с узлами
Шаг	N	B	C	D	E	F	G	H	I	J
0	{A}	3	-	9	-	-	-	-	-	-
1	{A,B}	(3)	4	9	7	-	10	-	-	-
2	{A,B,C}	3	(4)	6	6	10	10	8	-	14
3	{A,BC,D}	3	4	(6)	6	10	10	8	9	14
4	{A,B,C,D,E}	3	4	6	(6)	10	10	8	9	14
5	{A,B,C,D,E,H}	3	4	6	6	10	10	(8)	9	14
6	{A,B,C,D,E,H,I}	3	4	6	6	10	10	8	(9)	14
7	{A,B,C,D,E,H,I,F}	3	4	6	6	(10)	10	8	9	14
8	{A,B,C,D,E,H,I,F,G}	3	4	6	6	10	(10)	8	9	14
9	{A,B,C,D,E,H,I,F,G,J}	3	4	6	6	10	10	8	9	(14)

Таблица 4.2.11.2.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QoS) может характеризоваться следующими параметрами:

пропускной способностью канала;

задержкой (время распространения пакета);

числом дейтограмм, стоящих в очереди для передачи;

загрузкой канала;

требованиями безопасности;

типом трафика;

числом шагов до цели;

возможностями промежуточных связей (например, многовариантность достижения адресата).

Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF.

Отклик BAD

Содержимое: опционный код отклика;

текст, читаемый человеком

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

Пример: C: ...very long command line...

S: * BAD Command line too long

C: ...empty line...

S: * BAD Empty command line

C: A443 EXPUNGE

S: * BAD Disk crash, attempting salvage to a new disk!

S: * OK Salvage successful, no data lost

S: A443 OK Expunge completed

Отклик BYE

Содержимое: опционный код отклика;

текст, читаемый человеком

Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:

Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.

Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.

Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.

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

Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.

Пример: S: * BYE Autologout; idle for too long

Отклик CAPABILITY

Содержимое: список возможностей.

Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1".

Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.

Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".

Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.

Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN

Отклик EXISTS

Содержимое: отсутствует.

Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.

Пример: S: * 23 EXISTS

Отклик EXPUNGE

Содержимое: отсутствует.

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

Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи "снизу-вверх" пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.

Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.

Информация отклика EXPUNGE должна регистрироваться клиентом.

Пример: S: * 44 EXPUNGE

Отклик FETCH

Содержимое: текст сообщения.

Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:

BODY Форма BODYSTRUCTURE без расширения данных.

BODY[<section>]<<origin_octet>>

Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.

Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[ ] может быть укорочено, но BODY[ ] никогда не укорачивается.

Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.

Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность.

BODYSTRUCTURE - список, заключенный в скобки, который описывает [MIME-IMB],

структура тела сообщения.

Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию.

Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)

Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой.
Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).

Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED"))

Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:

Список параметров тела, заключенный в скобки.

Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB].

Размещение тела

Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.

Язык тела

Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].

Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:

Тип тела

Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].

Субтип тела

Строка, описывающая имя субтипа, как это определено в [MIME-IMB].

Список параметров тела, заключенный в скобки

Список пар атрибут/значение, заключенный в скобки, [например, ("foo" "bar" "baz" "rag"), где "bar" является значением "foo", а "rag" - значением "baz"], как это описано в [MIME-IMB].

Идентификатор тела

Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].

Описание тела

Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].

Шифрование тела

Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].

Размер тела

Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.

Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.

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

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

Данные расширения для несоставной части тела располагаются в следующем порядке:

MD5 тела

Строка, содержащая значение MD5 тела, как это описано в [MD5].

Размещение тела

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

Язык тела

Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].

Любые последующие данные расширения пока не определены в данной версии протокола.

ENVELOPE - список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения.

Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.

Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.

Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.

Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.

Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.

FLAGS	Список флагов, установленных для данного сообщения, заключенный в скобки.
INTERNALDATE	Строка, представляющая внутреннюю дату сообщения.
RFC822	Эквивалент BODY[].
RFC822.HEADER	Эквивалент BODY.PEEK[HEADER].
RFC822.SIZE	Число, выражающее размер сообщения [RFC-822].
RFC822.TEXT	Эквивалент BODY[TEXT].
UID	Число, выражающее уникальный идентификатор сообщения.

Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

Отклик FLAGS

Содержимое: список флагов, заключенный в скобки.

Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.

Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

Отклик исходящего вызова OCRP (Outgoing-Call-Reply)

Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ. Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP:

Тип сообщения (Message Type)

Assigned Session ID

Следующие AVP могут присутствовать в OCRP:

Physical Channel ID

Отклик LIST

Содержимое: атрибуты имени, иерархический разделитель, имя.

Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.

Определено четыре атрибута имени:

\Noinferiors	Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем.
\Noselect	Не допускается использование данного имени для именования почтового ящика, который может быть выбран.
\Marked	Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран.
\Unmarked	Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран.

Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.

Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.

Пример: S: * LIST (\Noselect) "/" ~/Mail/foo

Отклик LSUB

Содержимое: атрибуты имени, иерархический разграничитель, имя.

Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.

Пример: S: * LSUB () "." #news.comp.mail.misc

Отклик NO

Содержимое: опционный код отклика;

текст, читаемый человеком

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

Пример: C: A222 COPY 1:2 owatagusiam

S: * NO Disk is 98% full, please delete unnecessary data

S: A222 OK COPY completed

C: A223 COPY 3:200 blurdybloop

S: * NO Disk is 98% full, please delete unnecessary data

S: * NO Disk is 99% full, please delete unnecessary data

S: A223 NO COPY failed: disk is full

Отклик OK

Содержимое: опционный код отклика;

текст, читаемый человеком

Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.

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

Пример: S: * OK IMAP4rev1 server ready

C: A001 LOGIN fred blurdybloop

S: * OK [ALERT] System shutdown in 10 minutes

S: A001 OK LOGIN Completed

Отклик PREAUTH

Содержимое: опционный код отклика;

текст, читаемый человеком

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

Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith

Отклик RECENT

Содержимое: отсутствует.

Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).

Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.

Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.

Пример: S: * 5 RECENT