Качество обслуживания (QoS) в локальных сетях и не только

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Существует три модели реализации QoS: наилучшая возможная; интегральная и дифференцированная. Наилучший возможный вид услуг реализуется в сети, когда делается все возможное для доставки пакета, но при этом ничего не гарантируется (например FTP или HTTP). Интегрированный вид услуг (RFC-1633, 1994 год) разрабатывался первым и реализуется путем резервирования по схеме точка-точка (протокол RSVP; 1997; см. ). Протокол RSVP предоставляет сигнальный механизм для конфигурирования удаленных маршрутизаторов с целью получения нужного QoS. Протокол ориентирован на работу с тремя видами трафика: best efforts (обычная передача IP-данных без установления соединения), чувствительный к скорости передачи и чувствительный к задержкам.Трафик чувствительный к загрузке требует формирования канала с гарантированной пропускной способностью.Приложение при этом вынуждено мириться с определенными задержками доставки (класс услуг с гарантированной скоростью в битах в сек. Третий вид трафика (чувствительный к задержкам) гарантирует минимальную задержку и низкую дисперсию времени доставки. Пропускная способность может при этом варьироваться. Примером такого вида трафика может служить передача голоса или видео. RSVP определяет два типа услуг для этого видв трафика: сервис с контролируемыми задержками и предсказуемый сервис (для приложений реального времени (видео-конференции и телефонные переговоры).

В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса: QoS Class 1 (называемый также классом услуг А) имеет те же характеристики, что и выделенный цифровой канал точка-точкаQoS Class 2 (называемый также классом услуг В) обеспечивает режим, приемлемый для аудио и видео при видеоконференициях или передачи мультимедиа QoS Class 3 (называемый также классом услуг 3) обеспечивает режим, приемлемый для передачи, ориентированной на соединение, например, через посредство frame relay. QoS Class 4 (называемый также классом услуг 4) эквивалентен режиму IP-передачи в условиях наилучших усилий (best efforts) при отсутствии гарантии доставки.

Следует помнить, что в Интернет нет гарантий ни по задержке, ни вообще по доставке, что неприемлемо для передачи голоса (пропускная способность ? 16 кбит/с, максимально допустимая задержка <100мсек), видеоконференций и приложений виртуальной реальности.

Приложение в этой модели не будет осуществлять передачу, пока не получит подтверждения резервирования. Инициатором резервирования в этой модели всегда является получатель. Получатель в рамках RSVP анализирует параметры потока отправителя (Tspec) и посылает ему запрос резервирования Resv, который должны воспринять все промежуточные узлы (если они способны это сделать). Этот запрос специфицирует желательные параметры QoS. Для поддержания резервирования вдоль всего пути это сообщение должно периодически повторяться. В протоколе RSVP всего предусмотрено семь разных типов сообщений. Вообще RSVP превоначально предназначался для организации IP-телефонии. Если с помощью RSVP произведено резервирование всей полосы канала, никакая передача прочих данных через этот канал будет невозможна, пока хотя бы часть резервирований не будет отменена. Характер резервирования определяется спецификацией потока (flow spec). Если запрашивается лишь контроль загрузки, flow spec будет тождественна Tspec. Если же требуется гарантированный вид услуг, flow spec содержит Tspec и Rspec. Надо учитывать, что RSVP не очень удобен при работе с каналами малой пропускной способности. WFQ может начать работать, когда пакеты имеют разный приоритет. Существует 8 уровней приоритета (чем больше номер, тем выше приоритет): Приоритет управления сетью (7)Приоритет управления Интернет = межсетевое управление (6)Критический приоритет (5)Экстренный приоритет (4)Срочный приоритет (3)Немедленный приоритет (2)Предпочтительный приоритет (1)Ординартный приоритет (0)

Не ищите разъяснения смысла этих определений, его пока не существует... Значению 000 соответствует услуга наилучших усилий (best efforts). Архитектура listserv ориентирована на получение минимального временного разброса доставки при гарантии пропускной способности не ниже требуемой.


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

Когда установлены соответствующие биты поля TOS, WFQ настраивает обработку так, чтобы очереди с более высоким приоритетом продвигались быстрее, чем менее приоритетные очереди. Порядок обслуживания очередей остается тем же, но объем данных, обрабатываемых из очереди, зависит от веса очереди. Весовой коэффициент обратно пропорционален уровню приоритета. Все это справедливо, если приложение и все участники обмена поддерживают приоритетное обслуживание с использованием TOS. Следует иметь в виду, что методы приоритетного обслуживания используются не только для получения требуемого уровня QoS, но и для подавления перезрузки нанала. Смотри также .

Дифференциальный вид услуг (RFC-2474 и RFC-2475) предполагает наличие определенного набора средств классификации и механизмов организации очередей, обеспечивающих работу с приоритетами. Дифференциальный вид услуг обычно предполагает использование 6-битового поля DSCP (DiffServ Code Point) и определяет по-шаговое поведение вируального канала PHB (Per Hop Behavior). PHB задается сервис-провайдером и определяется на основе кода в поле DSCP. Запись в поле DSCP обычно осуществляется на входе сети. Поле DS (Differentiated Services), где размещается DSCP, фактически замещает поле TOS (RFC-791) в IP-заголовке. Стандартизации значений поля DS пока не произведено. Любая сеть должна поддерживать, по крайней мере, два класса PHB. Express Forwarding PHB (экспрессная переадресация) относится к наивысшему уровню услуг, возможному в модели Diffserv. Здесь для обеспечения низких потерь, малого временного разброса и гарантированной полосы используется RSVP. Diffserv достаточно хорошо адаптируется для работы в каналах с малой пропускной способностью.

Первой попыткой ввести некоторые параметры качества обслуживания относятся к 1981 году (RFC-791). Тогда было определено поле IP-заголовка TOS (Type of service; значения бит см. в ).


Позднее ( в 1992 году) определение TOS было скорректировано в RFC-1349 (определено 4 бита вместо трех). Из-за неопределенности механизмов реализации ToS реально это поле не использовалось в течение 20 лет. Значения бит поля TOS из RFC-1349 описаны в таблице:

0	1	2	3	4	5	6	7
Приоритет	X	X	X	X	0

Значения поля приоритет определены выше. 4 бита, обозначенные "X", теоретически допускают 16 значений. Практически из них используется только 5 кодов

1000 - Минимальная задержка
0100 - Максимальная пропускная способность
0010 - Максимальная надежность
0001 - Минимальная стоимость
0000 - Обычные (нормальные) услуги

Diffserv не определяет частоту отбрасывания пакетов, но утверждает, что класс 4 обрабатывается более приоритетно, чем класс 3 и что в пределах каждого AF (Assured Forwarding) все классы имеют преимущества перед прочими классами. В таблице ниже предствлены значения приоритетов для AF.

	Класс 1	Класс 2	Класс 3	Класс 4
Низкий приоритет отбрасыания	001010	010010	011010	100010
Средний приоритет отбрасыания	001100	010100	011100	100100
Высокий приоритет отбрасыания	001110	010111	011110	100110

В рамках diffserv могут использоваться несколько механизмов обработки очередей, например, WRED (Weighted Random Early Detection). Зарезервировав на фазе формирования канала в АТМ достаточно большую пропускную способность, можно минимизировать временной разброс (также как и в intserv).

Компания CISCO разработала специальную технологию для обеспечения нужного уровня QoS - CISCO Content Networkig (транспортировка через сеть с учетом содержимого). В рамках этой технологии решается фундаментальная проблема - классификации транспортируемых пакетов с учетом содержимого их заголовков. Сетевые технологии стремительно усложняются. Раньше было достаточно определить приоритет для определенного адреса или для заданного протокола, теперь этого мало. Один и тот же пользователь с фиксированным IP может в одно и то же воемя реализовать через сеть передачу голоса, осуществлять поиск информации в WEB-сети и т.д., причем все это делать в рамках одного и того же протокола.


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

CISCO для решения этой проблемы в IP-среде разработала специальное средство, называемое NBAR (Network Based Application Recognition - распознавание приложения по сетевым параметрам). Техника NBAR применима только к такому трафику, который может быть переадресован с помощью технологии CEF (Cisco Express Forwarding). NBAR может классифицировать HTTP-трафик не только по адресам и номерам портов, но и по информации, содержащейся в URL (до 400 байт). Реально NBAR просматривает 512 байт (сюда помимо URL входят заголовки L2, L3, L4 и HTTP). В рамках NBAR предусматривается классификация субпортов. NBAR классифицирует HTTP-трафик по mime-типу или get-запросам. Предельное число одновременно обслуживаемых URL-ЭВМ или mime-типов не должно превышать 24. Анализ NBAR 400 байт URL-заголовка способствует уменьшению вероятности злоупотреблений сетевыми ресурсами. Здесь появляется возможность выявления неавторизованной пересылки пользователями больших файлов mp3 и пр.. NBAR может классифицировать TCP и UDP-протоколы, использующие стандартизованные номера портов, а также и прочие протоколы (например, маршрутные, ICMP, IPSec, IPINIP, Kerberos, IMAP/SIMAP, HTTPS, L2TP, LDAP, NETBIOS, RSVP, SNNTP, NTP, POP3/SPOP3, SFTP, SSH, X-Windows, SOCKS и т.д.).

NBAR позволяет загружать в маршрутизатор шаблоны классификации в любой момент времени. Это осуществляется с помощью использования PDLM (Packet Description Language Module - модуль языка описания пакетов). PDLM копируется в флэш-память с консоли маршрутизатора или каким-то другим способом. Список поддерживаемых протоколов постоянно обновляется. Следует помнить, что NBAR сам по себе не обеспечивает QoS, а лишь выделяет определенный класс трафика из общего информационного потока. Раз трафик классифицирован, могут быть применены определенные механизмы для обеспечения определенного уровня сервиса.


В перечень таких услуг входят: Минимальная гаранитрованная полоса на основе сласса, определенного с помощью WFQ.Организация очередей с малой задержкой LLQ (Low Latency Queuing)Формирование политики трафика для ограничения загрузокФормирование трафика для избежания перегрузок.Исключение перегрузок, используя WRED (Weighted Random Early Detection)Пометка пакетов для использования архитектур diffserv или intservРеализация WFQ (Flow-based Weighted Fair Queuing)

Использование NBAR для классификации 500 потоков потребует дополнительно 1 Мбайт памяти. В младших моделях маршрутизаторов, например 2600, применение NBAR займет до 15% мощности процессора. Это обстоятельство следует учитывать, если нужно обеспечить определенный уровень QoS, ведь это потребует дополнительной мощности процессора. Применение CEF потребует еще больше ресурсов процессора. NBAR не поддерживает трафик, отличный от IP. NBAR не может таже использоваться для VLAN, многоканальных PPP (multilink PPP).

В то время как на уровне IP (L3) реализуется несколько подходов обеспечения QoS (intserv в RSVP и diffserv в MPLS; см. ), на уровне L2 ситуация пока много хуже. Следует, впрочем, признать, что решение в протоколе MPLS полностью пригодно и для L2. Требуется лишь появление на рынке сетевых приборов, поддерживающих MPLS или 802.1Q.

В стандарте 802.1Q (Virtual Bridged Local Area Network) определен тип маркированного кадра путем введения метки, содержащей следующие поля: TPID (Tagged Protocol Identifier) = 0x8100 (два октета). Этот идентификатор указывает программе, как следует обрабатывать остальную часть кадра. По назначению это поля совпадает с полем тип протокола стандартного кадра EthernetПриоритет пользователя (802.1Q; 3 бита). (Смотри )CFI (Canonical Format Identifier) - 1 битИдентификатор VLAN (ID) - 12 бит

При введении этих полей в кадр Ethernet приходится пересчитать контрольную сумму кадра (FCS). Для поддержки стандарта IEEE 802.1р канальный уровень должен работать с множественными очередями (по одной на каждый код приоритета).


В настоящее время разрабатывается стандарт расширения RSVP для 802.3 (SBM -Subnet Bandwidth Manager - http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-sbm-08.txt). Смотри также http://www.ietf.org/html.charters/issll-charter.html (Integrated Services over Specific Lower Layers).

Для управления протоколом SBM используются следующие мультикаст-адреса:
224.0.0.17 - все SBM-системы должны прослушивать этот адрес.
224.0.0.16 - все кандидаты DSBM должны прослушивать этот адрес.

Обычно важно обеспечить к ачество обслуживания (QoS) в режиме точка-точка (см. ). На практике это удается реализовать достаточно редко, в частности потому, что многие технологии LAN не поддерживают QoS. Ниже в таблице приведены приоритеты, поддерживаемые известными технологиями LAN (L2; см. ). В локальных сетях различают приоритет доступа (access_priority) и приоритет пользователя (user_priority). Значение приоритета пользователя формируется МАС-уровнем, помещается в соответствующее поле заголовка кадра и используется для обеспечения QoS в режиме точка-точка в среде переключателей L2. Значение приоритета доступа используется переключателем LAN для передачи кадров. Приоритет пользователя может быть не равен приоритету доступа. К сожалению кадры 802.3 и 802.11 соответствующих полей приоритета в заголовке не имеют. Значение 0 соответствует наинизшему приоритету. Коды приоритета используются переключателями при обработке очередей. Применение приоритетов регламентируется документом IEEE 802.1D (1998).

Таблица 1. Выходной приоритет доступа для разных технологий LAN

Приоритет пользователя	Выходной приоритет для МАС-технологий
802.3	802.4	802.5	802.6	802.11	802.12	FDDI
0	0	0	0	0	0	0	0
1	0	1	1	1	0	0	1
2	0	2	2	2	0	0	2
3	0	3	3	3	0	0	3
4	0	4	4	4	0	4	4
5	0	5	5	5	0	4	5
6	0	6	6	6	0	4	6
7	0	7	7	7	0	4	6

802.3	CSMA/CD
802.4	Token Bus
802.5	Token Ring
802.6	DQDB - Double Queue, Double Bus
802.11	Беспроводные локальные сети
802.12	100VGAnyLAN (с приоритетным запросом)
FDDI	Fiber Distributed Data Interface (token ring)

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

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

Ниже перечислены типы трафика, начиная с высоко приоритетного:

Управление сетью (7). Передача данных для поддержания сетевой инфраструктуры (кадры маршрутных протоколов.

Голос (6). Критичнен по задержке (< 10мсек) при интерактивных переговорах.

Видео (5). Критичнен по задержке (< 100мсек) при интерактивных видео обменах.

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

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

Наилучшие усилия (2). Это трафик обычный трафик LAN.

Фоновый режим (0, Background). Массовые пересылки данных и любая другая активность, не влияющая негативно на работу остальных.

Восьмой тип (1) оставлен на будущее, он имеет приоритет выше фонового, но ниже наилучших усилий. Это означает, что в каждом из выходных портов формируется до 8 очередей. Ниже в табл. 2 перечислены рекомендуемые приоритнты пользователя для указанных выше классов трафика.

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

Приоритет пользователя	Число доступных классов трафика
1
2	3	4	5	6	7	8
0 по умолчанию	0	0	0	1	1	1	1	2
1	0	0	0	0	0	0	0	0
2	0	0	0	0	0	0	0	1
3	0	0	0	1	1	2	2	3
4	0	1	1	2	2	3	3	4
5	0	1	1	2	3	4	4	5
6	0	1	2	3	4	5	5	6
7	0	1	2	3	4	5	6	7

Документ IEEE 802. 1D предлагает установить соответствие между приоритетом пользователя =0 и классом трафика =2. Когда имеется 8 кодов класса трафика, то приоритету пользователя 1 и 2 ставится в соответствие код класса трафика 0 и 1, соответственно. В таблице 3 представлено соответствие классов трафика и числа очередей. Если реализуется только одна очередь, то все классы трафика реализуются через нее. Если имеется две очереди (вторая строка таблицы 3), рекомендуется отнести классы с кодами 7, 6, 5 и 4 к высоко приоритетной очереди, а остальные - низко приоритетной. В нижней строке табл. 3 представлены значения кода приоритета пользователя.

Таблица 3. Рекомендуемое число очередей для разных классов трафика

Число очередей	Типы трафика
1
BE (EE,BK,Vo,CL,VI,NC)
2	BE(EE,BK)	VO(CL,VI,NC)
3	BE(EE,BK)	CL(VI)	VO(NC)
4	BK	BE(EE)	CL(VI)	VO(NC)
5	BK	BE(EE)	CL	VI	VO(NC)
6	BK	BE	EE	CL	VI	VO(NC)
7	BK	BE	EE	CL	VI	VO	NC
8	BK	-	BE	EE	CL	VI	VO	NC
Приоритет пользователя	1	2	0	3	4	5	6	7

Надписи полужирным шрифтом относятся к типу трафика, который определяет типы классов.

BK	- Background (фон)
BE	- Best Effort (наилучшие усилия)
EE	- Excelrnt Effort (максимальные усилия)
CL	- Controlled Load (контролируемая нагрузка)
VI	- Video (задержка и разброс доставки <100мсек)
VO	- Voice (голос, задержка и разброс доставки <10мсек)
NC	- Network Control (управление сетью)

Одним из наиболее приемлемых, но пока не реализованных в LAN протоколов обеспечения заданного уровня QoS является MPLS. Этот протокол, предназначенный первоначально для формирования VPN и ускорения коммутации пакетов, оказался весьма удобным и для классификации трафика, а также обеспечения требуемого уровня QoS. Пакеты, входящие в VPN из традиционной сети Интернет, снабжаются метками в краевых маршрутизаторах LER (Label Edge Router), именно здесь осуществляется классификация этих пакетов. Метка представляет собой идентификатор фиксированной длины (см. ). В данном протоколе маршрут пакета определяется метками, а не IP-адресом места назначения.


Полный анализ заголовка пакета выполняется только в краевом маршрутизаторе LER, последующие маршрутизаторы (или коммутаторы) рассматривают только метку (это касается и услуг с гарантированным QoS). Такое решение минимизирует время коммутации по сравнению с IP-сетями.

В современных сетях VPN часто содержат IP (PPP или Ethernet) и АТМ участки. Соединение сетевых элементов MPLS через АТМ каналы оказывается наиболее дешево. Обычно это реализуется с помощью постоянных виртуальных путей PVC ATM. Коммутация в АТМ производится в этом случае на основе поля VPI. Поле же VPI выполняет функцию метки. VPI-соединение должно быть заказано с определенным классом АТМ-сервиса. В АТМ предусмотрены следующие стандартные классы сервиса:

CBR - (Constant Bit Rate Service). Этот класс предназначен для передачи не сжатого голоса и видео при эмуляции канала

VBR-rt - (Variable Bit Rate Real Time). Этот класс предназначен для поддержки нестационапного (импульсивного) трафика, такого как сжатый голос и видео.

VBR-nrt - (Variable Bit Rate Non-Real Time). Этот класс может быть использован для импульсивных приложений, таких как Frame Relay через АТМ.

AVR - (Available Bit Rate). Этот класс первоначально предназначался для большинства приложений. Здесь применены механизмы управления трафиком, кторые управляют перегрузкой. Кроме того, ABR может гарантировать минимальный поток ячеек, а также обрабатывать всплески трафика, если это позволяет доступная полоса.

UBR - (Unspecified Bit Rate). Этот класс трафика используется для приложений с импульсивными потоками данных. Сервис UBR не гарантирует какого либо качества обслуживания, доставка осуществляется в режиме "наилучших усилий".

Обычно для приложений MPLS используются классы ATM CBR или VBR. Выбор определяется расценками сервис-провайдеров, которые могут варьироваться в широких пределах. Протокол MPLS поддерживает следующие услуги в сфере QoS:

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


IP TOS напрямую соответствует полю класса обслуживания в MPLS.

Исключение перегрузки. Эта услуга реализуется за счет алгоритма WRED (Weighted Random Early Detection), работающего на уровне интерфейса и осуществляющего управление буфером.

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

Кондиционирование трафика. Использование управления трафиком или политики может определить свойства входящего сетевого трафика. Такое кондиционирование может при заданной скорости сгладить поток. Примером такого кондиционирования может служить FRTS (Frame Relay Traffic Shaping - формирование трафика в Frame Relay), а примером использования политики может быть САR (Commited Access Rate - разрешенная скорость доступа).

Управление (Signaling). Протокол резервирования ресурсов RSVP является основным механизмом реализации управления доступом для сетевых потоков. RSVP может запросит ресурсы, необходимые для осуществления обмена некоторым конкретным приложением в заданной сети.

По проблематике QoS смотри также:

RFC-1633	"Integrated Services in the Internet Architecture: An Overview" Braden R., Clark D., Shenker S., June 1994.
RFC-2474	"Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", K. Nichols, December 1998.
RFC-2475	"An Architecture for Differetiated Services", Blake S., Black D., Carlson M. Davies E., Wang Z., Weiss W., December 1998.
RFC-2386	"A Framework for QoS-based Routing in the Internet", E. Crawley, August 1998
RFC-2597	"Assured Forwarding PHB Group", J. Heinanen, June 1999
RFC-2598	"An Expedited Forwarding PHB", V. Jacobson, June 1999
RFC-3387	"Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network", M. Eder, H. Chaskar, S. Nag. September 2002
http://staff.washington.edu/gray/papers/eqos22.html	"Enterprise QoS Survival Guide 1999 Edition" Gray T., 1999.
http://www.ietf.org/internet-drafts/draft-iab-qos-00.txt	"Next Steps for IP QoS Atchitecture" Huston G.,
	"Administering CISCO QoS in IP-Networks", Michael E. Flannagen, Syngress, 2001

Keepalive (Hello)

Механизм keepalive используется L2TP, для того чтобы разделять простои туннеля от длительных периодов отсутствия управления или информационной активности в туннеле. Это выполняется путем введения управляющих сообщений Hello (смотри раздел 6.5) после специфицированного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. Как для любого другого управляющего сообщения, при недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путем введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля.

Коды результата и ошибки

Результирующий код (CDN, StopCCN)

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

		0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Код результата	Код ошибки (опц.)
Сообщение об ошибке (опц.)

Рис. 7. Формат поля значения атрибута AVP

Результирующий код представляет собой целое число без знака длиной в 2 октета. Опционный код ошибки представляет собой 2-октетное целое число без знака. Опционное сообщение об ошибке поясняет код ошибки. Присутствие кода ошибки и сообщения определяется полем длины AVP. Сообщение об ошибке содержит произвольную строку текста, пригодного для чтения, характеризующего ситуацию. Читабельный текст во всех сообщений об ошибке должен быть представлен в кодировке UTF-8, для языка по умолчанию [RFC2277].

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина равна 8, если в сообщении нет кода ошибки и нет сообщения об ошибке, 10, если имеется код ошибки, но нет сообщения об ошибке, или 10 + длина сообщения об ошибке, если имеется код и сообщение об ошибке. Определенные значения кодов результата для сообщения StopCCN перечислены ниже:

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

1 - Общий запрос ликвидации управляющего соединения

2 - Общая ошибка - код ошибки указывает на разновидность возникшей проблемы

3 - Управляющий канал уже существует

4 - Источник запроса не авторизован для формирования управляющего канала

5 - Версия протокола источника запроса не поддерживается. Код ошибки указывает на более высокую поддерживаемую версию

6 - Источник запроса прекратил работу (shutdown)

7 - Ошибка машины конечных состояний

Определены следующие значения кодов результата для сообщений CDN:

0 - Зарезервировано
1 - Вызов прерван из-за потери несущей.
2 - Вызов прерван по причине, указанной в коде ошибки
3 - Вызов прерван по административным причинам
4 - Вызов не прошел из-за отсутствия необходимых условий (временная причина)


5 - Вызов не прошел из-за отсутствия необходимых условий (постоянная причина)
6 - Неверное место назначения
7 - Вызов не прошел из-за невозможности детектировать несущую
8 - Вызов не прошел из-за регистрации сигнала “занято”
9 - Вызов не прошел из-за отсутствия постоянного гудка (разрешение набора номера)
10 - Вызов не состоялся в пределах временного интервала, выделенного LAC
11 - Вызов реализовал соединение, но не обнаружено соответствующих кадров

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

0 - Отсутствие ошибки.

1 - Пока нет контрольного соединения для данной пары LAC-LNS.

2 - Длина не корректна.

3 - Одно из значений полей находится вне допустимых пределов или зарезервированное поле имеет ненулевое значение.

4 - Недостаточно ресурсов для осуществления операции

5 - ID-сессии не верно в данном контексте

6 - Произошла ошибка в LAC, специфическая для оборудования производителя.

7 - Испробовать другое место назначение. Если LAC знает о других возможных местах назначения LNS, следует попробовать одно из них. Это может быть использовано для управления LAC, базирующемся на LNS-политике, например, в случае существования многоканальных PPP.

8 - Сессия или туннель были аннулированы (shutdown) из-за получения неизвестной AVP с битом M=1 (смотри раздел 4.2). Сообщение об ошибке должно содержать атрибут некорректного AVP в читаемой текстовой форме.

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

Команда APPEND

Аргументы: имя почтового ящика,
опционно - флаг списка со скобками,
опционно - строка даты и времени,
литерал сообщения

Отклики: команда не требует какого-либо специального отклика

Результат:	OK	команда успешно исполнена
	NO	команда не прошла: добавление в почтовый ящик не удалось, ошибка во флагах или дате/времени, или в тексте сообщения
	BAD	команда неизвестна или неверен аргумент

Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.

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

Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.

Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).

Пример: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id:
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed

Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP].

Команда AUTHENTICATE

Аргументы: имя механизма аутентификации.
Отклики: может быть запрошена дополнительная информация.

Результат	OK	Аутентификация завершена, осуществлен переход в состояние "аутентификация выполнена";
	NO	Ошибка аутентификации: неподдерживаемый механизм аутентификации, параметры аутентификации отвергнуты;
	BAD	Неизвестная команда или неверный аргумент, механизм аутентификации прерван.

Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.

Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.

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

Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.

Пример: S: * OK KerberosV4 IMAP4rev1 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful

Команда CAPABILITY

Аргументы: отсутствуют.
Отклики: Необходим немаркированный отклик: CAPABILITY.
Результат: OK – успешное завершение команды;
BAD – команда неизвестна или неверный аргумент<./p>

Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP".

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

Пример: C: abcd CAPABILITY
S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
S: abcd OK CAPABILITY completed

Команда CHECK

Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика;
Результат: OK - проверка завершена;
BAD - команда неизвестна или неверен аргумент.

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

Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.

Пример: C: FXXZ CHECK
S: FXXZ OK CHECK Completed

Команда CLOSE

Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK - команда выполнена, система в состоянии "аутентификация выполнена";
NO - команда не прошла, никакого ящика не выбрано;
BAD - команда неизвестна или неверен аргумент.

Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние "аутентификация выполнена". Никакого немаркированного отклика EXPUNGE не посылается.

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

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

Пример: C: A341 CLOSE
S: A341 OK CLOSE completed

Команда COPY

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

Результат:	OK	команда успешно завершена;
	NO	команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик;
	BAD	команда неизвестна или неверен аргумент.

Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии.

Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.

Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY.

Пример: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed

Команда CREATE

Аргументы: имя почтового ящика.
Отклики: на эту команду не посылается каких-либо откликов.

Результат	OK	команда выполнена;
	NO	команда не выполнена: почтовый ящик с таким именем не может быть создан;
	BAD	команда неизвестна или неверен аргумент.

Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.

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

Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания "foo/bar/zap" на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.

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

Пример: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed

Замечание: интерпретация этого примера зависит от того, является ли символ "/" иерархическим сепаратором. Если "/" иерархический сепаратор, создается новый иерархический уровень с "owatagusiam" с новым членом иерархии этого уровня "blurdybloop". В противном случае создаются два почтовых ящика на одном и том же уровне иерархии.

Команда DELETE

Аргументы: имя почтового ящика.
Отклики: команда не требует каких-либо откликов.
Результат: OK - команда завершена;
NO - ошибка при выполнении команды: не удается стереть ящик с этим именем;
BAD - команда неизвестна или неверен аргумент.

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

Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик "foo" имеет иерархическую структуру "foo.bar" (предполагается, что "." является иерархическим сепаратором), удаление "foo" не должно удалять "foo.bar". Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect.

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

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

Примеры: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed

Команда EXAMINE

Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

Результат:	OK	Осмотр закончен, система в состоянии "выбор сделан" ;
	NO	Осмотр не прошел, система в состоянии "аутентификация выполнена"; нет такого почтового ящика; доступ к почтовому ящику невозможен;
	BAD	Команда неизвестна или неверен аргумент.

Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как "только для чтения". Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика "[READ-ONLY]".

Пример: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed

Команда EXPUNGE

Аргументы: отсутствуют.
Отклики: немаркированные отклики: EXPUNGE.
Результат: OK - команда успешно завершена;
NO - команда не прошла: стирание не выполнено (например, запрещено);
BAD - команда неизвестна или неверен аргумент.

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

Пример: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed

Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.

5.4.4. Команда SEARCH

Аргументы: опционны, [CHARSET]-спецификация.
Критерии поиска (один или более).
Отклики: необходим немаркированный отклик: SEARCH.
Результат: OK - поиск завершен;
NO - ошибка: поиск для данного набора символов или критериев не возможен;
BAD - команда неизвестна или неверен аргумент

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

Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT).

Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII.
US- ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).

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

<набор сообщений>	Сообщения с номерами, соответствующими специфицированному набору номеров
ALL	Все сообщения в почтовом ящике. Ключ отбора по умолчанию для применения команд AND
ANSWERED	Сообщения с установленным флагом \Answered.
BCC <строка>	Сообщения, которые содержат специфицированную строку в поле BCC структуры заголовка сообщения.
BEFORE <дата>	Сообщения, чьи внутренние даты раньше указанной.
BODY <строка>	Сообщения, которые содержат специфицированную строку в теле сообщения.
CC <строка>	Сообщения, которые содержат специфицированную строку в CC поле заголовка.
DELETED	Сообщения с установленным флагом \Deleted.
DRAFT	Сообщения с установленным флагом \Draft.
FLAGGED	Сообщения c установленным флагом \Flagged.
FROM <строка>	Сообщения, которые содержат специфицированную строку в поле FROM заголовка.
HEADER <имя поля> <строка>	Сообщения, которые содержат заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицированную строку в теле данного поля.
KEYWORD <флаг>	Сообщения со специфицированным ключевыми словами.
LARGER	Сообщения с размером [RFC-822] больше чем специфицированное число октетов.
NEW	Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функционально эквивалентно "(RECENT UNSEEN)".
NOT <ключ поиска>	Сообщения, которые не содержат специфицированного ключевого слова.
OLD	Сообщения, которые не имеют флага \Recent. "NOT RECENT" (противоположно "NOT NEW").
ON <дата>	Сообщения, чья внутренняя дата соответствует специфицированному значению даты.
OR <ключ поиска 1> <ключ поиска 2>	Сообщения, которые соответствуют любому из ключевых слов поиска.
RECENT	Сообщения, которые имеют установленный флаг \Recent.
SEEN	Сообщения, которые имеют установленный флаг \Seen.
SENTBEFORE <дата>	Сообщения, чье содержимое заголовка, соответствует дате ранее специфицированного значения [RFC-822].
SENTON <дата>	Сообщения, чье содержимое заголовка, соответствует специфицированной дате [RFC-822]
SENTSINCE <дата>	Сообщения, чье содержимое заголовка, соответствует [RFC-822]: специфицированному значению даты или позже.
SINCE <дата>	Сообщения, чья внутренняя дата соответствует или позже специфицированного значения.
SMALLER	Сообщения с размером [RFC-822] меньше чем специфицированное число октетов.
SUBJECT <строка>	Сообщения, которое содержит специфицированную строку в поле SUBJECT заголовка.
TEXT <строка>	Сообщения, которые содержат специфицированную строку в заголовке или теле сообщения
TO <строка>	Сообщения, которые содержат специфицированную строку в поле заголовка TO.
UID <набор сообщений>	Сообщения с уникальными идентификаторами, соответствующими заданному значению идентификатора.
UNANSWERED	Сообщения, которые не имеют флага \Answered.
UNDELETED	Сообщения, которые не имеют флага \Deleted.
UNDRAFT	Сообщения, которые не имеют флага \Draft.
UNFLAGGED	Сообщения, которые не имеют флага \Flagged.
UNKEYWORD <флаг>	Сообщения, которые не содержат заданных ключевых слов.
UNSEEN	Сообщения, которые не имеют флага \Seen.

Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed

Команда FETCH

Аргументы: набор сообщений,
имена информационных сообщений.
Отклики: немаркированные отклики: FETCH
Результат: OK - операция успешно завершена;
NO - команда не прошла: не удалось доставить эти данные;
BAD - команда неизвестна или неверен аргумент.

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

ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY Нерасширяемая форма BODYSTRUCTURE.
BODY[]<>

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

HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок.

Каждое сообщение имеет номер, по крайней мере, одной части.

Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 1.

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

Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка.
Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях, вставляется разграничивающая пустая строка между заголовком и телом сообщения.

Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:

HEADER ([RFC-822] заголовок сообщения)
TEXT MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-822] заголовок сообщения)
3.TEXT ([RFC-822] текстовое тело сообщения)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-822] заголовок сообщения)
4.2.TEXT ([RFC-822] текстовое тело сообщения)
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT

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

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

Замечание: это означает, что запрос BODY[]<0.2048> сообщения длиной 1500 октетов пришлет BODY[]<0> с литералом размера 1500, а не BODY[].

BODY.PEEK[] <>	Альтернативная форма BODY[], которая не устанавливает флаг \Seen.
BODYSTRUCTURE	Структура тела сообщения [MIME-IMB]. Она вычисляется сервером путем разбора полей заголовка [MIME-IMB] [RFC-822] и заголовков [MIME-IMB].
ENVELOPE	Структура заголовка сообщения. Она вычисляется сервером в результате разбора заголовка [RFC-822] на части, присваивая им значения по умолчания, если это необходимо.
FAST	Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE)
FLAGS	Флаги, присвоенные сообщению.
FULL	Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
INTERNALDATE	Внутренняя дата сообщения.
RFC822	Функционально эквивалентно BODY[], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822).
RFC822.HEADER	Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных FETCH (возвращает данные в формате RFC822.HEADER).
RFC822.SIZE	Размер сообщения [RFC-822].
RFC822.TEXT	Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822.TEXT).
UID	Уникальный идентификатор сообщения.

Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed

Команда LIST

Аргументы: имя,
имя почтового ящика может содержать символы подмены (wildcard).
Отклики: немаркированные отклики LIST.

Результат:	OK	команда list выполнена;
	NO	команда не прошла: не возможно выполнение list для данного образца или имени;
	BAD	команда неизвестна или неверен аргумент.

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

Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.

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

Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо.

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

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

Шаблон	Имя почтового ящика	Интерпретация
~smith/Mail/	foo.*	~smith/Mail/foo.*
Archive/	%	archive/%
#news.	comp.mail.*	#news.comp.mail.*
~smith/Mail/	/usr/doc/foo	/usr/doc/foo
archive/	~fred/Mail/*	~fred/Mail/*

Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что "~smith/Mail" не должно преобразоваться во что-то подобное "/u2/users/smith/Mail", иначе для клиента было бы невозможно определить, соответствовала ли интерпретация контексту шаблона.

Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю. Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию "*" так, что начальный символ "/" будет приводить к несоответствию имени шаблону.

Специальное имя INBOX включается в выдачу команды LIST, если INBOX поддерживается данным сервером для данного пользователя и, если строка "INBOX", напечатанная прописными буквами, соответствует интерпретированному шаблону.

Пример: C: A101 LIST "" ""

S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed

Команда LOGIN

Аргументы: имя пользователя, пароль.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK - login завершено, система в состоянии с аутентификацией;
NO - login не прошла: имя пользователя или пароль отвергнуты;
BAD - команда неизвестна или неверный аргумент.

Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.

Пример: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed

Команда LOGOUT

Аргументы: отсутствуют.
Отклики: необходим немаркированный отклик BYE.
Результат: OK – прерывание сессии завершено;
BAD – неизвестная команда или неверный аргумент.

Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.

Пример: C: A023 LOGOUT
S: * BYE IMAP 4.1 Server logging out
S: A023 OK LOGOUT completed
(Сервер и клиент разорвали соединение)

Команда LSUB

Аргументы: имя-шаблон,
имя почтового ящика может содержать символы подмены (wildcards).
Отклики: немаркированный отклик: LSUB

Результат:	OK	команда успешно исполнена;
	NO	команда не прошла: не возможна выдача списка для предлагаемого шаблона или имени;
	BAD	команда неизвестна или неверен аргумент.

Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.

Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.

Пример: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed

Команда NOOP

Аргументы: отсутствуют.
Отклики: никакого специального отклика на эту команду не требуется.
Результат: OK – команда успешно завершена;
BAD – команда неизвестна или неверен аргумент;
Команда NOOP ничего не делает и всегда успешно завершается.

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

Пример: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

Команда RENAME

Аргументы: имя существующего почтового ящика, имя нового почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.

Результат:	OK	переименование успешно осуществилось;
	NO	переименование не прошло: не удалось переименовать ящик с данным именем, не удалось присвоить новое имя;
	BAD	команда неизвестна или неверен аргумент.

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

Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "foo" в "zap" переименует "foo/bar" (предполагая, что "/" является иерархическим разделителем) в "zap/bar".

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

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

Примеры: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed

Команда SELECT

Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

Результат: OK - процедура выбора закончена, система находится в состоянии "выбрано";
NO - выбор неудачен: нет такого ящика, доступ к почтовому ящику невозможен;
BAD - команда неизвестна или неверен аргумент.

Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:

FLAGS - флаги, определенные для почтового ящика.
EXISTS Число сообщений в почтовом ящике.
RECENT Число сообщений с набором флагов \Recent.
OK [UIDVALIDITY ] Уникальный идентификатор корректности.

Сервер должен также послать "невидимый" код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике.

Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.

Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом "[READ-WRITE]".

Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме "только для чтения" и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика "[READ-ONLY]". Доступ "только для чтения" тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние некоторых флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа "только для чтения".

Пример: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed

Команда STATUS

Аргументы: имя почтового ящика, статусная информация имен.
Отклики: немаркированные отклики: STATUS.
Результат: OK - команда успешно выполнена;
NO - команда не прошла: нет статусной информации для данного имени;
BAD - команда неизвестна или неверен аргумент.

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

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

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

MESSAGES	Число сообщений в почтовом ящике
RECENT	Число сообщений с установленным флагом \Recent
UIDNEXT	Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто.
UIDVALIDITY	Уникальный валидатор почтового ящика
UNSEEN	Число сообщений, не имеющих установленного флага \Seen

Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed

Команда STORE

Аргументы: набор сообщений,
имя элемента сообщения,
значение элемента сообщения.
Отклики: немаркированные отклики: FETCH.
Результат: OK - операция успешно завершена;
NO - команда не прошла: данные не могут быть запомнены;
BAD - команда неизвестна или неверен аргумент.

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

Замечание: вне зависимости от того используется или нет суффикс ".SILENT", сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения.

В настоящее время определены следующие элементы данных:

FLAGS <список флагов>	Заменить флаги для сообщения, приведенного в аргументе. Новое значение флагов присылается, как если бы выполнялась команда FETCH для этих флагов.
FLAGS.SILENT <список флагов>	Эквивалентно FLAGS, но без возвращения нового значения.
+FLAGS <список флагов>	Добавить аргумент к флагам сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
+FLAGS.SILENT <список флагов>	Эквивалентно +FLAGS, но без возвращения нового значения.
-FLAGS <список флагов>	Удаляет аргумент из флагов сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
-FLAGS.SILENT <список флагов>	Эквивалентно -FLAGS, но без возвращения нового значения.

Пример: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH FLAGS (\Deleted \Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
S: A003 OK STORE completed

Команда SUBSCRIBE

Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK - процедура подписки завершена;
NO - подписка не прошла: подписка для данного имени невозможна;
BAD - команда неизвестна или неверен аргумент.

Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку "активных" или "подписных" ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.

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

Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, "system-alerts") после того как срок годности его содержимого истек с тем, чтобы создать его вновь при появлении новых сообщений.

Пример: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed

Команда UID

Аргументы: имя команды,
аргументы команды.
Отклики: немаркированные отклики: FETCH, SEARCH.
Результат: OK - команда UID завершена;
NO - команда UID не прошла;
BAD - команда неизвестна или неверен аргумент.

Команда UID имеет две формы. В первой форме она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.

Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению порядкового номера сообщения 1:100 и UID 443:557.

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

Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.

Пример: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed

Команда UNSUBSCRIBE

Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK - ликвидация подписки прошла успешно;
NO - ликвидация подписки не прошла: это невозможно для данного имени;
BAD - команда неизвестна или неверен аргумент.

Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка "активных" или "подписных" почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.

Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed

Команды клиента

Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.

Команды клиента - экспериментальные и расширения Команда X

Аргументы: определяется приложением.
Отклики: определяется приложением.
Результат: OK - команда выполнена;
NO - отказ;
BAD - команда неизвестна или неверен аргумент.

Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X.

Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды.

Пример: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN completed-cay

6. Отклики сервера

Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".

Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.

Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными".

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

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

Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.

Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.

Команды клиента – любое состояние

Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.

Команды клиента в состоянии "аутентификация осуществлена"

В состоянии "аутентификация осуществлена" разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние "выбрано" .

В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.

Команды клиента – в состоянии без аутентификации

В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.

Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.

По завершении аутентификации невозможно вернуться непосредственно в состояние “без аутентификации”. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии “без аутентификации” возможны команды: AUTHENTICATE и LOGIN.

Команды клиента в состоянии "выбор сделан"

В состоянии "выбор сделан", разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.

Конфигурация и управление

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

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

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

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

В еще одном сценарии, удобном для любой сети, где мультикастные услуги недоступны, DNS может быть сконфигурирована с одним CNAME, аналогично time.domain.net, и списком адресных записей для серверов NTP в домене. Используя адрес time.domain.net и получив список, клиент выбирает сервер и начинает с ним работу в уникастном режиме.

Ликвидация туннеля

Разрыв туннеля происходит в случае посылки партнером сообщения Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать определенное время отклика на это сообщение, прежде чем ликвидировать управляющую информацию, имеющую отношение к туннелю. Получатель этого уведомления должен послать подтверждение получения этого сообщения и затем ликвидировать управляющую информацию.

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

Локальное восстановление

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

При этом используются следующие правила спецификации: Когда маршрутизация обнаруживает изменение набора выходных интерфейсов для места назначения G, RSVP должен обновить состояние прохода, подождать короткий период W и затем послать сообщение обновление Path всем сессиям G/* (т.е., любой сессии с местом назначения G, вне зависимости от порта назначения). Короткая выдержка перед рассылкой сообщения обновления Path нужна, чтобы позволить завершиться переходным процессам в маршрутном протоколе. В настоящее время предлагается W = 2 сек; однако, эта величина должна быть задана при конфигурировании каждого интерфейса.Когда приходит сообщение Path с адресом предыдущего узла, который отличается от записанного в состоянии прохода, RSVP должен немедленно послать сообщение обновления Resv этому PHOP.

Локальные уникаст-адреса IPv

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.4.1.1.10:

Рис. 4.4.1.1.10. Локальный адрес канала

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

Рис. 4.4.1.1.11. Локальный адрес сети

Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или “красть” префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика.

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

LTP через UDP/IP

L2TP использует зарегистрированный UDP-порт 1701 [RFC1700]. Весь L2TP-пакет, включая поле данных и L2TP-заголовок, пересылается внутри UDP-дейтограммы. Создатель L2TP-туннеля выбирает доступный UDP-порт (который может быть или не быть 1701), и посылает пакет по нужному адресу места назначения с номером порта 1701. Получатель выбирает свободный номер порта в своей системе (который может быть или не быть 1701), и посылает отклик инициатору по его номеру порта и адресу. Раз номера портов отправителя и получателя определены, они должны оставаться неизменными в течение всей жизни туннеля.

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

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

Порт 1701 используется как пакетами L2F [RFC2341], так и L2TP. Поле версия в каждом из заголовков может использоваться, чтобы отличить пакеты этих двух типов (L2F использует значение 1, а версия L2TP, описанная в этом документе, использует 2). Реализация L2TP, работающая в системе, которая не поддерживает L2F, должна отбрасывать все L2F-пакеты.

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

Молчаливое отбрасывание пакетов может оказаться проблематичным для некоторых протоколов. Если в PPP разрешена надежная доставка [RFC1663], никакой выше расположенный протокол не может столкнуться с потерей пакетов. Если в L2TP разрешена нумерация пакетов, L2TP может контролировать потерю пакетов. В случае LNS, PPP и L2TP стеки присутствуют в LNS, и потеря пакета может регистрироваться, как если бы пакет получен с неверной CRC. Когда клиенты LAC и PPP физически различны, возможна аналоговая сигнализация, реализуемая путем посылки PPP-клиенту пакета с неверной контрольной суммой. Заметим, что это сильно усложнит отладку канальных программ клиента, так как статистика клиента не сможет отличить истинные ошибки транспортной среды от ошибок, инициированных LAC. Эта техника нереализуема на аппаратном уровне.

Если используется VJ-сжатие, и не разрешена ни надежная доставка в PPP, ни нумерация пакетов, каждый потерянный пакет будет приводить к вероятности 2-16 того, что сегмент TCP будет переадресован с неверным содержимым [RFC1144]. Там где вероятность потери велика, не следует использовать сжатие заголовков TCP-сегментов.

LTP и IPsec

При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне за счет ESP и/или AH. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы Ipsec, как обычные информационные UDP/IP-пакеты.

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

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

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

В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.

Максимальный размер поля данных для протоколов высокого уровня

При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

Манипуляции, зависящие от вида услуг

Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Для того чтобы манипулировать этими объектами процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг. Сравнение спецификаций потоков

Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
result_code

Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te. Сравнение LUB Flowspecs

LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB Вычисление GLB Flowspecs

GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_GLB Сравнение Tspecs

Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны. Сумма Tspecs

Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

Этот вызов используется для вычисления Path_Te.

40. Приложение A. Определения объектов

C-типы определены для двух семейств адресов Интернет IPv4 и IPv6. Для работы с другими адресными семействами можно легко определить новый C-тип. Все неиспользуемые поля должны заполняться нулями и игнорироваться при получении .

Класс сессии
Класс сессии = 1. Объект IPv4/UDP SESSION: Класс = 1, C-тип = 1

Объект IPv6/UDP SESSION: Класс = 1, C-тип = 2

DestAddress

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

Протокол Id

Идентификатор IP-протокола для потока данных. Это поле не должно быть равно нулю.

Флаги

0x01 = E_Police flag

Флаг E_Police используется в сообщениях Path для определения эффективного “края” сети, с целью организации управления трафиком.
Если ЭВМ отправитель сама не способна осуществлять управление трафиком, она установит этот бит в сообщениях Path, которые посылает. Первый узел, где RSVP имеется возможность управления трафиком (если это требуется), установит этот флаг равным нулю.

UDP/TCP порт места назначения сессии. Допустимо значение нуль, означающее отсутствие порта.

Класс RSVP_HOP

RSVP_HOP класс = 3.

Объект IPv4 RSVP_HOP: Класс = 3, C-Тип = 1



Объект IPv6 RSVP_HOP: Класс = 3, C-Тип = 2

Этот объект несет в себе IP-адрес интерфейса, через который последний RSVP-узел переслал это сообщение. Дескриптор логического интерфейса LIH (Logical Interface Handle) используется, для того чтобы различать логические выходные интерфейсы. Узел, получая LIH в сообщении Path, запоминает его величину и возвращает его в объектах HOP последующих сообщений Resv, посланных узлу, который сформировал LIH. LIH должен быть тождественно равен нулю, если не существует дескриптора логического интерфейса.

Класс INTEGRITY

INTEGRITY класс = 4.

Класс TIME_VALUES

TIME_VALUES класс = 5. Объект TIME_VALUES: Класс = 5, C-Тип = 1

Период обновления

Период таймаута обновления R, использованного для генерации этого сообщения (в миллисекундах).

Класс ERROR_SPEC

ERROR_SPEC класс = 6. Объект IPv4 ERROR_SPEC: Класс = 6, C-тип = 1

Объект IPv6 ERROR_SPEC: Класс = 6, C-тип = 2



Поле адрес узла, где произошла ошибка является IP-адресом (IPv4 или Ipv6).

Флаги

0x01 = InPlace

Это значение поля флаги используется только для объектов ERROR_SPEC в сообщении ResvErr. Если флаг = 1, это указывает, что в узле, где произошла ошибка, установлено резервирование.

0x02 = NotGuilty

Это значение поля флаги используется только для объекта ERROR_SPEC в сообщении ResvErr. Это значение устанавливается для интерфейса в прикладной программе получателя. Если флаг имеет такой код, спецификация FLOWSPEC, которая вызвала ошибку, больше запрошенной получателем.

Код ошибки.Одно-октетное поле кода описания ошибки.

Значение ошибки

Двухоктетное поле, содержащее дополнительную информацию об ошибке.


Его содержимое зависит от типа ошибки. Значения поля код ошибки и значение ошибки приведены в приложении B (см. ниже).

Класс SCOPE = 7.



Этот объект содержит список IP-адресов, использованных для сообщений маршрутизации с произвольным выбором отправителей (wildcard) без петель. Адреса должны быть перечислены в возрастающем порядке. Объект IPv4 SCOPE: Класс = 7, C-тип = 1

Объект Ipv6 SCOPE: Класс = 7, C-тип = 2

Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.

Класс STYLE = 8.



Объект STYLE: Класс = 8, C-тип = 1

Поле Флаги: 8 бит. (Пока не определены)

Вектор опций: 24 бита

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

19 бит: Зарезервировано
2 бита: контроль совместного использования
00b: Зарезервировано
01b: Явное резервирование
10b: Распределенное резервирование
11b: Зарезервировано

3 бита: Управление выбором отправителя
000b: Зарезервировано
001b: Произвольный выбор (Wildcard)
010b: Прямой выбор (Explicit)
011b - 111b: Зарезервировано

Младшие биты вектора опций определяются стилем:
WF 10001b
FF 01010b
SE 10010b

Класс FLOWSPEC

Класс FLOWSPEC = 9. Зарезервировано (устарело) объект flowspec: Класс = 9, C-Тип = 1Объект Inv-serv Flowspec: Класс = 9, C-тип = 2

Содержимое и правила кодирования этого объекта описаны в документах, подготовленных рабочей группой int-serv [RFC 2210].

Класс FILTER_SPEC = 10.



Объект IPv4 FILTER_SPEC: Класс = 10, C-тип = 1

Объект IPv6 FILTER_SPEC: Класс = 10, C-тип = 2

Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт. Объект IPv6 Flow-label FILTER_SPEC: Класс = 10, C-тип = 3



SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ отправителя.


Его значение не должно быть равно нулю.

SrcPort. UDP/TCP номер порта отправителя, или нуль, указывающий на отсутствие порта.

Метка потока. 24-битовое поле метки потока, определенной в IPv6. Этот код может использоваться классификатором пакетов для эффективной идентификации кадров, принадлежащих определенному потоку данных (отправитель-> место назначения).

Класс SENDER_TEMPLATE = 11. Объект IPv4 SENDER_TEMPLATE: Класс = 11, C-тип = 1

Определение то же, что и для объекта IPv4/UDP FILTER_SPEC. Объект IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 2

Определение то же, что и для объекта IPv6/UDP FILTER_SPEC. Объект метки потока IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 3

Класс SENDER_TSPEC = 12. Объект Intserv SENDER_TSPEC: Класс = 12, C-тип = 2

Содержимое и правила кодирования для этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

Класс ADSPEC = 13. Объект Intserv ADSPEC: Класс = 13, C-тип = 2

Содержимое и формат этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

Класс POLICY_DATA = 14. Объект POLICY_DATA: Класс = 14, C-тип = 1

Содержимое этого объекта будет определено в будущем.

Класс Resv_CONFIRM = 15. Объект IPv4 RESV_CONFIRM: Класс = 15, C-тип = 1

Объект характеризует 4-байтовый IP-адрес получателя (Ipv4).

Объект IPv6 RESV_CONFIRM: Класс = 15, C-тип = 2

Объект характеризует 15-байтовый IP-адрес получателя (Ipv6).

Маршрутная политика

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики:

оповещение (announce) и
восприятие (accept).

Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (AS) может работать только один внутренний протокол маршрутизации (IGP), а обмен маршрутной информацией между автономными системами происходит в соответствии с внешним протоколом маршрутизации (EGP). Эта идея продемонстрирована на рис. 4.4.11.4.1. ЭВМ (или узлы) A1,B1,C1,D1 и маршрутизатор G-1 составляют одну автономную систему, а A2,B2,C2,D2,E2 и маршрутизатор G-2 - вторую.

Рис. 4.4.11.4.1. Схема связи автономных систем

Пусть имеются две автономные системы ASX и ASY, обменивающиеся маршрутной информацией. ASX знает, как можно достичь сети Net1, которая может и не принадлежать ASX. Аналогично ASY знает, как послать пакет для сети Net2.

net1 .... ASX <----> ASY ...... Net2

Для того чтобы пакеты попали из Net1 в Net2 через ASX и ASY, автономная система ASX должна анонсировать сеть Net1 автономной системе ASY, используя один из внешних протоколов маршрутизации (EGP или BGP), а ASY должна воспринять эту информацию и использовать.
Предметом маршрутной политики в этом случае является решение ASX послать маршрутную информацию ASY, а также решение ASY эту информацию принять и использовать. Не существует никаких правил, которые бы вынуждали ASX и ASY к принятию таких решений. Таким образом, протокол маршрутизации определяет формат маршрутной информации, способ ее пересылки и хранения, но решения о ее посылке той или иной AS, а также решение об использовании маршрутной информации, поступающей извне остаются в руках администратора AS.

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

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

Рис. 4.4.11.4.2

Под каналом в данном случае подразумевается любая среда коммуникации - Ethernet, FDDI и т.д.. Может так случиться, что AS2 предпочитает использовать канал 2 только для обмена с AS4. А канал 1 используется для связи с AS3 и в качестве резервного маршрута (back-up) к AS4 в случае выхода из строя канала 2. Для описания маршрутной политики используются атрибуты interas-in и interas-out. Эти атрибуты позволяют описать локальные решения AS, основанные на ее предпочтениях, так как это делается в протоколах BGP-4 или IGRP. Пример такого описания представлен ниже:

aut-num: AS2 - (номер автономной системы, формат:
AS<целое положительное число в интервале 1-65535>)

as-in: from AS3 10 accept AS3 AS4

(описание воспринимаемой маршрутной информации от других AS-партнеров. Формат описания:

from <aut-num> <cost> accept >выражение маршрутной политики <.
здесь . <aut-num> - относится к AS-соседям; <cost> - положительное целое число, характеризующее относительную ценность маршрутов, чем меньше cost, тем предпочтительнее маршрут; ключевые слова from (от) и accept (воспринимает) могут отсутствовать.)



Маршрутная политика (<выражение маршрутной политики>) может иметь следующие форматы.

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

Список ключевых слов. В настоящее время определено ключевое слово ANY, которое говорит о том, что речь может идти о любых соседних AS.

Логическое выражение, включающее в себя объекты типа 1 или 2, объединенные операторами AND, OR, NOT, которые в данном случае, строго говоря, не являются Булевыми. Так например, AS1 OR AS2 означает все маршруты AS1 или AS2. Или AS1 AND HepNet означает маршрут AS1, принадлежащий объединению HepNet. NOT AS3 означает любой маршрут кроме маршрутов AS3.

Приоритеты операторов распределены в следующем порядке: для оператора () слева направо; для NOT - справа на лево; для AND и OR - слева направо.

В отсутствии логических операторов элементы списка (AS, AS-макро, объединения и списки маршрутов) предполагаются объединенными оператором OR.

as-out: to AS3 announce AS1 AS2

(описание сформированной маршрутной информации, рассылаемой другим AS-партнерам). Формат описания:

to . <aut-num> announce . <выражение маршрутной политики>
ключевые слова to {указатель адресата} и announce
{указатель списка доступных AS} могут и отсутствовать.)
относится к AS-соседям.

interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5) accept AS3
interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref=15) accept AS4
interas-in: from AS3 193.0.1.5/32 193.0.1.6/32 (pref=10) accept AS4
...

interas-in: описывает локальные предпочтения для соединений с другими AS. Это описание имеет формат:

from accept <выражение маршрутной политики>

Ключевые слова from (от) и accept (воспринимает) могут отсутствовать. <aut-num> - автономная система, описанная в as-in. <местный-rid> - (идентификатор местного маршрутизатора) содержит IP-адрес пограничного маршрутизатора, политика которого описывается. <соседний-rid> содержит IP-адрес соседнего маршрутизатора, от которого воспринимается маршрутная информация, описанная в <выражении маршрутной политики> .


IP-адреса имеют префиксный формат ( описание префиксного формата см. выше в конце раздела 1.4.11.4 [бесклассовая интердоменная маршрутизация - CIDR]).

Предпочтение описывается, как <pref-type> = <значение>; ключевое слово <pref-type> должно обязательно присутствовать. В настоящее время стандарт поддерживает только один вид <pref-type> - "pref". <значение> может принимать один из следующих видов:

<стоимость> - положительное число, служащее выражением относительной ценности исследуемых маршрутов. Чем меньше <стоимость> - тем предпочтительнее маршрут. <стоимость> имеет смысл при сравнении атрибутов interas-in и совершенно не применима для сравнения с атрибутами as-in.

Любой маршрут, описанный в interas-in и неупомянутый в AS-IN, предполагается отвергнутым. Система диагностики выдаст при этом сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как as-out и as-in.

Если мы рассмотрим соответствующие атрибуты interas-out для AS3, то увидим следующее:

aut-num: AS3
as-in: from AS2 10 accept AS1 A2
as-out: to AS2 announce AS3 AS4
interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3
interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=15) announce AS4
interas-out: to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=10) announce AS4
...

Оператор interas-out: имеет формат:

to aut-num < местный-rid> < соседний-rid> [<метрика> ]
announce <выражение маршрутной политики>

Ключевые слова IN и announce могут и отсутствовать. Остальные фрагменты оператора идентичны описанным выше.

< метрика> является необязательным параметром и описывается как:

( < metric-type> =< величина> ), следует заметить, что в данном случае наличие скобок "()" и ключевого слова <metric-type> (тип метрики) обязательно. В настоящее время поддерживается только один тип метрики "metric-out". Параметр <величина> может иметь следующий вид:

< num-metric> - метрика для оценки выходных маршрутов, чем ниже ее значение, тем предпочтительнее маршрут.


Именно эта оценка маршрута передается соседним маршрутизаторам. IGP - этот тип метрики указывает на то, что она отражает оценку внутренних маршрутов AS. Следует избегать использования <num-metric> и IGP для одних и тех же точек назначения.

Атрибут as-exclude отмечает список транзитных AS, маршруты через которые должны быть исключены из рассмотрения. Формат использования:

exclude <aut-num> to <exclude-route-keyword> , ключевые слова exclude и to не являются обязательными. <aut-num> - описывает транзитные AS. В качестве <exclude-route-keyword> можно использовать одно из:

<aut-num> , AS макро, ANY (любой) или community.

Атрибут default указывает на маршрут по умолчанию. Формат атрибута:

<aut-num> <relative cost> <default-expression> ,

где <aut-num> указывает на AS-партнера, путь к которому и предлагается в качестве маршрута по умолчанию. Атрибут <relative cost> - положительное целое число, характеризующее уровень приоритета предлагаемого маршрута. AS-macro является удобным средством группировать автономные системы. AS-макро могут использоваться в <выражениях маршрутной политики> для атрибутов as-in и as-out. В качестве примера можно привести:

aut-num: AS786
as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
as-out: to AS1755 announce AS786
.......

Здесь присутствует as-macro с именем AS-EBONE, описание которого может выглядеть как:

as-macro: AS-EBONE (имя AS-макро)
descr: ASes routed by EBONE (AS, маршрутизируемые в EBONE)
as-list: AS2121 AS1104 AS2600 AS2122 (список AS)
as-list: AS1103 AS1755 AS2043
guardian: guardian@ebone.net (администратор EBONE)
......

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

aut-num: AS786
as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
as-in: from AS1755 100 accept AS1103 OR AS1755 OR AS2043)AND NOT AS1104
......

Community - это группа маршрутов, которые не могут быть представлены одной AS или группой AS. Это может быть полезно при описании доступа к супер-ЭВМ, это может быть группа маршрутов, используемых для специальных целей, возможно объединение в группу для получения сетевой статистики.Такие группы не обмениваются маршрутной информацией. Группа Community может использоваться в качестве объекта маршрутной политики автономных систем. Примерами объектов типа community могут служить HEPNET (объединение сетей для физики высоких энергий), NSFNET (Национальная Научная сеть США), опорная московская оптоволоконная сеть.

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

Маршрутный заголовок

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

Следующий заголовок	8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
hdr ext len	8-битовое целое без знака. Длина заголовка маршрутизации выражается в 8-октетных блоках, и не включает в себя первые 8 октетов.
Тип маршрутизации	8-битовый идентификатор конкретного варианта маршрутизации
Оставшиеся сегменты	8-битовое число без знака. Число остающихся сегментов пути, т.e. число промежуточных узлов, которые должны быть посещены пакетом по пути к месту назначения.
Данные, зависящие от типа	Поле переменной длины, формат зависит от кода поля тип маршрутизации, а длина определяется заголовком маршрутизации и кратна 8 октетам.

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

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

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

Рис. 4.4.1.1.20. Формат заголовка маршрутизации типа 0

Следующий заголовок	8-битовый селектор. Идентифицирует тип заголовка, следующего непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
hdr ext len	8-битовое целое без знака. Длина заголовка маршрутизации в 8-октетных блоках, исключая первые 8 октетов. Для заголовков маршрутизации типа 0 hdr ext len равна удвоенному числу адресов в заголовке, должно быть четным числом меньше или равным 46.
Тип маршрутизации	0.
Оставшиеся сегменты	8-битовое целое без знака. Число оставшихся сегментов пути, т.e., число узлов, которые следует посетить на пути к месту назначения. Максимально допустимое число = 23
Резерв	8-битовое поле резерва. Инициализируется нулем при передаче и игнорируется при приеме.
strict/loose bit map	24-битовый код-маска, биты пронумерованы, начиная с 0 до 23, слева направо. Для каждого из сегментов пути указывает должен ли следующий узел быть соседом: 1 означает strict (должен быть соседом), 0 означает пропустить (не должен быть соседом).
Адрес[1..n]	Вектор 128-битовых адресов, пронумерованных с 1 до n.

<
/p> Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0.

Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения.

Биты с номерами более n, где n - число адресов в заголовке маршрутизации, должны быть обнуляться отправителем и игнорироваться получателем.

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

Если оставшееся число сегментов = 0
{ продолжить обработку следующего заголовка пакета, чей тип задан полем следующий заголовок заголовка маршрутизации }

else если HDR ext len является нечетным или больше 46,
{посылается сообщение ICMP (parameter problem, код 0) с указателем на поле HDR #EXT LEN, пакет выбрасывается}

else
{ вычислить n, число адресов в заголовке маршрутизации, для этого код HRD EXT LEN делится на 2

Если число оставшихся сегментов пути больше n,
{послать сообщение ICMP (parameter problem, код 0) с указанием на поле числа оставшихся сегментов пути }

else

{ уменьшить число оставшихся сегментов пути на 1;

Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n

Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми

{ выбросить пакет }

else { поменять местами адрес места назначения IPv6 и адрес[i]

если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа

{ послать сообщение ICMP destination unreachable -- not a neighbor
и выбросить пакет }



else если код IPv6 hop limit меньше или равен 1
{послать сообщение icmp time exceeded -- hop limit exceeded in transit message и выбросить пакет }

else { уменьшить hop limit на 1
повторно направить пакет модулю IPv6 для отправки новому адресату }
}
}
}

В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения:

При движении пакетов от S к I1:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = I1	Число оставшихся сегментов пути = 3
	Адрес[1] = I2
Если бит 0 bit map равен 1, s и i1 должны быть соседями; это проверяется узлом S	Адрес[2] = I3 Адрес[3] = d

При движении пакетов от I1 к I2:

Адрес отправителя = s	Hdr Ext Len = 6
Адрес получателя = I2	Число оставшихся сегментов пути = 2
	Адрес[1] = I1
Если бит 1 bit map равен 1, I1 и I2 должны быть соседями; это проверяется узлом I1	Адрес[2] = i3 Адрес[3] = D

При движении пакетов от I2 к I3:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = I3	Число оставшихся сегментов пути = 1 Адрес[1] = I1
Если бит 2 bit map равен 1, I2 и I3 должны быть соседями; это проверяется узлом I2	Адрес[2] = I2
	Адрес[3] = D

При движении пакетов от I3 к D:

Адрес отправителя = S	Hdr Ext Len = 6
Адрес получателя = D	Число оставшихся сегментов пути = 0 Адрес[1] = I1
Если бит 3 bit map равен 1, I3 и D должны быть соседями; это проверяется узлом I3	Адрес[2] = I2 Адрес[3] = i3

Машины состояний управляющего соединения

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

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

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-

Модель адресации

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

IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:

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

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

IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей.

Модель резервирования

Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра – для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS.

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров: "Rspec”, который определяет желательное значение QoS, и "Tspec", который описывает информационный поток.

Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы. Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC-2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов.
Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.

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

A. Резервирование канала

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

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

Б. Переадресация запроса назад

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

Модели реализации протокола TCP и его перспективы

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Как известно протокол TCP (описание протокола смотри, например, в []) ориентирован на соединение, он использует для транспортировки IP-дейтограммы (L3), которые пересылаются посредством протокольных кадров уровня L2. Между двумя партнерами может быть прямое соединение, а может располагаться большое число сетевых приборов уровней L2 и L3 (см. рис. 1). Если потоки входящих и выходящих сегментов для заданного сетевого устройства равны, режим стационарен и состояние его буферов не меняется. Но маршрутизаторы и переключатели обычно являются многоканальными устройствами. По этой причине, если даже партнеры ТСР-соединения рассчитаны на идентичную скорость обмена, возможна ситуация, когда некоторое сетевое устройство, вовлеченное в обмен, окажется перегруженным. Ведь всегда могут возникать и исчезать новые сессии информационного или мультимедийного обмена, использующие частично те же сетевые устройства. Протокол ТСР функционирует нормально при выполнении ряда условий.

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

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

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

Буферы сетевых устройств используют схему первый_вошел-первым_вышел (FIFO).
Предполагается, что размер этих буферов соответствует произведению RTT*B (B - полоса пропускания, RTT - сумма времен транспортировки сегмента от отправителя к получателю и времени движения отклика от получателя к отправителю). Если последнее условие нарушено, пропускная способность неизбежно понизится и будет определяться размером буфера, а не полосой пропускания канала.

Длительность TCP-сессии больше нескольких RTT, чтобы оправдать используемую протокольную избыточность. Короткие ТСР-сессии, широко используемые WEB-технологией снижают эффективность обмена. (Именно это обстоятельство вынудило в версиях HTTPv1.1 и выше не разрывать ТСР-соединение после вызова очередной страницы).

Чтобы минимизировать влияние избыточности, связанной с заголовком (20 байт IP +20 байт ТСР + МАС-заголовок), используемое поле данных должно иметь большой объем. Для узкополосных каналов, где MTU мало, нарушение данного требования делает канал низкоэффективным. По этой причине выявление допустимого MTU в начале сессии должно приветствоваться.

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

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

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

Для прояснения модели работа протокола ТСР рассмотрим простой фрагмент сети, отображенный на рис. 1.

Рис. 1.

На данном рисунке ЭВМ С1-С3 могут осуществлять обмен друг с другом и с ЭВМ С4-С6. Переключатели SW работают на уровне L2 имеют буферы и могут быть причиной потерь также как сами ЭВМ и маршрутизаторы GW1-GW2. Понятно, что объектом перегрузки помимо названных устройств может стать любой сетевой объект сети Интернет.


Если устройства L3 при переполнении своего буфера могут послать отправителю пакета уведомление ICMP(4), то SW в общем случае могут этого и не делать (например, потому что не умеют). Причиной потери может быть и повреждение пакета на безбрежных просторах Интернет. Особые проблемы могут порождать каналы с большим произведением полосы на RTT []. В основных версиях протокола ТСР для подавления перегрузки используется механизм окон, который управляется потерей пакетов. В современных сетях передача данных, которая создает стационарный трафик, сосуществует с мультимедиа трафиком, который по своей природе нестабилен, что создает дополнительные проблемы для управления с применением оконных алгоритмов. Кроме того, мультимедийный трафик транспортируется обычно протоколом UDP, не предполагающим подтверждений доставки. Именно дейтограммы UDP могут вызвать переполнение буфера и об этом станет известно отправителю ТСР позднее после регистрации потери сегмента.

Анализируя различные модели работы протокола ТСР, следует учитывать, что в сети Интернет могут встречаться участки с разными протоколами L2 (Ethernet, ATM, SDH, Frame Relay, PPP и т.д.). Эти технологии имеют разные алгоритмы обработки ситуаций перегрузки (или не иметь их вовсе), а отправитель и получатель, как правило, не имеют данных о том, какие протоколы уровня L2 реализуют виртуальное соединение (L4).

В настоящее время предложено и опробовано несколько разновидностей протокола TCP.

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

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

Мультикастинг и MBONE

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

MBONE - это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются "туннелями". Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году.

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

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

MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с.

Каждый туннель имеет определенный порог для переменной времени жизни пакета (time-to-live - TTL). Согласно договоренности (IETF) широкополосная видео-информация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видео-пакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, существующему в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами. Следует помнить, что маршрутизатор не откликнется ICMP-сообщением "время истекло", когда TTL достигнет нуля, так как вообще дейтограммы с мультикастинг-адресами не вызывают ICMP-откликов. Увеличивая TTL, прикладной процесс может расширять "зону взаимодействия".
Сначала дейтограмма может посылаться с TTL=1, если отклика не получено, c TTL=2 и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает.

Конфигурация системы в режиме мультикастинга производится автоматически. Для того чтобы изменить конфигурацию системы, или добавить еще один туннель используются специальные конфигурационные команды, которые записываются в /etc/mrouted.conf. Существует два типа таких команд:

phyint <local-addr> [disable] [metric <m>] [threshold <t>]

tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>]

Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<local-addr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Последняя команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1.

Специфика мультикастинг-туннелей требует принципиально новых решений задачи маршрутизации, первой попыткой разрешить эту проблему был протокол DVMRP. Следует иметь в виду, что DVMRP может решить лишь часть задачи, хотя бы потому, что это внутренний протокол. Главной особенностью мультикастинг-маршрутизации является то, что нужно проложить маршруты от источника к совокупности адресатов, от которых пришли запросы участия в процессе.Режим мультикастинга поддерживается не всеми маршрутизаторами Интернет. Возможны конфликты при решении задачи маршрутизации, когда транзитный маршрутизатор не имеет "своих" участников группы (а должен выделить заметный ресурс каналов для удовлетворения внешних запросов).

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

Мультикастинг-адрес 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 дейтограммах или встречаться в любых заголовках маршрутизации.

---

---