A Библиография

[ACAP]	Myers, J. "ACAP -- Application Configuration Access Protocol", Work in Progress.
[CHARSET]	Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[DISPOSITION]	Troost, R., and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[IMAP-AUTH]	Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. Carnegie-Mellon University, December 1994.
[IMAP-COMPAT]	Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, University of Washington, November 1996.
[IMAP-DISC]	Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.
[IMAP-HISTORICAL]	Crispin, M. "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, University of Washington, December 1994.
[IMAP-MODEL]	Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, University of Washington, December 1994.
[IMAP-OBSOLETE]	Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, University of Washington, November 1996
[IMAP2]	Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, University of Washington, August 1990.
[LANGUAGE-TAGS]	Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[MD5]	Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[MIME-IMB]	Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-IMT]	Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996.
[MIME-HDRS]	Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC-822]	Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.
[SMTP]	Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
[UTF-7]	Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 1642, July 1994.

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

Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться для посылки IPv6 дейтограмм самому себе. Его нельзя использовать в качестве идентификатора интерфейса.

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

Алгоритм кластеризации

В исходном алгоритме DTS процедура выбора часов прерывается в данной точке с выбором кандидатов из центра области пересечения. Однако это ведет к заметной потере точности и стабильности, так как не учитываются индивидуальные статистические свойства партнеров. Следовательно, в NTP только кандидаты, которые остаются в результате описанного выше отбора, могут участвовать в последующей обработке. Список кандидатов преобразуется к форме [расстояние, индекс], где расстояние вычисляется на основе кода слоя и расстояния синхронизации l партнера. Масштабный коэффициент позволяет реализовать механизм весового учета вкладов от кодов слоя и расстояния. Обычно, код слоя доминирует, если только один или более кандидатов имеют слишком большие расстояния. Список упорядочивается согласно величине расстояния.

for (each peer) begin

/* обращение ко всем партнерам */

if (low ? q ? high) begin

l	/* сформировать запись в списке */

dist l}

add [dist, peer] to candidate list;

endif;

endfor;

sort candidate list by increasing dist;

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

Заметим, что exi представляет собой дисперсию относительно i-го партнера из списка кандидатов, которая может быть вычислена методом дисперсии фильтра, описанным выше. ej - дисперсия j-ого партнера из списка, включающая в себя вклады от ошибок измерения, от накопления дрейфа и из-за дисперсии фильтра. Если максимальное значение exi больше чем минимальное значение ej, а число кандидатов больше чем ntp.minclock, i-ый партнер удаляется из списка и процедура повторяется. Если текущий источник синхронизации является одним из членов списка и нет других кандидатов из более низкого слоя, процедура прерывается, и никакие другие последующие шаги не предпринимаются.
В противном случае в качестве источника синхронизации берется первый кандидат из списка. В ниже приведенном тексте i, j, k, l - индексы партнеров, k - индекс текущего источника синхронизации (нуль, если такой источник отсутствует), l - индекс первого кандидата в списке.

while begin

for (each survivor [distance, index]) begin

/* вычисление дисперсии */

find index i for max e{xi};

find index j for min ej;

endfor

if (e{xi} ? ej or m ? NTP.MINCLOCK) break;

peer.survivor [i]

/* отбрасывание i-го партнера */

if (i = k) sys.peer

delete the ith peer from the candidate list;

m

endwhile

if (peer.survivor [k] = 0 or peer.stratum [k] >> peer.stratum [l]) begin

sys.peer

call poll-update;

endif

end clock-select procedure;

Алгоритм сконструирован так, чтобы отдавать предпочтение партнерам из головной части списка, которые размещены в более низком слое, имеют наименьшее расстояние и могут обеспечить наибольшую точность и стабильность. С помощью правильного выбора весового коэффициента v (называемого ntp.select), можно удалить некоторые записи из финальной части списка.

Алгоритм пересечения

begin clock-selection procedure

Каждый из партнеров просматривается последовательно и добавляется в конец списка, если он прошел ряд тестов. Для каждого из m кандидатов в список заносятся 3 записи в форме [указатель, тип]: [q - l, - 1], [q, 0] и [q + l, 1]. В результате в списке будет 3m записей, которые будут позднее упорядочены.

for (each peer)

/*обращение ко всем партнерам */

if ({peer.reach ? 0 and peer.dispersion < ntp.maxdisperse} and not (peer.stratum > 1 И peer.refid = peer.hostaddr)) begin

andistance (peer);

/* запись в список */

add [q - l, -1] to endpoint list;

add [q, 0] to endpoint list;

add [q + l, 1] to endpoint list;

<B>endif

endfor

if (m = 0) begin

/* уход, если кандидаты отсутствуют */

sys.peer

sys.stratum

exit;

endif

sort endpoint list by increasing endpointtype;

Ниже приведенный алгоритм представляет собой адаптированную версию DTS [DEC89] и сконструирован так, чтобы отбирать только истинных кандидатов. Алгоритм начинается с инициализации значения f и занесения нуля в счетчики i и c. Затем, начиная с конца упорядоченного, для каждой записи [указатель, тип] значение типа вычитается из кода счетчика i, который содержит число пересечений. Если код типа равен нулю, инкрементируется значение c, которое регистрирует число ложных кандидатов. Если для некоторых записей i і ? m - f, конец записи становится нижней границей пересечения; в противном случае, f увеличивается на 1 и процедура повторяется. Без сброса значений f или c, аналогичная процедура используется для нахождения верхней границы, за исключением того, что значение кода тип добавляется к счетчику. Если после того как обе границы определены c Ј f, процедура продолжается для найденных m - f кандидатов, в противном случае, f увеличивается на 1 и вся процедура повторяется.

for (f from 0 to f ? m/2) begin

/* обращение ко всем кандидатам */

for (each [endpoint, type] from lowest) begin

/* нахождение нижней границы */

low

if (i ? m - f) break;

if (type = 0) c

endfor;

i

for (each [endpoint, type] from highest) begin

/* нахождение верхней границы */

i

high

if (i ? m - f) break;

if (type = 0 ) c

endfor;

if (c ? f) break;

/* продолжить, пока не будут найдены все ложные кандидаты */

endfor;

if (low > high) begin

/* завершить, если не найдено ни одного пересечения */

sys.peer

exit;

endif;

Заметим, что работа продолжается далее данной точки, только если имеется более m/2 пересечений. Однако возможно, но не слишком вероятно, что в области пересечения окажется менее m/2 кандидатов.

Алгоритмы фильтрации и селекции

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

Для того чтобы NTP алгоритмы фильтрации и отбора работали эффективно, полезно иметь меру вариации для каждого из партнеров. Принятая мера вариации базируется на разностях первого порядка, которые легко вычислить. Существует две меры, одна называемая дисперсией фильтра es, и другая дисперсия выбора (select dispersion) ez. Обе меры вычисляются как взвешенные суммы смещений из списка, сформированного на основе расстояний синхронизации. Если qi (0Ј i < n) смещение i-ой записи, тогда разность eij i-ой записи по отношению к j-ой записи определяется как |qi - q j|. Дисперсия относительно j-ой записи определяется как

ej =

где w - весовой коэффициент, который служит для учета влияния расстояния синхронизации на дисперсию. В алгоритмах NTP w выбирается меньше 1/2: w = ntp.filter для дисперсии фильтра (filter dispersion) и w = NTP.SELECT для дисперсии выбора (select dispersion).

Дисперсия es и ex определены относительно 0-ой записи e0.

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

Аннулирование (Teardown)

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

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

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

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

Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

Одной из наиболее сложных систем

4.4.13.2 Нотация ASN.1

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

Одной из наиболее сложных систем сегодня являются открытые системы связи OSI (Open System Interconnection). OSI представляет собой достаточно формализованную стандартную архитектуру управления межкомпьютерными коммуникациями. Для описания этой системы была разработана абстрактный синтаксис нотаций ASN.1 (Abstract Syntax Notation; cм. A Layman’s Guide to a Subset of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, Inc. Redwood City, CA, 1991). ASN.1 является формальным языком, который обладает двумя основными чертами.

ASN.1 представляет собой язык описания типов данных и их значений. В общем виде такое описание имеет вид:

data type value name | data type identifier ::= data value или {data type identifier (data value)}

Коме того, ASN.1 является языком программирования. Этот язык служит для описания MIB и может использоваться для модификации существующей или создания новой базы данных MIB для SNMP. Список наиболее распространенных ключевых слов ASN.1 для описания MIB SNMP включает в себя: BEGIN, IDENTIFIER, END, OCTETS, STRING, SEQUENCE, INTEGER, STRING, OBJECT,OF, NULL, DEFINITIONS DESCRIPTION

Объекты MIB создаются макросами ASN.1. Макрос OBJECT-TYPE имеет формат:

data type value name OBJECT-TYPE

SYNTAX data type identifier

UNITS

ACCESS

STATUS

DESCRIPTION

REFERENCE

INDEX

DEFVAL

::= {data value}

SYNTAX - определяет тип данных (простой, структурированный и т.д)

ACCESS - задает уровень доступа к объекту (read only, read & write)

STATUS - определяет статус описания объекта (текущий, устаревший и пр.)

DESCRIPTION - опсывает роль или функцию управляемого объекта и способы его применения

REFERENCE - опционное описание, характеризующее наследование объекта (указывает на родительский объект)

INDEX - работает в случае, когда объект содержит список или таблицу и позволяет указать позицию в списке или таблице

DEFVAL - опционная характеристика, указывающая значение объекта по умолчанию

Используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами.
Неотъемлемой частью ASN. 1 являются базовые правила кодирования BER (Basic Encoding Rules), которые позволяют определить большое разнообразие типов данных. BER описывает то, как представить или закодировать любую величину в рамках стандарта ASN.1. чки вс е величины здесь представляются в виде последовательности 8-битных октетов. Восьмой бит октета всегда считается самым старшим. BER позволяет закодировать величину более чем одним способом. Имеется также поднабор правил кодирования DER (Distinguished Encoding Rules, описаны в документе Х.509), которые определяют однозначные способы кодирования величин ASN.1.

Ниже приведены базовые правила обозначений метасинтаксиса ASN.1.

n	(полужирный курсив) обозначает переменную
[ ]	(квадратные скобки, напечатанные полужирным шрифтом) указывают на то, что терм является опционным.
{ }	(фигурные скобки, напечатанные полужирным шрифтом) группируют родственные термы.
\|	(вертикальная черта, напечатанная полужирным шрифтом) выделяет альтернативные значения.
…	(многоточие, напечатанное полужирным шрифтом) обозначает повторения.
=	(знак равенства, напечатанный полужирным шрифтом) описывает терм как субтерм.

ASN.1 имеет четыре разновидности типов: простые типы, не имеющие компонент, структурные типы, имеющие компоненты, помеченные (tagged) типы, которые получаются из других типов, а также прочие типы, которые включают в себя типы CHOICE и ANY. Типам и значениям могут присваиваться имена с помощью оператора (::=). Эти имена в дальнейшем могут использоваться для определения других типов и величин.

Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые состоят из класса и неотрицательного кода метки. Типы ASN.1 тождественны, если их числовые метки совпадают. Существует четыре класса меток.

universal	для типов, значения которых является неизменным для всех приложений. Эти типы определены в документе Х.208.
application	для типов со значением, специфическим для приложений, таких как служба каталогов Х.500. Типы двух разных приложений могут иметь одну и ту же метку и разные значения.
private	для типов, которые являются специфическими для данного предприятия.
content-specific	для типов со значением, специфическим для данного структурного типа.

<

Ниже приведена таблица 4.4.13.2.1 типов и их меток универсального класса.

Таблица 4.4.13.2.1. Типы и их метки

Тип	Комментарий	Цифровая метка (шестнадцатеричное)
INTEGER	Любое целое число	02
BIT STRING	Произвольная строка бит	03
OCTET STRING	Произвольная последовательность октетов	04
NULL	0	05
OBJECT IDENTIFIER	Последовательность целых компонент, идентифицирующих объект	06
SEQUENCE and SEQUENCE OF		10
SET and SET OF		11
PrintableString	Последовательность печатных символов	13
IA5String	Произвольная строка символов IA5 (ASCII)	16
UTCTime	Универсальное время (по Гринвичу; GMT)	17

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

В SMI (Structure of Management Information) не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL.

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

SEQUENCE	упорядоченный набор из одного или более типов.
SEQUENCE OF	упорядоченный набор из нуля или более представителей данного типа.
SET	неупорядоченный набор из одного или более типов.
SET OF	неупорядоченный набор из нуля или более представителей данного типа.

Структурированные типы могут иметь опционные компоненты, в том числе со значениями по умолчанию.

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

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

Тип CHOICE обозначает объединение одного или более альтернатив. Тип ANY служит для обозначения произвольной величины для произвольного типа.

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

Identifier octets	Определяет класс и числовую метку значения, а также указывает, является ли метод примитивным или конструктивным.
Length octets	Для методов кодирования с известной длиной определяет число октетов содержимого.
Contents octets	Для примитивных методов с заданной длиной дает конкретное выражение значения.
End-of-contents octets	Для конструктивных методов с неопределенной длиной указывает на конец содержимого.

Примитивный метод кодирования с заданной длиной

Этот метод применим для простых типов и типов полученных из простых типов путем неявной пометки. Здесь необходимо, чтобы длина величины была известна заранее. Октеты идентификатора имеют два формата: для числовых меток от 0 до 31, и для числовых меток более 31. В первом случае биты 7 и 8 определяют класс (см. таблицу 4.4.13.2.2), бит 6 равен нулю, указывая на то, что метод кодирования primitive. Остальные биты используются для записи кода числовой метки. Во втором случае используется два или более октетов. В первом октете кодировка аналогична первому варианту за исключением того, что биты 1-5 содержат единицы.

Таблица 4.4.13.2.2. Коды классов

Класс	Бит 8	Бит 7
Универсальный	0	0
Прикладной	0	1
Контекстно-ориентированный	1	0
Частный	1	1

Для октетов длины примитивного метода имеется два формата: короткий (один октет для длин 0-127) и длинный (2-127 октетов). Для короткой формы 8-ой бит октета всегда равен нулю. Для длинной формы восьмой бит первого октета всегда равен 1, биты 1-7 содержат код числа дополнительных октетов длины. Старшая цифра записывается первой.

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

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

Конструктивный метод кодирования с незаданной длиной

Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00.

Нотация типов, помеченных неявно, имеет вид:

[[class] number] IMPLICIT Type

class = UNIVERSAL | APPLICATION | PRIVITE

где Type - тип, class - опционное имя класса и number - цифровая метка (неотрицательное целое число).

Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например:

PrivateKeyInfo ::= SEQUENCE {

version Version,

privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,

privateKey PrivateKey,

attributes [0] IMPLICIT Attributes OPTIONAL }

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

Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование.

Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes.

Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate

(X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат.

[ [class] number] EXPLICIT Type

class = UNIVERSAL | APPLICATION | PRIVATE

где Type - тип, class - опционное имя класса, а number - числовая метка в пределах класса (неотрицательное целое число). Пример:

ContentInfo ::= SEQUENCE {

ContebtType ContentType,

Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0.

Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено).

Certificate ::= …

Version [0] Version DEFAULT v1988,

…

BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид.

Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType.

Тип ANY

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

ANY [DEINED BY identifier]

где identifier - опционный идентификатор. Форма ANY DEINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которой identifier определяет какую-то другую компоненту и эта компонента имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме истинный тип задается величиной этой другой компоненты. Например, тип AlgorithmIdentifier [X.509] имеет компоненту типа ANY:

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameter ANY DEFINED BY algorithm OPTIONAL }

Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm.

Битовые строки

Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат.

BIT STRING

Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING:

SubjectPublicKeyInfo ::= SEQUENCE {

Algorithm AlgorithmIdentifier,

PublicKey BIT STRING }

BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты.

При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING “0111 1101 1001 1111 11” может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).

03 04 06 7D 9F C0	DER-кодирование
03 04 06 7D 9F E0	Дополнение кодом “100000”
03 81 04 06 7D 9F C0	Длинная форма представления октетов длины
23 09 03 03 00 7D 9F 03 02 06 C0	Конструктивное кодирование “01111101 1001 1111” +”11”

Первый октет первых трех представлений содержат код типа (для BIT STRING = 03). Второй октет в первых двух представлениях - код октетов длины (ведь далее следует 4 октета). Третий октет первой и второй строк содержит число добавленных нулей до числа бит, кратного восьми.

Во втором байте третей строки записана 8, что указывает на длинную форму представления октетов длины. Последующая 1 говорит о том, что использован один дополнительный октет длины. Код длины в четвертом примере записан также во втором октете (далее следует 9 октетов). В этом варианте битовая строка разбита на две субстроки, первая из которых имеет длину в два октета. DER-кодирование предполагает всегда примитивный метод представления с дополнением строки нулями до длины, кратной целому числу октетов.

Тип CHOICE

Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат.

CHOICE {

[identifier1] Type1,

…,

[identifiern] Typen }

где identifier1, …, identifiern являются опционными идентификаторами альтернатив, а типы Type1, …, Typen - альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при кодировании. Типы должны иметь определенные метки. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.

ExtendedCertificateOrCertificate ::= CHOICE {

certificate Certificate, -- X.509 certificate

extendedCertificate [0] IMPLICIT ExtendedCertificate }

Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для типа CHOICE сводится к кодированию альтернатив. При этом октеты идентификатора для рассмотренного примера содержат код 30, если выбранная альтернатива certificate, и A0 - в случае ExtendedCertificate.

Строки IA5

Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 - эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.

IA5String

BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов.

При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки “test1@rsa.com”.

12 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D	DER-кодирование
Длинная форма октетов длины
32 13 12 05 74 65 73 74 31 12 01 40 12 07 72 73 61 2E 63 6F 6D	Конструктивное кодирование: “test1” + “@” + “rsa.com”

DER-кодирование является всегда примитивным, октеты содержимого идентичны случаю BER-кодирования.

Целое

Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат:

INTEGER [{identifier1(value1) … identifiern(valuen) }]

где identifier1 … identifiern являются опционными идентификаторами, а value1… valuen опционные целые значения. Например, Version RFC-1114 относится к целому типу со значением:

Version ::= INTEGER { 1988(0) }

Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version:

Certificate

version Version DEFAULT v1988,

…

BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3.

Таблица 4.4.13.2.3. Примеры BER-кодирования

Значение целого	BER-код
0	02 01 00
127	02 02 00 7F
128	02 02 00 80
256	02 02 01 00
-128	02 01 80
-129	02 02 FF 7F

NULL

Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:

NULL

Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты.

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

05 00

05 81 00

DER-кодирование типа NULL является также примитивным и совпадает с первой строкой приведенного выше примера.

Объектные идентификаторы

Тип OBJECT IDENTIFIER служит для обозначения дентификаторов, которые представляют собой последовательность целочисленных компонент, которые идентифицируют такие объекты, как алгоритм или атрибут имени каталога. Значение OBJECT IDENTIFIER может содержать любое число неотрицательных компонент. Этот тип не относится в числу строчных. Значения OBJECT IDENTIFIER присваиваются при регистрации.

Тип OBJECT IDENTIFIER используется для идентификации содержимого ContentInfo, алгоритмов в X.509 (AlgorithmIdentifier) и атрибутов Attribute и AttributeValueAssertion (X.501). Нотация OBJECT IDENTIFIER имеет формат.

OBJECT IDENTIFIER

Нотация величины OBJECT IDENTIFIER имеет вид:

{ [identifier] component1… componentn}

componenti = identifieri | identifieri (valuei) | valuei

где identifier, identifier1, … identifiern являются идентификаторами, а value1 …, valuen - опционные целые числа. Идентификаторы без целых значений могут встретиться только для объектов, описанных в Х.208.

Например, нижеприведенные величины объектных идентификаторов присвоены RSA DATA Security, Inc.

{ iso(1) member-body(2) 840 113549 }

{ 1 2 840 113549 }

В таблице 4.4.13.2.4 представлены некоторые объектные идентификаторы и их значения.

Таблица 4.4.13.2.4. Некоторые объектные идентификаторы и их значения

Величина объектного идентификатора	Назначение
{ 1 2 }	Члены ISO
{ 1 2 840 }	US (ANSI)
{ 1 2 840 113549}	RSA Data Security, Inc.
{ 1 2 840 113549 }	RSA Data Security, Inc. PKCS (Public Key Cryptography Standard)
{ 2 5 }	Служба каталогов (X.500)
{ 2 5 8 }	Служба каталогов - алгоритмы

BER-кодирование OBJECT IDENTIFIER является всегда примитивным. Октеты содержимого представляют собой объединение n-1 строки октетов, где n число компонент объектного идентификатора.

Каждая октетная строка несет в себе целое число по модулю 128 (старшая часть первая). 8-ой бит каждого октета, кроме последнего, равен 1. Пусть value1, …, valuen целые значения компонентов объектного идентификатора. Тогда n-1 субидентификаторов, из которых формируется октетная строка, будут иметь следующий вид.

Первый субидентификатор равен 40value1

+ value2. (значение value1 лежит в пределах 0-2 включительно, а value2 в интервале 0-39, когда value1 равна 0 или 1.

i-ый субидентификатор равен valuei+1 ; 2 Ј iЈ n-1.

Например, субидентификаторы объектного идентификатора RSA Data Security, Inc. равны 42 = 40ґ 1 + 2, 840, 113549 и 1. В шестнадцатеричном представлении BER-код этого объектного идентификатора имеет вид:

06 07 2A 86 48 86 F7 0D 01

DER-кодирование в данном случае совпадает с BER.

Строки октетов

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

OCTET STRING [SIZE ({size | size1..size2})]

где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE(size) строка октетов должна иметь октеты size. В формате OCTET STRING SIZE(size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING:

PBEParameter ::= SEQUENCE {

salt OCTET STRING SIZE (8),

iterationCount INTEGER }

Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING. Например, BER-код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное).

04 08 01 23 45 67 89 AB CD EF	DER-кодирование
04 81 08 01 23 45 67 89 AB CD EF	Длинный формат октетов длины
24 0С	Конструктивное кодирование
04 04 01 23 45 67	“01 23 45 67” + “89 AB CD EF”
04 04 89 AB CD EF

Строки печатных символов Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора: A, B,…,Z a,b,…,z 0,1,…,9 (пробел) ‘ () +, - . / : = ? Этот тип используется для представления атрибутов имен (Х.520). Нотация типа PrintableString имеет вид: PrintableString BER-кодирование значения PrintableString может быть примитивным или конструктивным. При примитивном кодировании печатных символов байты содержимого несут в себе строки октетов печатных ASCII-кодов. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок. Например, BER-код значения PrintableString “Test User 1” может быть представлено одним из ниже приведенных способов.

13 0B 54 65 73 74 20 55 73 65 72 20 31	DER-кодирование
13 81 0B 54 65 73 74 20 55 73 65 72 20 31	Длинная форма октетов длины
33 0F	Конструктивная форма,
13 05 54 65 73 74 20	“Test” + “User 1”
13 06 55 73 65 72 20 31

Тип SEQUENCE Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид: SEQUENCE { [identifier1] Type1 [{OPTIONAL | DEFAULT value1}], …, [identifiern] Typen [{OPTIONAL | DEFAULT valuen}], где identifier1 , …, identifiern являются опционными идентификаторами компонентов, Type1 , …, Typen - типы компонентов, а value1 ,…, valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует. Например, тип Validity [X.509] относится к типу SEQUENCE и имеет два компонента. Validity ::= SEQUENCE { start UTCTime,

end UTCTime }

Здесь start и end являются идентификаторами компонент, а типом компонент служит UTCTime. BER-кодирование значения SEQUENCE является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов последовательности.

Тип SEQUENCE OF

Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более компонентов данного типа, используется для имен в X.501. Нотация SEQUENCE OF имеет вид:

SEQUENCE OF Type

Так например, тип RNDSequence состоит из нуля или более компонент типа RelativeDistinguishedName.

RNDSequence ::= SEQUENCE OF RelativeDistinguishedName

BER-кодирование SEQUENCE OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов значений элементов последовательности в порядке их расположения. DER-кодирование имеет тот же формат.

Тип SET

Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.

SET {

[identifier1] Type1 Type1

[{OPTIONAL | DEFAULT value1}],

…,

[identifiern] Typen [{OPTIONAL | DEFAULT valuen}],

где identifier1 , …, identifiern

являются опционными идентификаторами компонентов, Type1

, …, Typen - типы компонентов, а value1 ,…, valuen

опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует.

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

Тип SET OF

Тип SET OF представляет неупорядоченный набор, состоящий из нуля или более компонентов заданного типа и предназначенный для атрибутов PKCS (Public-Key Cryptography Standard) и имен X.501. Нотация типа SET OF имеет вид:

SET OF Type

где Type - тип. Так тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.

RelativeDistinguishedName ::= SET OF AttributeValueAssertion

BER- кодирование типа SET OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов величин компонентов в порядке их исходного расположения. DER-кодирование также является всегда конструктивным, октеты содержимого представляются как и в случае BER-кодировки. Но компоненты лексикографически упорядочиваются.

Тип UTCTime

Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime характеризует местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:

YYMMDDhhmm-hh`mm`

YYMMDDhhmmssZ

YYMMDDhhmmss+ hh`mm`

YYMMDDhhmmss- hh`mm`

где

YY	младшие две цифры года
ММ	код месяца (01 - 12)
DD	код дня (01 - 31)
hh	код часа (00 - 23)
mm	код минут (00 - 59)
ss	код секунд (00 - 59)
Z	означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а - указывает на то, что местное время опережает GMT.
hh`	абсолютное значение смещения по отношению к GMT в часах
mm`	абсолютное смещение по отношению к GMT в минутах.

UTCTime используется для определения типа Validity [X.509]. Нотация типа UTCTime имеет вид.

UTCTime

BER-кодирование значения UTCTime может быть примитивным или конструктивным. При примитивном кодировании октеты представляют собой символы строки в виде ASCII-кодов. При конструктивном кодировании октеты образуют объединение BER-кодов последовательных субстрок. В качестве примера рассмотрим варианты представления времени 4:45:40 после полудня 6 мая 1991 года (Pacific Daylight Time) в виде величины UTCTime.

“910506164540-0700”

“910506234540Z”

Это представление эквивалентно следующим BER-кодам:

17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5A

17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30

DER-кодирование типа UTCTime всегда является примитивным.

Ниже приводится пример ASN.1 нотации имен типа X.501.

Name ::= CHOICE { RNDSequence }

RNDSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET OF AttributeValueAssertion

AttributeValueAssertion ::= SEQUENCE { AttributeType, AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY

Тип Name идентифицирует объект в каталоге X.500. Name имеет тип CHOICE с одной альтернативой RNDSequence. Тип RNDSequence указывает проход по дереву каталогов X.500, начиная с корневой части. RNDSequence имеет тип SEQUENCE OF, состоящий из нуля или более компонентов RelativeDistinguishedName. Тип RelativeDistinguishedName присваивает уникальное имя объекту на дереве каталога. RelativeDistinguishedName имеет тип SET OF, состоящий из нуля или более компонентов AttributeValueAssertion. Тип AttributeValueAssertion присваивает значение атрибуту имени (например, определяющее принадлежность к стране). AttributeValueAssertion имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и AttributeValue. AttributeType идентифицирует атрибут с помощью объектного идентификатора. AttributeValue присваивает значение атрибуту. Ниже предлагается пример DER-кодирования типа Name. В качестве имени использовано RSA Data Security, Inc. NOTARY (отдел Internet Privacy Enhanced Mail).

(root)

|

countryName = ”US”

|

organizationName = ”RSA Data Security, Inc.”

|

organizationalUnitName = ”NOTARY”

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

Тип атрибута

DER-кодирование трех значений AttributeType согласно примитивному методу с заданной длиной дает следующие строки октетов.

06 03 55 04 06	countryName
06 03 55 04 0A	organizationName
06 03 55 04 0B	organizationalUnitName

Здесь countryName, organizationName и organizationalUnitName являются типами атрибутов Х.520, которые имеют следующие определения.

AttributeType OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }

countryName OBJECT IDENTIFIER ::= { AttributeType 6 }

organizationName OBJECT IDENTIFIER ::= { AttributeType 10 }

organizationalUnitName OBJECT IDENTIFIER ::= { AttributeType 11 }

Октеты идентификатора имеют формат с меткой, так как метка равна 6 для OBJECT IDENTIFIER. Биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, что говорит о примитивном методе кодирования. Октеты длины ориентированы на короткую форму представления. Октеты содержимого представляют собой объединения трех-октетных строк, полученных из субидентификаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11.

Значение атрибута

DER-кодирование трех значений AttributeValue в соответствии с примитивным методом при заданной длине дает следующие строки:

13 02 55 53	“US”
13 17 52 53 41 20	“RSA
44 61 74 61 20	Data
53 65 63 75 72 69 74 79 2C 20	Security,
49 6E 63 2E	Inc.”

Метка равна 19 (PrintableString) биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, отмечая примитивный метод кодирования. Октеты длины имеют “короткий” формат, а октеты содержимого являются ASCII-представлением значения атрибута.

Атрибут ValueAssertion

DER-кодирование трех значений AttributeValueAssertion в соответствии с конструктивным методом дает следующие строки октетов.

30 09 06 03 55 04 06 13 02 55 53	countryName = “US”
30 1E 06 03 55 04 0A 13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 74 79 2C 20 49 6E 63 2E	organizationName = “RSA Data Security, Inc.”
30 0D 06 03 55 04 0B 13 06 4E 4F 54 41 52 59	organizationalUnitName = “NOTARY”

30 09 … 55 53

31 20

30 1E … 63 2E

31 0F

30 0D … 52 59

Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов компонент AttributeValueAssertion.

RDNSequence

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

30 40

31 0B … 55 53

31 20 … 63 2E

31 0F … 52 59

Октеты идентификатора используют короткий формат (low-octet form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов трех компонент RelativeDistinguishedName в порядке их следования.

Name

DER-кодирование значений Name выполняется аналогично значениям RDNSequence и выдает следующие результаты.

30 40 31 0B 30 09 06 03 55 04 06

13 02 55 53

31 20 30 1E 06 03 55 04 0A

13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 74 79 2C 20 49 6E 63 2E

31 0F 30 0D 06 03 55 04 0B

13 06 4E 4F 54 41 52 59

Атрибут флагов сообщения

Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.

Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:

\seen	Сообщение прочитано
\answered	На сообщение послан ответ
\flagged	Сообщение "помечено" как срочное, требующее особого внимания
\deleted	Сообщение помечено как стертое для последующего удаления посредством expunge
\draft	Сообщения не является законченным (помечено, как проект).
\recent	Сообщение только что положено в почтовый ящик. Эта сессия является первой, где фигурирует данное сообщение; для последующих сессий это сообщение не будет иметь флага \recent. Флаг не может быть изменен клиентом.

Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа "\". Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.

Замечание: Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store, и по этой причине не может быть изменен вообще.

Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола , это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.

Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения.

Атрибут сообщения UID

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

В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].

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

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

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

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

Атрибут порядкового номера сообщения

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

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

Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, имеется 286 сообщений, имеющих меньшее значение UID и 236 сообщений с большими UID.

Атрибуты AVP

Как это определено в разделе 4.1, AVP содержат поля ID производителя, атрибута и значения. Для ID производителя значение 0 IANA поддерживает регистр присвоенных атрибутов, а в некоторых случаях и значений. Атрибуты 0-39 присвоены согласно тому, как это описано в разделе 4.4. Остальные значения доступны для присвоения при согласовании с IETF [RFC 2434].

Аутентификация прокси PPP

L2TP определяет AVP, которые могут пересылаться в процессе установления сессии с целью передачи PPP аутентификационной информации, полученной в LAC, для перепроверки в LNS (смотри раздел 4.4.5). Это предполагает полное доверие между LAC и LNS. Если LNS решит использовать прокси аутентификацию, она должна быть конфигурируема, требуя нового цикла PPP-аутентификации по инициативе LNS (который может включать или нет новый раунд согласования параметров с LCP).

Аутентификация туннеля

L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено.

При участии в аутентификации туннеля LAC и LNS должны обладать общим секретным кодом. Это тот же секретный код, который использовался для AVP-сокрытия (смотри раздел 4.3).

AVP, применимые для всех управляющих сообщений

Тип сообщения (все сообщения)

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

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Тип сообщения

Рис. 6

Тип сообщения характеризуется целым 2-октетным числом без знака.

Тип сообщения AVP должен быть первым AVP в сообщении, который следует непосредственно сразу за заголовком управляющего cообщения (определено в разделе 3.1). Список типов управляющих сообщений и их идентификаторов смотри в разделе 3.2.

Обязательный бит (M) в типе сообщения AVP имеет специальное назначение. Этот бит служит скорее не для указания того, следует ли игнорировать саму AVP, если бы она не распознана, а указанием того, что при не распознании следует игнорировать управляющее сообщение. Таким образом, если M-бит равен 1 в типе сообщения AVP, а тип сообщения неизвестен программе, туннель должен быть ликвидирован. Если бит M=0, тогда программа может игнорировать сообщения неизвестных типов. M-бит должен быть сделан равным 1 для всех типов сообщений определенных в данном документе. Эта AVP не может быть скрытой (H-бит должен быть равен нулю 0). Длина этого AVP равна 8.

Случайный вектор (все сообщения)

Случайный вектор AVP, тип атрибута 36, используются для разрешения сокрытия значения атрибута AVP.

Случайная последовательность октетов может иметь произвольную длину, хотя для случайного вектора рекомендуется длина, по крайней мере, 16 октетов. Строка содержит случайный вектор для использования при вычислении хэша MD5 чтобы извлечь или скрыть значение атрибута скрытого AVP (смотри раздел 4.2).

В сообщении может быть более одного случайного вектора AVP. Эта AVP должна предшествовать первому AVP с битом H =1.

M-бит для этого AVP должно быть равно 1. Это AVP не должно быть скрыто (H-бит должен быть равен 0). Длина этого AVP равно 6 плюс длина случайной строки октетов.

AVP прокси LCP и аутентификации

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

LCP CONFREQ, полученный в исходном состоянии (ICCN)

В AVP, полученного в исходном состоянии LCP CONFREQ, тип атрибута 26, предоставляет LNS исходное сообщение CONFREQ, полученное LAC от партнера PPP.

LCP CONFREQ является копией тела полученного исходного CONFREQ, начиная с первой опции тела сообщения LCP. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Последний посланный LCP CONFREQ (ICCN)

В AVP последнего посланного LCP CONFREQ, тип атрибута 27, предоставляет LNS последнего CONFREQ, посланного LAC партнеру PPP.

LCP CONFREQ является копией тела финального CONFREQ, посланного клиенту с целью завершения LCP-согласования, начиная с первой опции тела LCP-сообщения. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Последний полученный LCP CONFREQ (ICCN)

AVP последнего полученного LCP CONFREQ, тип атрибута 28, предоставляет LNS последнего CONFREQ, полученного концентратором LAC от PPP-партнера.

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

Эта AVP может быть скрытой (бит H может быть 0 или 1).
M- бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Тип прокси Authen (ICCN)

AVP типа прокси Authen, тип атрибута 29, определяет, должна ли использоваться прокси аутентификация. Тип Authen представляет собой 2-октетное целое число без знака.

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

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

1 - Текстовой обмен имя пользователя/пароль

2 - PPP CHAP

3 - PPP PAP

4 - Никакой аутентификации

5 - Microsoft CHAP версия 1 (MSCHAPv1)

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

Имя прокси Authen (ICCN)

AVP имени прокси Authen, тип атрибута 30, специфицирует имя аутентифицируемого клиента при использовании прокси аутентификации.

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

Эта AVP должна присутствовать в сообщениях, содержащих AVP типа Proxy Authen с типом Authen 1, 2, 3 или 5. Может быть, желательно применить AVP-сокрытие для защиты имени, представленного открытым текстом. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 6 плюс длина имени.

Приглашение прокси Authen (ICCN)

AVP приглашения прокси Authen, тип атрибута 31, специфицирует приглашение, посланное LAC партнеру PPP при использовании прокси аутентификации. Приглашение представляет собой строку из одного или более октетов.

Эта AVP должна присутствовать для типов прокси Authen 2 и 5. Поле приглашения содержит приглашение CHAP, предлагаемое LAC клиенту.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6, плюс длина приглашения.

ID прокси Authen (ICCN)

AVP ID прокси Authen, тип атрибута 32, специфицирует код ID PPP-аутентификации, которая реализуется между LAC и PPP-партнером, когда используется прокси аутентификация. Поле значения атрибута для этого AVP имеет следующий формат:

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Зарезервировано	ID

Рис. 15. Поле значения атрибута для AVP ID прокси Authen

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

AVP прокси Authen ID должна присутствовать для типов Proxy authen 2, 3 и 5. Для 2 и 5, поле ID содержит значение ID-байта переданное LAC клиенту в его приглашении (Challenge). Для 3 - это значение идентификатора Authenticate-Request. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0.

Отклик прокси Authen Response (ICCN)

AVP отклика прокси Authen, тип атрибута 33, специфицирует отклик аутентификации PPP, полученный LAC от PPP-партнера, когда используется прокси аутентификация. Отклик представляет собой строку октетов произвольной длины.

Эта AVP должна присутствовать для типов прокси authen 1, 2, 3 и 5. Поле отклика содержит отклик клиента на приглашение. Для типов прокси authen 2 и 5, это поле содержит значение отклика, полученное LAC. Для типов 1 или 3, оно несет в себе открытый текст пароля, полученного LAC от клиента. В случае паролей с открытым текстом рекомендуется AVP-сокрытие.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина отклика.

AVP статуса вызова

Ошибки вызова (WEN)

AVP ошибок вызова, тип атрибута 34, используется LAC для посылки LNS информации об ошибке. Поле значения атрибута для этого 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
Зарезервировано	Ошибка CRC (H)
Ошибка CRC (L)	Ошибка в формате кадра (H)
Ошибка в формате кадра (L)	Аппаратное переполнение (H)
Аппаратное переполнение (L)	Переполнение буфера (H)
Переполнение буфера (L)	Ошибка таймаута (H)
Ошибка таймаута (L)	Ошибка выравнивания (H)
Ошибка выравнивания (L)

Рис. 16. Поле значения атрибута для AVP ошибок вызова

Определены следующие поля:

Зарезервировано	Не используется, должно равняться нулю 0
Ошибки CRC	Число PPP-кадров, полученных с CRC-ошибками с момента реализации вызова
Ошибки формата кадров	Число полученных PPP-пакетов с неверным форматом
Аппаратное переполнение	Число переполнений аппаратного буфера с момента реализации вызова
Число переполнений буфера	Число зарегистрированных переполнений буфера с момента реализации вызова
Число ошибок таймаутов	Число таймаутов с момента реализации вызова
Ошибки выравнивания	Число ошибок выравнивания с момента реализации вызова

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 32.

ACCM (SLI)

AVP ACCM, тип атрибута 35, используется LNS, чтобы проинформировать LAC о ACCM, согласуемом LNS с PPP-партнером. Поле значения атрибута для этого 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
Зарезервировано	Послать ACCM (H)
Послать ACCM (L)	Получить ACCM (H)
Получить ACCM (L)

Рис. 17. Поле значения атрибута для AVP ACCM

Посланное ACCM и полученное ACCM имеют по 4 октета, перед которыми размещаются 2 октета зарезервированного количества. Значение посланного ACCM должно использоваться LAC для обработки пакетов, которые он отправляет через канал. Значение полученного ACCM должно использоваться LAC для обработки пакетов, которые он получает через канал. Значения по умолчанию, используемые LAC для обоих этих полей равны 0xFFFFFFFF. LAC должен учитывать значения этих полей, если только нет конфигурационной информации, которая указывает, что запрошенная маска должна быть модифицирована, чтобы разрешить операцию.

Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 16.

AVP управления контрольным соединением

Версия протокола (SCCRP, SCCRQ)

Версия протокола AVP, тип атрибута - 2, указывает на версию протокола L2TP отправителя. Поле значения атрибута для данной AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ver	Rev

Рис. 8. Поле значения атрибута для AVP управления контрольным соединением

Поле Ver характеризуется целым числом без знака длиной в один октет и содержит код 1. Поле Rev характеризуется целым числом без знака длиной в один октет и содержит код 0. Так характеризуется версия протокола L2TP 1, и модификация версии 0. Заметим, что это не тот же код версии, что включается в заголовок каждого сообщения.

Эта AVP не должна быть скрытой (бит H должен быть равен 0). Бит M для данной AVP должен быть равен 1. Длина этой AVP равна 8.

Возможность работы с кадрами (SCCRP, SCCRQ)

Возможность работы с кадрами AVP, тип атрибута - 3, предоставляет партнеру указание на типы кадров, которые будут приняты или запрошены отправителем. Поле значения атрибута для этого 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
Зарезервировано для будущих определений типа кадрового обмена	A	S

Рис. 9. Поле значения атрибута для AVP возможности работы с кадрами

Поле значения атрибута представляет собой 32-битовую маску, с двумя определенными битами. Если бит A=1, поддерживается асинхронный обмен кадрами. Если бит S=1, поддерживается синхронный обмен кадрами.

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

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) равна 10.

Возможности носителя (SCCRP, SCCRQ)

AVP возможностей носителя, тип атрибута - 4, предоставляют партнеру указание на типы носителя, поддерживаемые аппаратным интерфейсом отправителя для исходящих вызовов.
Поле значения атрибута для этого 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
Зарезервировано для будущих определений типа несущей среды	A	D

Рис. 10. Поле значения атрибута для AVP возможности носителя

Это 32-битная маска, с двумя определенными битами. Если бит A =1, поддерживается аналоговый доступ. Если бит D =1, поддерживается цифровой доступ.

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

Заметим, что LNS, который не может работать как LAC, а также не поддерживает оборудование для обработки входящих и исходящих вызовов, должен установить биты A и D этого AVP равными 0, или не должен вообще посылать AVP. LNS, который может работать в качестве LAC, и направлять исходящие вызовы, должен устанавливать биты A или D так, как это нужно. Присутствие этого сообщения не гарантирует того, что данный исходящий вызов будет направлен отправителем, если это потребуется, хотя такая возможность и существует.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) равна 10.

Арбитр конфликта (Tie Breaker (SCCRQ))

AVP арбитра конфликта, тип атрибута - 5, указывает, что отправитель желает иметь один туннель между заданной парой LAC-LNS.

Значение Tie Breaker характеризуется 8-октетным кодом, который используется для выбора одного туннеля, когда LAC и LNS требуют формирования туннеля одновременно. Получатель SCCRQ должен проверить, был ли послано партнеру SCCRQ и, если это так, должен сравнить свое значение Tie Breaker с полученным. Более низкое значение "wins" и "loser" должно вызвать молчаливую ликвидацию туннеля.

В случае, когда код арбитра присутствует на обеих сторонах и значения равны, обе стороны должны ликвидировать туннели. Если получен tie breaker, а невыполненный просроченный SCCRQ не имеет значения tie breaker, инициатор, который включает AVP Tie Breaker "выигрывает". Если ни одна из сторон не посылает Tie Breaker, тогда открываются два туннеля.

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этого AVP должен быть равен 0. Длина этой AVP равна 14.

Фирменная версия (Firmware Revision) (SCCRP, SCCRQ)

Фирменная версия AVP, тип атрибута 6, указывает на фирменную версию прибора, пославшего сообщение.

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

Для приборов, которые не имеют кода фирменной версии (универсальные ЭВМ, где, например, работают программные модули L2TP), вместо этого может быть сообщена модификация программных модулей L2TP.

Эта AVP может быть скрыта (H-бит может быть равен 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 8.

Имя ЭВМ (SCCRP, SCCRQ)

AVP имени ЭВМ, тип атрибута 7, указывает на имя ЭВМ, реализующей функцию LAC или LNS.

Имя ЭВМ имеет переменную длину, но должно иметь, по крайней мере, один октет. Это имя должно быть максимально уникальным; для ЭВМ, участвующих в DNS [RFC1034], следует выбирать полное имя домена.

Эта AVP не должна быть скрыта (H-бит должен быть 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 6 плюс длина имени ЭВМ.

Имя производителя (SCCRP, SCCRQ)

AVP имени производителя, тип атрибута 8, содержит специфическую для производителя строку, которая характеризует тип используемого LAC или LNS.

Имя производителя представляет собой строку октетов произвольной длины. Для обеспечения читаемости текст этой AVP должен быть представлен с помощью символьного набора UTF-8 на языке, выбранном по умолчанию [RFC2277].

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для данной AVP должен быть равен 0.

Длина ( до сокрытия) этой AVP равна 6 плюс длина имени производителя.

ID, присвоенное туннелю (SCCRP, SCCRQ, StopCCN)

AVP ID, присвоенного туннелю, тип атрибута 9, несет в себе ID, присвоенное туннелю отправителем. ID, присвоенное туннелю, содержит в себе 2-октетное целое неравное нулю число без знака.

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

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

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

Размер приемного окна (Receive Window Size (SCCRQ, SCCRP))

Размер приемного окна AVP, тип атрибута 10, специфицирует размер приемного окна, которое предлагает удаленный партнер. Размер окна характеризуется 2-октетным целым числом без знака.

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

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 8.

Приглашение (Challenge (SCCRP, SCCRQ))

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

Эта AVP может быть скрытой (бит H может быть 0 или 1).M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина приглашения (challenge).

Отклик на приглашение (Challenge Response (SCCCN, SCCRP))

AVP отклика, тип атрибута 13, направляет ответ на полученное сообщение.

Поле отклик содержит 16 октетов, соответствуя CHAP-стилю [RFC1994] отклика на вызов.

Эта AVP должна присутствовать в SCCRP или SCCCN, если приглашение было получено в предыдущем SCCRQ или SCCRP. Для целей вычисления значения ID в CHAP-отклике используется код типа сообщения AVP для этого кадра (например, 2 для SCCRP, и 3 для SCCCN).

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 22.

AVP управления вызовом

Q.931 код причины (CDN)

AVP, тип атрибута 12, используется, чтобы предоставить дополнительную информацию в случае непреднамеренного разрыва соединения. Поле значения атрибута для этого 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
Код причины	Сообщение причины	Сообщение-рекомендация

Рис. 11. Поле значения атрибута для AVP кода причины Q.931

В качестве кода причины присылается код Q.931, а в качестве сообщения причины - сообщение Q.931 (например, DISCONNECT), ассоциированное с кодом причины. Оба кода присылаются в их исходных кодировках ITU [DSS1]. Дополнительный ASCI-текст сообщения-рекомендации может быть включен (присутствие определяется с помощью кода длины AVP) для дальнейшего уточнения причины отсоединения.

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 9, плюс размер сообщения Advisory.

ID, присвоенное сессии (CDN, ICRP, ICRQ, OCRP, OCRQ)

AVP ID, присвоенного сессии, тип атрибута 14, содержит ID, присвоенное сессии отправителем сообщения. ID, присвоенное сессии, представляет собой 2-октетное целое, ненулевое число без знака.

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

В управляющем сообщении CDN, используется первое AVP ID-сессии, полученное партнером, позволяя партнеру идентифицировать соответствующий туннель, даже если CDN послано до получения ID, присвоенное сессии.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

Порядковый номер вызова (ICRQ, OCRQ)

AVP порядкового номера вызова, тип атрибута 15, несет в себе идентификатор, присвоенный данному вызову LAC или LNS. Порядковый номер вызова представляет собой 32-битовый код.

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

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Максимальный BPS (OCRQ)

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

Максимальный BPS представляет собой 32-битовый код, характеризующий скорость передачи в битах в секунду.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Максимальный BPS (OCRQ)

AVP максимального BPS, тип атрибута 17, характеризует максимальную приемлемую скорость канала для данного вызова.

Максимальный BPS представляет собой 32-битный код, характеризующий скорость передачи в битах в секунду.

Эта AVP может быть скрытым (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) этого AVP равна 10.

Тип носителя (ICRQ, OCRQ)

AVP типа носителя, тип атрибута 18, характеризует тип носителя для входящего или исходящего вызовов. Поле значения атрибута для этого 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
Зарезервировано для будущих определений типа несущей среды	A	D

Рис. 12. Поле значения атрибута для AVP типа носителя

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

Если бит A=1, то вызов относится к аналоговому каналу. Если бит D=1, то вызов относится к цифровому каналу. Могут быть установлены оба бита, что может означать, что тип канала не определен, или допустима работа, как с аналоговым, так и цифровым каналами.

Биты в поле значение данной AVP должны устанавливаться LNS для OCRQ, если они были установлены в AVP возможностей носителя, полученной от LAC в период установления управляющего соединения.

Можно не устанавливать ни A, ни D-биты в ICRQ. Такая установка может означать, что вызов не был получен по физическому каналу (например, если LAC и PPP находятся в той же подсистеме).

Эта AVP может быть скрыта (H-бит может быть 0 или 1). M-бит этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Тип кадрового обмена (ICCN, OCCN, OCRQ)

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

атрибута для этого 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
Зарезервировано для будущих определений типа кадрового обмена	A	S

Рис. 13. Поле значения атрибута для AVP типа кадрового обмена

Тип кадрового обмена представляет собой 32-битовую маску, которая указывает тип кадрового обмена PPP, запрошенный для OCRQ, или тип кадрового обмена PPP, согласованный для OCCN или ICCN. Тип кадрового обмена может быть использован как указание PPP на LNS, какую из канальных опций использовать для согласования с LCP [RFC1662].

Бит A указывает на асинхронный обмен кадрами. Бит S указывает на синхронный обмен кадрами. Для OCRQ могут быть установлены оба бита, что будет означать допустимость обоих типов кадрового обмена.

Биты в поле значение этой AVP должны устанавливаться только LNS для OCRQ, если они были установлены в AVP возможностей кадрового обмена, полученной от LAC в процессе установления управляющего соединения. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1.

Длина ( до сокрытия) этой AVP равна 10.

Вызванный номер (Called Number (ICRQ, OCRQ))

AVP вызванного номера, тип атрибута 21, характеризует телефонный номер, куда посылается вызов для OCRQ.

Вызванный номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.

Вызывающий номер (Calling Number (ICRQ))

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

Вызывающий номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.

Субадрес (ICRQ, OCRQ)

AVP субадреса, тип атрибута 23, несет в себе дополнительную информацию по вызову.

Субадрес является ASCII-строкой. Может быть, необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина субадреса.

Скорость канала (Tx) (Connect Speed (ICCN, OCCN))

AVP скорости канала (Tx) BPS, тип атрибута 24, характеризует быстродействие устройства, выбранного для попытки установления соединения. Скорость канала (Tx) BPS содержит 4 октета и характеризует скорость обмена в битах в секунду.

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

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Скорость соединения Rx (Connect Speed (ICCN, OCCN))

AVP скорости соединения Rx, тип атрибута 38, представляет скорость канала с точки зрения LAC (например, информация, передаваемая от удаленной системы в LAC). Поле значения атрибута для этого 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
BPS (H)	BPS (L)

Рис. 14. Поле значения атрибута для AVP скорости соединения Rx

BPS имеет 4 октета, характеризующие скорость обмена в битах в секунду. Присутствие этой AVP означает, что быстродействие канала может быть асимметричным с учетом скорости передачи, заданной в AVP скорости соединения Rx.

Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

ID физического канала (ICRQ, OCRP)

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

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

ID частной группы (ICCN)

AVP ID частной группы, тип атрибута 37, используется LAC для индикации того, что этот вызов ассоциируется с определенной группой клиентов. ID частной группы представляет собой строку октетов произвольной длины.

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

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

Эта AVP может быть скрытой (H-бит может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина ID частной группы.

Необходима нумерация (Sequencing Required (ICCN, OCCN))

AVP Sequencing Required, тип атрибута 39, сообщает LNS, что порядковые номера должны всегда присутствовать в информационном канале. Эта AVP не имеет поля значения атрибута.

Эта AVP не должна быть скрытой (H-бит должен быть 0). M-бит этой AVP должен быть равен 1. Длина этой AVP равна 6.

B Потеря пакета и повторная передача

Существующий туннель имеет новую сессию, запрошенную LAC. Пакет ICRP потерян и должен быть послан LNS повторно. Заметим, что потеря ICRP несет в себе две проблемы: это не только блокирует машину состояний высокого уровня, но и лишает LAC своевременного прихода подтверждения его ICRQ на нижнем уровне.

LAC LNS

ICRQ ->

Nr: 1, Ns: 2

(пакет потерян)
	Nr: 3, Ns: 1

(пауза; таймер LAC запускается первым, поэтому первым и срабатывает)

ICRQ ->

Nr: 1, Ns: 2

(Понимая, что он уже видел этот пакет, LNS отбрасывает его и посылает ZLB)

Nr: 3, Ns: 2

(срабатывает таймер повторной передачи LNS)


	Nr: 3, Ns: 1

ICCN ->

Nr: 2, Ns: 3


	Nr: 4, Ns: 2

Безопасность

При использовании протокола RSVP возникают определенные проблемы безопасности.

Целостность сообщений и аутентификация узлов

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

Аутентификация пользователя

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

Безопасные потоки данных

Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя.

Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207].

Безопасность на конце туннеля

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

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

Assigned Tunnel ID и Assigned Session ID (смотри раздел 4.4.3) должны быть выбраны непредсказуемым образом. Такая методика препятствует деятельности хакеров, которые не имеют доступа к пакетам, которыми обмениваются LAC и LNS.

Безопасность от начала до конца

Защищая поток L2TP-пакетов, так как это делает безопасный транспорт, мы защищаем данные, передаваемые по PPP-туннелю от LAC к LNS. Такая защита не должна рассматриваться как замена для безопасности точка-точка при передаче данных между ЭВМ или приложениями.

Безопасность пакетного уровня

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

и CISCO. Главная цель BGP

4.4.11.4 Внешний протокол BGP

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

Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае - это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

1	OPEN	(открыть)
2	UPDATE	(изменить)
3	NOTIFICATION	(внимание)
4	KEEPALIVE	(еще жив)

После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения.
Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):

Рис. 4.4.11.4.2 Формат сообщения open

Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.

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

Длина сообщения = 29 + длина поля идентификационных данных.

Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

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

Рис. 4.4.11.4.3 Формат update-сообщения

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

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

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

Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0). Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля Флагов атрибута определяет, является ли информация в опционном переходном атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут пути характеризуют значение атрибута и интерпретируются согласно флагам атрибута.

Атрибуты пути бывают "стандартные обязательные" (well-known mandatory), "стандартные на усмотрение оператора", "опционные переходные" и "опционные непереходные". Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься, как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз.

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

ORIGIN (код типа = 1) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:

Код атрибута	Описание
0	IGP - информация достижимости сетевого уровня является внутренней по отношению к исходной автономной системе;
1	EGP - информация достижимости сетевого уровня получена с помощью внешнего протокола маршрутизации;
2	Incomplete - информация достижимости сетевого уровня получена каким-то иным способом.

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

Код типа сегмента	Описание
1	AS_set: неупорядоченный набор маршрутов в update сообщении;
2	AS_sequence: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении.

<

br>

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

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

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

LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.

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

aggregator (код типа = 7) - опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета). Объем информации о достижимости сетевого уровня равен (в октетах):

Длина сообщения UPDATE - 23 - полная длина атрибутов пути - длина списка отмененных маршрутов. Информация о достижимости кодируется в следующей форме:

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

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

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

NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается. Помимо заголовка NOTIFICATION-сообщение имеет следующие поля:

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

Таблица 4.4.11.4.1. Коды ошибок

Код ошибки	Описание
1	Ошибка в заголовке сообщения.
2	Ошибка в сообщении open
3	Ошибка в сообщении update
4	Истекло время сохранения
5	Ошибка машины конечных состояний
6	Прерывание

При отсутствии фатальной ошибки BGP-партнер может в любой момент прервать связь, послав NOTIFICATION-сообщение с кодом ошибки прерывание.

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

Таблица 4.4.11.4.2 Субкоды ошибок

Ошибка	Субкод	Описание
Заголовок	1 2 3	Соединение не синхронизовано Неверная длина сообщения Неверный тип сообщения
Сообщения OPEN	1 2 3 4 5 6	Неверный код версии Ошибочный код as-партнера Ошибочный идентификатор BGP Ошибка в коде идентификации Ошибка при идентификации Неприемлемое время сохранения
Сообщения UPDATE	1 2 3 4 5 6 7 8 9 10 11	Ошибка в списке атрибутов Не узнан стандартный атрибут Отсутствует стандартный атрибут Ошибка в флагах атрибута Ошибка в длине атрибута Неправильный атрибут origin Циклический маршрут Ошибка в атрибуте next_hop Ошибка в опционном атрибуте Ошибка в сетевом поле Ошибка в as_path

Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:

1.	ADJ-RIBS-IN:	Запоминает маршрутную информацию, которая получена из update-сообщений. Это список маршрутов, из которого можно выбирать. (policy information base - PIB).
2.	LOC-RIB:	Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN.
3.	ADJ-RIBS-OUT:	Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений.

<

br>

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

Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел ""). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов.

BGP использует три таймера:

Connectretry (сбрасывается при инициализации и коррекции; 120 сек),

Holdtime (запускается при получении команд Update или Keepalive; 90сек) и

keepalive (запускается при посылке сообщения Keepalive; 30сек).

BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.

BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована.

При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается.

Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:

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

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

Рассылка информации из loc_rib всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.

Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) - способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети.

Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 - ). Для приведенных примеров это в терминах масок выглядит следующим образом:

24 и 17 длины префикса сети.

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

Протокол	Метрика	Диапазон	Код "маршрут недостижим"
RIP hello BGP	Число скачков Задержка в ms Не определена	0-15 0-29999 0-65534	16 30000 65535

Колонка "маршрут недостижим" содержит коды метрики, которые говорят о недоступности маршрута. Обычно предполагается, что если послан пакет из точки <А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не совпадают, представлен на рис. 4.4.11.4.4. В предложенной схеме имеется две ЭВМ "Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и "GW-1".

Рис. 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно".

Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:

1 GW-1	(192.148.166.35)
2 Место назначения	(192.148.166.33)

Команда же traceroute 192.148.165.80 распечатает:

1 GW-1	(192.148.166.35)
2 GW-2	(192.148.166.7)
3 Место назначения	(192.148.165.80)

Команда traceroute -g 192.148.165.80 сообщит вам:

1 GW-1	(192.148.166.35)
2 *****	; В этом режиме маршрутизатор не откликается
3 Место назначения	(192.148.165.80)
4 GW-1	(192.148.166.35)
5 ЭВМ-отправитель	(192.148.166.32)

<

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

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

-a отображает состояния всех соединений;

-i отображает значения конфигурационных параметров;

-r отображает таблицу маршрутов;

-v отображает статистику обмена локального Ethernet-интерфейса.

Например, команда netstat -r может выдать:

Routing tables (таблицы маршрутизации)

Destination	Gateway	Flags	Refcnt	Use	Interface
Stavropol-GW.ITEP.RU	nb	UGHD	0	109	le0
ihep.su	itepgw	UGHD	0	103	le0
m10.ihep.su	itepgw	UGHD	0	16	le0
194.85.66.50	itepgw	UGHD	0	455	le0
Kharkov.ITEP-Kharkov	nb	UGHD	0	105	le0
Bryansk-GW.ITEP.Ru	nb	UGHD	1	8113	le0
193.124.225.67	nb	UGHD	0	0	le0
ixwin.ihep.su	itepgw	UGHD	1	6450	le0
ihep.su	itepgw	UGHD	0	14	le0
192.148.166.21	nb	UGHD	0	109	le0
ihep.su	itepgw	UGHD	0	224	le0
193.124.225.71	nb	UGHD	0	10	le0
194.85.112.0	ITEP-FDDI-BBone.ITEP	UGD	0	253	le0
default	itepgw	UG	10	102497	le0

Здесь приведен только фрагмент маршрутной таблицы. Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway - имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес.

Базовая команда netstat может обеспечить следующую информацию:

Active Internet connections (активные Интернет связи)

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
tcp	0	0	127.0.0.1.1313	127.0.0.1.sunrpc	TIME_WAIT
tcp	0	0	ns.1312	193.124.18.65.smtp	SYN_SENT
tcp	0	0	127.0.0.1.1311	127.0.0.1.sunrpc	TIME_WAIT
tcp	0	0	ns.1310	ns.domain	TIME_WAIT
tcp	0	0	127.0.0.1.1309	127.0.0.1.sunrpc	TIME_WAIT
tcp	39	24576	ns.nntp	Bryansk-GW.ITEP.1697	ESTABLISHED
tcp	0	0	ns.telnet	semenov.1802	ESTABLISHED
tcp	0	188	ns.1033	xmart.desy.de.6000	ESTABLISHED
udp	0	0	127.0.0.1.domain	.
udp	0	0	ns.domain	.

Active UNIX domain sockets (активные UNIX-соединители домена)

Address	Type	Recv-Q	Send-Q	Vnode	Conn	Refs	Nextref Addr
ff64b38c	stream	0	0	ff13187c	0	0	0 /dev/printer
ff64b28c	dgram	0	0	0	0	0	0
ff64698c	dgram	0	0	<>ff137fa8	0	0	0 /dev/log

Библиография

[Baker96]	Baker, F., "RSVP Cryptographic Authentication", Work in Progress.
[RFC 1633]	Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994.
[FJ94]	Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994.
[RFC 2207]	Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC-2208]	“Resource Reservation Protocol (RSVP) - Version 1. Applicability Statement”.
[RFC-2209]	“Resource Reservation Protocol (RSVP) - Version 1.Message Processing Rules”
[RFC 2113]	Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997.
[RFC 2210]	Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997.
[RFC-2211]	“Specification of the Controlled-Load Network Element Service”
[RFC-2212]	“Specification of Guarantied Quality of Service”
[PolArch96]	Herzog, S., "Policy Control for RSVP: Architectural Overview". Work in Progress.
[OPWA95]	Shenker, S. and L. Breslau, "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.

[1]	I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996.
[2]	S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [24]
[3]	J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987
[4]	International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993
[5]	The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991
[6]	Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987
[7]	Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987
[8]	Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989
[9]	Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994
[10]	Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994
[11]	Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982
[12]	W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968

[1]	D. D. Clark и D. L. Tennenhouse, "Architectural considerations for a new generation of protocols," in SIGCOMM Symposium on Communications Architectures и Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20(4), Sept. 1990.
[2]	D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.
[3]	Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
[4]	Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL, March 1992.
[5]	Reynolds, J., и J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[6]	Eastlake, D., Crocker, S., и J. Schiller, "Randomness Recommendations for Security", RFC 1750, DEC, Cybercash, MIT, December 1994.
[7]	J.-C. Bolot, T. Turletti, и I. Wakeman, "Scalable feedback control for multicast video distribution in the internet," in SIGCOMM Symposium on Communications Architectures и Protocols, (London, England), pp. 58--67, ACM, Aug. 1994.
[8]	Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, и Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.
[9]	V. L. Voydock и S. T. Kent, "Security mechanisms in high-level network protocols," ACM Computing Surveys, vol. 15, pp. 135--171, June 1983.
[10]	Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science и RSA Data Security, Inc., April 1992.
[11]	S. Stubblebine, "Security services for multimedia conferencing," in 16th National Computer Security Conference , (Baltimore, Maryland), pp. 391--395, Sept. 1993.
[12]	S. Floyd и V. Jacobson, "The synchronization of periodic routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 122-136, April 1994.

Битовые и двоичные строки

8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB]. Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. "Двоичная строка" - это любая строка из NUL символов. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую как BASE64, прежде чем их пересылать. Строка с большим числом символов CTL может рассматриваться как двоичная.

Биты заголовка AVP

Имеется 4 резервных бита в заголовке AVP. Дополнительные биты должны присваиваться через стандартную процедуру [RFC 2434].

Будущая совместимость

В будущем для существующих классов могут быть описаны новые объекты C-Типа, а могут быть определены и новые классы объектов. Крайне желательно использовать такие объекты Интернет в рамках старых приложений, которые их не распознают. К сожалению, это возможно с заметными ограничениями. Здесь нужно придерживаться следующих правил (`b' означает бит).

1. Неизвестный класс

Существует три возможных способа, чтобы приложение RSVP могло работать с объектом неизвестного класса. Этот выбор определяется двумя старшими битами октета Class-Num.

Class-Num = 0bbbbbbb. Все сообщение должно быть отброшено и возвращена ошибка "Unknown Object Class" (неизвестный класс объекта).

Class-Num = 10bbbbbb. Узел должен игнорировать объект без дальнейшей пересылки или отправки сообщений об ошибке.

Class-Num = 11bbbbbb. Узел должен игнорировать объект, но может переадресовать его далее без модификации со всеми сообщениями, вызванными данным запросом.

Ниже приведены более детализированные правила для работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb:

Такие объекты неизвестного класса, включенные в сообщения PathTear, ResvTear, PathErr или ResvErr, должны немедленно переадресовываться в рамках того же сообщения.

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

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

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

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

2. Неизвестный C-Тип для известного класса

Появление объекта с неизвестным C-типом приведет к выбрасыванию всего сообщения и генерации сообщения об ошибке (ResvErr или PathErr). Сообщение об ошибке будет включать Class-Num и C-тип, который был не распознан. Оконечная система, которая отправила нераспознанное сообщение может использовать эту информацию, чтобы попытаться повторить попытку с объектом другого C-типа.

Объекты определенных классов (FLOWSPEC, ADSPEC и POLICY_DATA) не прозрачны для RSVP, который просто передает их системе управления трафиком или другим модулям управления. В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-Тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке.

Call-Disconnect-Notify (CDN)

Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции.Следующие AVP должны присутствовать в CDN:

Message Type

Код результата (Result Code)

Assigned Session ID

Следующие AVP могут присутствовать в CDN:

Код причины Q.931

Dns_

4.4.12 DNS (структура, обработка запросов, ресурсные записи)

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

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.4.12.1		53	235

Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети не последнюю роль играет сервер имен (DNS-система, RFC-4032, -4034, -4035, -2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706, -1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35). Сервер имен это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и ЭВМ вместе с их IP-адресами. Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkrley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS - преобразование символьного имени в IP-адрес и наоборот в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNS-серверами показана ниже на рисунке 4.4.12.1.

Рис. 4.4.12.1. Структура взаимодействия с серверами имен

База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Как уже отмечалось имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (двухсимвольные национальные коды смотри в приложении), или характер организации образовательная, коммерческая, правительственная и т.д.).

Следующие 3-х символьные коды в конце Internet-адреса означают функциональную принадлежность узла:

Таблица 4.4.12.1. Стандартизованные суффиксы имен

Поле адреса	Тип сети
.aero	Фирма или организация, относящаяся к сфере авиации;
.biz	Организация, относящаяся к сфере бизнеса;
.com	Коммерческая организация;
.coop	Кооперативная организация;
.gov	Государственное учреждение (США);
.info	Открытая TLD-структура (регистрация имен доменов)
.org	Бесприбыльная организация;
.edu	Учебное заведение;
.mil	Военное предприятие или организация (США);
.museum	Имя домена музея
.name	Имя домена частного лица
.net	Большая сеть;
.pro	Профессионал, достойный доверия. Управляется RegistryPro ();
.int	Международная организация;
.arpa	Специальный домен, используемый для преобразования ip-адреса в имя

<
Секции .mil и . gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru - имя mvax-кластера в ИТЭФ, vxitep.itep.ru - имя vax-кластера, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

Маленький фрагмент интернетовской иерархии имен показан на рис. 4.4.12.2. Число уровней реально больше, но обычно не превышает 5.

Рис. 4.4.12.2. Иерархия имен в Интернет-DNS (I - домен первого уровня; II - второго уровня)

Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен сходная с com/edu/org. Так в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk - для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна - существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен.

Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах.

Список корневых серверов вы можете получить с помощью анонимного FTP по адресам: или . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй - адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее - в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом.

Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 4.4.12.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).

Рис. 4.4.12.3. Формат DNS-сообщений

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

Рис. 4.4.12.4. Назначение битов поля флаги.

Таблица 4.4.12.2. Коды поля флаги

Код поля флаги	Описание
0 (QR)	Операция:	0 Запрос 1 Отклик
1…4	Тип запроса (opcode):	0 стандартный 1 инверсный 2 запрос состояния сервера
5 (AA)	Равен 1 при отклике от сервера (RR), в ведении которого находится домен, упомянутый в запросе.
6 (TC)	Равен 1 при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 октетов, но прислано только первые 512.
7 (RD)	Равен 1, если для получения ответа желательна рекурсия.
8 (RA)	Равен 1, если рекурсия для запрашиваемого сервера доступна.
9…11	Зарезервировано на будущее. Должны равняться нулю.
12…15	Тип отклика (rcode):	0 нет ошибки 1 ошибка в формате запроса 2 сбой в сервере 3 имени не существует

<

Ниже описан формат секции запросов в DNS-сообщении.

Рис. . 4.4.12.5. Формат секции вопросов DNS-запроса.

Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой октеты длины):

В реальной нотации байты длины субполя могут иметь два старших бита равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти ухищрения придуманы для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса:

Таблица 4.4.12.3.. Разновидности полей тип запроса и их коды

Тип запроса	Код запроса	Описание
A	1	IP-адрес
NS	2	Сервер имен.
CNAME	5	Каноническое имя.
SOA	6	Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.
MB	7	Имя домена почтового ящика.
WKS	11	well-known service - стандартная услуга.
PTR	12	Запись указателя.
HINFO	13	Информация об ЭВМ.
MINFO	14	Информация о почтовом ящике или списке почтовых адресов.
MX	15	Запись о почтовом сервере.
TXT	16	Не интерпретируемая строка ASCII символов.
AXFR	252	Запрос зонного обмена
* или ANY	255	Запрос всех записей.

(Пропущенные коды являются устаревшими или экспериментальными).

Последние две строки в таблице 4.4.12.3 относятся только к запросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] - 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса).

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

Рис. 4.4.12.6. Формат ресурсных записей в DNS (RR)

Всего существует 20 различных типов RR-записей. Имя домена в такой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 - это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.

Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет собой октет IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив несколько запросов в домен IN-ADDR.ARPA относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат:

IP_address	Hard-addr	Delay	Date	Host_name
128.141.202.101	00.00.0c.02.69.7d	440	10/10/95	na48-1.cern.ch
192.148.166.102	00.00.a7.14.41.c2	5	10/10/95
192.148.166.237	00.00.0c.02.69.7d	5	10/10/95	ITEP-M9.Relcom.ITEP.RU

<

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

Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNS-сервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 4.4.12.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала).

host -t cname cernvm.cern.ch

cernvm.cern.ch is a nickname for crnvma.cern.ch

Напомним, что CNAME - каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias).

host -t hinfo ns.itep.ru

ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3

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

host -t mx cl.itep.ru

cl.itep.ru is a nickname for r02vax.itep.ru

r02vax.itep.ru mail is handled by relay1.kiae.su

r02vax.itep.ru mail is handled by relay2.kiae.su

r02vax.itep.ru mail is handled by mx.itep.ru

r02vax.itep.ru mail is handled by x4u2.desy.de

host -v info.cern.ch

Trying domain "itep.ru"

rcode = 3 (Non-existent domain), ancount=0

Trying null domain

rcode = 0 (Success), ancount=2

info.cern.ch	86400	IN	CNAME	www6.cern.ch
www6.cern.ch	86400	IN	A	128.141.202.119

<

Trying domain "itep.ru"

rcode = 3 (Non-existent domain), ancount=0

Trying null domain

rcode = 0 (Success), ancount=1

The following answer is not authoritative:

www6.cern.ch

86400

128.141.202.119

For authoritative answers, see:

CERN.CH	52256	IN	NS	dxmon.cern.ch
CERN.CH	52256	IN	NS	ns.eu.net
CERN.CH	52256	IN	NS	sunic.sunet.se
CERN.CH	52256	IN	NS	scsnms.switch.ch

Additional information:

dxmon.cern.ch 79157 IN A 192.65.185.10

ns.eu.net 56281 IN A 192.16.202.11

sunic.sunet.se 85087 IN A 192.36.125.2

sunic.sunet.se 85087 IN A 192.36.148.18

scsnms.switch.ch 72545 IN A 130.59.1.30

scsnms.switch.ch 72545 IN A 130.59.10.30

Опция -v, используемая совместно с командой host позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 4.4.12.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MX-записями производится в следующих случаях:

Локальная сеть или ЭВМ не имеет непосредственной связи с Интернет, но желает участвовать в почтовом обмене (например, через UUCP-протокол).

Адресат не доступен и предпринимается попытка доставить почтовое сообщение альтернативной ЭВМ.

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

MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MX-записей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете напечатать команду (WKS - Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWS-сервера и пр.):

host -tv wks ns.itep.ru

ns.itep.ru WKS 193.124.224.35 udp domain tftp

ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger

Если вам нужно узнать IP- адреса того или иного узла можно также воспользоваться командой host:

host vxdesy.desy.de

vxdesy.desy.de has address 131.169.35.78

vxdesy.desy.de has address 131.169.35.79

vxdesy.desy.de has address 131.169.35.76

vxdesy.desy.de has address 131.169.35.77

Большая часть данных относится к типу "А".

Выше уже говорилось, что для транспортировки DNS-запросов применяются протоколы UDP и TCP. Когда же следует использовать эти протоколы? Обычно используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами.

Обычно реализация сервера имен (версия BIND - Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:

named.boot - файл начальной загрузки сервера имен;

named.local - стартовый файл клиента DNS;

named.ca - исходный буфер имен и адресов.

Это текстовые файлы, строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла-буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary.

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

Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

номер версии файла (увеличивается каждый раз при внесении любых изменений, этот параметр отслеживается вторичным сервером);

время обновления данных (период запросов, посылаемых вторичным сервером первичному) в секундах;

длительность периода повторных попыток (retry) вторичного сервера в случае неудачи;

продолжительность пригодности данных (expiration time) в секундах, по истечении этого времени вторичный сервер считает всю базу данных устаревшей.

значение TTL по умолчанию.

Запись может выглядеть как (RFC-1033):

@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (

45 ;serial

3600 ;refresh

600 ;retry

3600000 ;expire

86400 ) ;minimum

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

Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла можно считать следующее (взято из RFC-1033):

;list of possible root servers

. 1 IN NS SRI-NIC.ARPA.

NS C.ISI.EDU.

NS BRL-AOS.ARPA.

NS C.ISI.EDU.

;and their addresses

SRI-NIC.ARPA. A 10.0.0.51

A 26.0.0.73

C.ISI.EDU. A 10.0.0.52

BRL-AOS.ARPA. A 192.5.25.82

A 192.5.22.82

A 128.20.1.2

A.ISI.EDU.

A 26.3.0.103

Первое поле представляет собой имя домена или субдомена, второе поле - значение TTL, третье - поле класс (Internet), четвертое - тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен.

Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 (“Common DNS Implementation Errors and Suggested Fixes”). Ошибки при конфигурации DNS-сервера могут привести к досадным ошибкам и отказам системы. Обычно, при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNS-серверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них. Если клиент прислал рекурсивный запрос и сервер поддерживает рекурсию, запрос пересылается соответствующим серверам. Если рекурсия не поддерживается, сервер возвращает клиенту список DNS-серверов, предоставляя ему решать свои проблемы самостоятельно. Однако в некоторых случаях DNS-сервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов.

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

Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и никаких-либо данных клиенту.

Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода “отклик” некорректным, он может послать запрос повторно и т.д. и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.

В системах Windows часто используется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, также как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает использование протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service).

WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом.

Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 4.4.12.7.

Рис. 4.4.12.7. Формат запроса WINS

В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 4.4.12.8.

Рис. 4.4.12.8. Формат отклика на WINS-запрос

Поле флаги имеет следующую структуру:

0 _ _ _	_ _ _ _	Команда
_ 000	0 _ _ _	Запрос
_ _ _ _	_ _ 0 _	Не укорочено
_ _ _ _	_ _ _ 0	Рекурсия нежелательна

1 _ _ _	_ _ _ _	Отклик
_ 000	0 _ _ _	Запрос
_ _ _ _	_ _ 0 _	Не укорочено
_ _ _ _	_ 1 _ _	Официальный ответ

Для поля флаги имени характерна следующая структура

0 _ _ _	_ _ _ _	Уникальное имя NetBIOS
_ 10 _	_ _ _ _	Узел М-типа
_ _ _ _	_ 1 _ _	Активное имя
_ _ _ _	_ _ 0 _	Временное имя

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

1 _ _ _	_ _ _ _	Имя группы NetBIOS
_ 10 _	_ _ _ _	Узел М-типа
_ _ _ _	_ 1 _ _	Активное имя
_ _ _ _	_ _ 0 _	Временное имя

В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решено путем использования цифровых подписей (RFC-2137).

Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnarure).

Формальный синтаксис

Последующая синтаксическая спецификация использует нотацию Бакуса-Наура (BNF - Backus-Naur Form), как это описано в [RFC-822] с одним исключением, разделителем, используемым в конструкции "#", служит одиночный пробел (SPACE), а не одна или более запятых.

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

address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")"

addr_adl ::= nstring

;; Хранит маршрут из route-addr [RFC-822], если не равно нулю

addr_host ::= nstring

;; NIL указывает на синтаксис группы [RFC-822].

;; В противном случае, содержит имя домена [RFC-822]

addr_mailbox ::= nstring

;; NIL индицирует конец группы [RFC-822]; если не NIL, а addr_host равно NIL,

;; содержит имя группы ;; [RFC-822].

;; В противном случае, содержит локальную часть [RFC-822]

addr_name ::= nstring

;; Содержит фразу из почтового ящика [RFC-822], если не NIL

alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /

"I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /

"Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /

"Y" / "Z" /

"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /

"i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /

"q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /

"y" / "z"

;; Чувствительно к набору строчными или прописными буквами

append ::= "APPEND" SPACE mailbox [SPACE flag_list]

[SPACE date_time] SPACE literal

astring ::= atom / string

atom ::= 1*ATOM_CHAR

ATOM_CHAR ::=

atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /

quoted_specials

authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)

auth_type ::= atom

;; Определено в [IMAP-AUTH]

base64 ::= *(4base64_char) [base64_terminal]

base64_char ::= alpha / digit / "+" / "/"

base64_terminal ::= (2base64_char "==") / (3base64_char "=")

body ::= "(" body_type_1part / body_type_mpart ")"

body_extension ::= nstring / number / "(" 1#body_extension ")"

;; Будущее расширение. Реализации клиента должны воспринимать поля

;; body_extension. Реализации сервера не должны генерировать

;; поля body_extension, за исключением случаев, закрепленных в будущих

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

body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp

[SPACE body_fld_lang

[SPACE 1#body_extension]]]

;; не должны присылаться при non-extensible доставке "BODY"

body_ext_mpart ::= body_fld_param

[SPACE body_fld_dsp SPACE body_fld_lang

[SPACE 1#body_extension]]

;; MUST NOT be returned on non-extensible "BODY" fetch

body_fields ::= body_fld_param SPACE body_fld_id SPACE

body_fld_desc SPACE body_fld_enc SPACE

body_fld_octets

body_fld_desc ::= nstring

body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil

body_fld_enc ::= ( ("7BIT" / "8BIT" / "BINARY" / "BASE64"/

"QUOTED-PRINTABLE") ) / string

body_fld_id ::= nstring

body_fld_lang ::= nstring / "(" 1#string ")"

body_fld_lines ::= number

body_fld_md5 ::= nstring

body_fld_octets ::= number

body_fld_param ::= "(" 1#(string SPACE string) ")" / nil

body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)

[SPACE body_ext_1part]

body_type_basic ::= media_basic SPACE body_fields

;; субтип MESSAGE не должен следовать "RFC822"

body_type_mpart ::= 1*body SPACE media_subtype

[SPACE body_ext_mpart]

body_type_msg ::= media_message SPACE body_fields SPACE envelope

SPACE body SPACE body_fld_lines

body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines

capability ::= "AUTH=" auth_type / atom

;; Новая возможность должна начинаться с "X" или быть зарегистрирована

;; IANA в качестве стандарта или являться усовершенствованием

;; существующего стандарта

capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"

[SPACE 1#capability]

;; серверы IMAP 4.1, которые предлагают совместимость с RFC 1730

;; должны включать "IMAP4" в список возможностей этой реализации

CHAR ::=

0x01 - 0x7f>

CHAR8 ::=

command ::= tag SPACE (command_any / command_auth /

command_nonauth / command_select) CRLF

;; Modal based on state

command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command

;; Справедливо для всех состояний

command_auth ::= append / create / delete / examine / list / lsub /

rename / select / status / subscribe / unsubscribe

;; Работает только в состояниях Authenticated или Selected

command_nonauth ::= login / authenticate

;; Работает только в состоянии Non-Authenticated

command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /

copy / fetch / store / uid / search

;; Работает только в состоянии Selected

continue_req ::= "+" SPACE (resp_text / base64)

copy ::= "COPY" SPACE set SPACE mailbox

CR ::=

create ::= "CREATE" SPACE mailbox

;; Использование INBOX не приводит к ошибке

CRLF ::= CR LF

CTL ::=

0x00 - 0x1f, 0x7f>

date ::= date_text / date_text

date_day ::= 1*2digit

;; День месяца

date_day_fixed ::= (SPACE digit) / 2digit

;; Версия с фиксированным форматом date_day

date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /

"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

date_text ::= date_day "-" date_month "-" date_year

date_year ::= 4digit

date_time ::= date_day_fixed "-" date_month "-" date_year

SPACE time SPACE zone

delete ::= "DELETE" SPACE mailbox

;; Использование INBOX не приводит к ошибке

digit ::= "0" / digit_nz

digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

envelope ::= "(" env_date SPACE env_subject SPACE env_from

SPACE env_sender SPACE env_reply_to SPACE env_to

SPACE env_cc SPACE env_bcc SPACE env_in_reply_to

SPACE env_message_id ")"

env_bcc ::= "(" 1*address ")" / nil

env_cc ::= "(" 1*address ")" / nil

env_date ::= nstring

env_from ::= "(" 1*address ")" / nil

env_in_reply_to ::= nstring

env_message_id ::= nstring

env_reply_to ::= "(" 1*address ")" / nil

env_sender ::= "(" 1*address ")" / nil

env_subject ::= nstring

env_to ::= "(" 1*address ")" / nil

examine ::= "EXAMINE" SPACE mailbox

fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /

"FAST" / fetch_att / "(" 1#fetch_att ")")

fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /

"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /

"BODY" ["STRUCTURE"] / "UID" /

"BODY" [".PEEK"] section

[""]

flag ::= "\Answered" / "\Flagged" / "\Deleted" /

"\Seen" / "\Draft" / flag_keyword / flag_extension

flag_extension ::= "\" atom

;; Будущее расширение. Реализации клиента должны воспринимать

;; флаги flag_extension. Реализации сервера не должны генерировать

;; флаги flag_extension, за исключением случаев, определенных в

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

;; данной спецификации.

flag_keyword ::= atom

flag_list ::= "(" #flag ")"

greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF

header_fld_name ::= astring

header_list ::= "(" 1#header_fld_name ")"

LF ::=

list ::= "LIST" SPACE mailbox SPACE list_mailbox

list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string

list_wildcards ::= "%" / "*"

literal ::= "{" number "}" CRLF *CHAR8

;; Число характеризует количество октетов CHAR8

login ::= "LOGIN" SPACE userid SPACE password

lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox

mailbox ::= "INBOX" / astring

;; INBOX не чувствителен к использованию строчных или прописных букв.

;; все версии написания INBOX (напр., "iNbOx") должны

;; интерпретироваться как INBOX, а не как строку.

mailbox_data ::= "FLAGS" SPACE flag_list /

"LIST" SPACE mailbox_list /

"LSUB" SPACE mailbox_list /

"MAILBOX" SPACE text /

"SEARCH" [SPACE 1#nz_number] /

"STATUS" SPACE mailbox SPACE

"(" #

number SPACE "EXISTS" / number SPACE "RECENT"

mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /

"\Noselect" / "\Unmarked" / flag_extension) ")"

SPACE ( QUOTED_CHAR / nil) SPACE mailbox

media_basic ::= ( ("APPLICATION" / "AUDIO" / "IMAGE" /

"MESSAGE" / "VIDEO") ) / string)

SPACE media_subtype

;; Определено в [MIME-IMT]

media_message ::= "MESSAGE" SPACE

"RFC822"

;; Определено в [MIME-IMT]

media_subtype ::= string

;; Определено в [MIME-IMT]

media_text ::= "TEXT" SPACE media_subtype

;; Определено в [MIME-IMT]

message_data ::= nz_number SPACE ("EXPUNGE" /

("FETCH" SPACE msg_att))

msg_att ::= "(" 1#("ENVELOPE" SPACE envelope /

"FLAGS" SPACE "(" #(flag / "\Recent") ")" /

"INTERNALDATE" SPACE date_time /

"RFC822" [".HEADER" / ".TEXT"] SPACE nstring /

"RFC822.SIZE" SPACE number /

"BODY" ["STRUCTURE"] SPACE body /

"BODY" section [""] SPACE nstring /

"UID" SPACE uniqueid) ")"

nil ::= "NIL"

nstring ::= string / nil

number ::= 1*digit

;; 32- битное целое число без знака

;; (0

nz_number ::= digit_nz *digit

;; 32-битное не равное нулю целое число без знака

;; (0 < n < 4,294,967,296)

password ::= astring

quoted ::= *QUOTED_CHAR

QUOTED_CHAR ::= /

"\" quoted_specials

quoted_specials ::= / "\"

rename ::= "RENAME" SPACE mailbox SPACE mailbox

;; Использование INBOX в качестве места назначения не дает ошибки

response ::= *(continue_req / response_data) response_done

response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /

mailbox_data / message_data / capability_data)

CRLF

response_done ::= response_tagged / response_fatal

response_fatal ::= "*" SPACE resp_cond_bye CRLF

;; Сервер закрывает соединение немедленно

response_tagged ::= tag SPACE resp_cond_state CRLF

resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text

;; Условие аутентификации

resp_cond_bye ::= "BYE" SPACE resp_text

resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text

;; Условие состояния

resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)

;; текст не должен начинаться с "[" или "="

resp_text_code ::= "ALERT" / "PARSE" /

"PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /

"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /

"UIDVALIDITY" SPACE nz_number /

"UNSEEN" SPACE nz_number /

atom [SPACE 1*]

search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]

1#search_key

;; Символьный набор [CHARSET] должен быть зарегистрирован IANA

search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /

"BEFORE" SPACE date / "BODY" SPACE astring /

"CC" SPACE astring / "DELETED" / "FLAGGED" /

"FROM" SPACE astring /

"KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /

"ON" SPACE date / "RECENT" / "SEEN" /

"SINCE" SPACE date / "SUBJECT" SPACE astring /

"TEXT" SPACE astring / "TO" SPACE astring /

"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /

"UNKEYWORD" SPACE flag_keyword / "UNSEEN" /

;; Выше этой строки все в [IMAP2]

"DRAFT" /

"HEADER" SPACE header_fld_name SPACE astring /

"LARGER" SPACE number / "NOT" SPACE search_key /

"OR" SPACE search_key SPACE search_key /

"SENTBEFORE" SPACE date / "SENTON" SPACE date /

"SENTSINCE" SPACE date / "SMALLER" SPACE number /

"UID" SPACE set / "UNDRAFT" / set /

"(" 1#search_key ")"

section ::= "[" [section_text / (nz_number *["." nz_number]

["." (section_text / "MIME")])] "]"

section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"]

SPACE header_list / "TEXT"

select ::= "SELECT" SPACE mailbox

sequence_num ::= nz_number / "*"

;; * является наибольшим используемым числом.

Для порядковых номеров

;; сообщений оно равно количеству сообщений в почтовом ящике.

;; Для уникальных идентификаторов оно равно уникальному

;; идентификатору последнего сообщения в почтовом ящике./p>

set ::= sequence_num / (sequence_num ":" sequence_num) /

(set "," set)

;; Идентифицирует набор сообщений. Для порядковых номеров

;; сообщений это последовательность чисел с 1 до числа

;; сообщений в почтовом ящике.

;; Запятая разграничивает индивидуальные номера, двоеточие

;; указывает на диапазон чисел включительно.

;; Пример для почтового ящика с 15 сообщениями: 2,4:7,9,12:*

;; эквивалентно 2,4,5,6,7,9,12,13,14,15.

SPACE ::=

status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"

status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /

"UNSEEN"

store ::= "STORE" SPACE set SPACE store_att_flags

store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE

(flag_list / #flag)

string ::= quoted / literal

subscribe ::= "SUBSCRIBE" SPACE mailbox

tag ::= 1*

text ::= 1*TEXT_CHAR

text_mime2 ::= "=?" "?" "?"

"?="

;; Синтаксис определен в [MIME-HDRS]

TEXT_CHAR ::=

time ::= 2digit ":" 2digit ":" 2digit

;; Часы, минуты, секунды

uid ::= "UID" SPACE (copy / fetch / search / store)

;; Уникальные идентификаторы используются вместо

;; последовательных номеров сообщения.

uniqueid ::= nz_number

;; В возрастающем порядке

unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox

userid ::= astring

x_command ::= "X" atom

zone ::= ("+" / "-") 4digit

;; Число из 4 цифр со знаком hhmm, представляющее часы и минуты к западу от Гринвича

;; (Это число отличается от Universal Time). Вычитая временную зону из данного времени, можно получить

;; форму UT. Зона Universal Time равна "+0000".

Формат данных

IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL.

Атом состоит из одного или более неспециализированных символов.

Число состоит из одной или более цифр и характеризует некоторое числовое значение.

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

Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.

Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой (). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF.

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

Формат сообщений управления NTP

Формат заголовков управляющих NTP-сообщений показан на рис. 4.4.15.2. Этот заголовок располагается непосредственно вслед за UDP-заголовком.

Рис. 4.4.15.2. Формат управляющего сообщения ntp

Первые два бита, обозначенные ZZ, должны всегда содержать 0.

Номер версии (VN - version number) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).

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

Бит отклика (R) - равен нулю для команд и 1 для откликов.

Бит ошибки (E) - равен нулю для нормального отклика и 1 в случае ошибки.

Бит продолжения (M - more) - равен нулю для последнего фрагмента и 1 - для всех остальных.

Код операции (OP) - 5-битовое поле, определяющее код команды. Значения кодов и их функции представлены в таблице 4.4.15.5.

Таблица 4.4.15.5. Коду операции управляющего сообщения

Код	Функция
0	Зарезервировано
1	чтение статуса команда/отклик
2	чтение переменной команда/отклик
3	запись переменной команда/отклик
4	чтение переменных часов команда/отклик
5	запись переменных часов команда/отклик
6	установка адреса/порта trap команда/отклик
7	отклик на Trap
8-31	Зарезервировано на будущее

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

Статус - 16-битовое поле, содержащее код статуса системы, партнера или часов.

Идентификатор ассоциации (Association ID) - 16-битовое поле, несущее в себе идентификатор ассоциации.

Смещение (Offset) - 16-битовое поле, определяющее положение первого октета поля данных в сообщении, передаваемом в нескольких дейтограммах (позиция задается в октетах).

Длина (Count) - 16-битовое поле, определяющее длину поля данных в октетах.

Данные - это поле содержит информацию сообщения, как для команды, так и для отклика. Максимальное число октетов в поле данных равно 468.

Аутентификатор (опционно). Поле, содержащие аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.

Форматы объектов

Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 4.4.9.6.9:

Рис. 4.4.9.6.9. Формат объекта

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

Длина в байтах

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

Class-Num

Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы:

NULL

Объект NULL имеет код Class-Num равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется.

SESSION

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

RSVP_HOP

Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). Этот класс характеризует предшествующий узел (previous hop).

TIME_VALUES

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

STYLE

Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Необходим в каждом сообщении Resv.

FLOWSPEC

Определяет желательный уровень QoS, в сообщениях Resv.

FILTER_SPEC

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

SENDER_TEMPLATE

Содержит IP-адрес отправителя и, может быть, некоторые дополнительную информацию, идентифицирующую отправителя. Необходим в сообщениях Path.

SENDER_TSPEC

Определяет характеристики информационного трафика отправителя.
Необходим в сообщениях Path.

ADSPEC

Несет в себе данные OPWA, в сообщении Path.

ERROR_SPEC

Специфицирует ошибку в сообщениях PathErr, ResvErr, или подтверждение в сообщении ResvConf.

POLICY_DATA

Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr.

INTEGRITY

Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного документа.

SCOPE

Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear.

RESV_CONFIRM

Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf.

C-Type

Тип объекта, уникален в пределах класса Class-Num.

Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно, как 16-битовое число, для определения уникального типа для каждого из объектов.

Старшие два бита Class-Num используются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.

Framing Capabilities & Bearer Capabilities

AVP Framing Capabilities и Bearer Capabilities (определенные в разделе 4.4.3) содержат 32-битовые маски. Дополнительные биты могут быть определены через стандартную процедуру [RFC 2434].

Функциональная спецификация RSVP Формат сообщений RSVP

Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.

Генерирование псевдослучайных -битовых идентификаторов

Ниже приведенная подпрограмма (заимствована из RFC-1889) генерирует псевдослучайные 32-битовые идентификаторы, используя программы MD5, опубликованные в RFC-1321 [11]. Системные программы могут и не присутствовать во всех операционных системах, но они помогают понять, какого рода информация может использоваться.

o getdomainname() ,

o getwd() , или

o getrusage()

"Живые" видео или аудио сигналы могут быть также не плохим источником случайных числе, при этом только следует позаботиться о том, чтобы микрофон не был отключен, а объектив камеры не был закрыт [7].

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

* Генерация псевдослучайного 32-битового числа.

#include <sys/types.h> u_long */

#include <sys/time.h> /* gettimeofday() */

#include <unistd.h> /* get..() */

#include <stdio.h> /* printf() */

#include <time.h> /* clock() */

#include <sys/utsname.h> /* uname() */

#include "global.h" /* from RFC 1321 */

#include "md5.h" /* from RFC 1321 */

#define MD_CTX MD5_CTX

#define MDInit MD5Init

#define MDUpdate MD5Update

#define MDFinal MD5Final

static u_long md_32(char *string, int length)

{

MD_CTX context;

union {

char c[16];

u_long x[4];

} digest;

u_long r;

int i;

MDInit (&context);

MDUpdate (&context, string, length);

MDFinal ((unsigned char *)&digest, &context);

r = 0;

for (i = 0; i < 3; i++) {

r ^= digest.x[i];

}

return r;

} /* md_32 */

* Полученный результат - 32-битовое число без знака. Используйте аргумент 'type' если вам

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

u_int32 random32(int type)

{

struct {

int type;

struct timeval tv;

clock_t cpu;

pid_t pid;

u_long hid;

uid_t uid;

gid_t gid;

struct utsname name;

} s;

gettimeofday(&s.tv, 0);

uname(&s.name);

s.type = type;

s.cpu = clock();

s.pid = getpid();

s.hid = gethostid();

s.uid = getuid();

s.gid = getgid();

return md_32((char *)&s, sizeof(s));

} /* random32 */

Характеристики BI-TCP

При аналезе характеристик протокола предполагается, что потери пакетов происходят с вероятностью 1/р. Авторы определяют эпоху перегрузки как время между двумы последовательными потерями пакетов.

Пусть Wmax обозначает размер окна непосредственно перед потерей пакета. После потери размер окна уменьшается до Wmax(1 - b). BI-TCP переключается от аддитивного увеличения к двоичному поисковому увеличению окна, когда различие между текущим значением ширины окна и конечным значением (target) меньше Smax. Так как конечное (target)значение ширины окна является средней точкой между Wmax и текущим значением ширины окна, можно сказать, что BI-TCP переключается между этими двумя приращениями, когда разница между текщией шириной окна и Wmax меньше 2Smax. Ниже в таблицах 2 и 3 представлены расчетные характеристики протоколов AIMD, BI-TCP, HSTCP и STCP для каналов с быстродействием 100 и 2500 Мбит/c.

Таблица 2. Отношения пропускной способности протоколов при 100Мбит/c

Отношение RTT	1	3	6
AIMD	0,99	7,31	26,12
BI-TCP	0,94	13,06	33,81
HSTCP	1,13	10,42	51,09
STCP	1,12	27,84	72,74

Таблица 3. Отношения пропускной способности протоколов при 2,5Гбит/c

Отношение RTT	1	3	6
AIMD	1,05	6,56	22,55
BI-TCP	0,96	9,18	35,76
HSTCP	0,99	47,42	131,03
STCP	0,92	140,52	300,32

На рис. 6 приведены расчетные данные для откликов при использовании разных модификаций протокола ТСР.

Рис. 6. Сравнение функций отклика для разных протоколов

ICMPv(ICMP для IPv

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

Incoming-Call-Connected (ICCN)

Incoming-Call-Connected (ICCN) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение ICRP. Оно является третьим сообщением из трех сообщений обмена, используемых для установления сессий в пределах L2TP-туннеля.

ICCN используется для индикации того, что ICRP принято, на вызов получен ответ, а L2TP-сессия должна перейти в состояние “установлена”. Оно также предоставляет дополнительную информацию LNS о параметрах, используемых для вызова, на который получен ответ (параметры, которые не всегда быть доступны в момент посылки ICRQ).

Следующие AVP должны присутствовать в ICCN:

Тип сообщения (Message Type)

Скорость обмена в канале ((Tx) Connect Speed)

Тип кадрового обмена (Framing Type)

Следующие AVP могут присутствовать в ICCN:

Initial Received LCP CONFREQ

Последнее посланное LCP CONFREQ

Последнее полученное LCP CONFREQ

Тип Proxy Authen

Имя Proxy Authen

Приглашение Proxy Authen

Прокси Authen ID

Отклик прокси Authen

ID частной группы

Скорость обмена соединения (Rx Connect Speed)

Необходима нумерация (Sequencing Required)

с другом связать запрос эхо

Рис. 4.4.1.1.37. Сообщение запрос эхо

Поля IPv6:

Адрес места назначения - любой легальный IPv6-адрес

Поля ICMPv6:

Тип 128

Код 0

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

Номер по порядку

Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

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

Описание

Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

Поля ICMPv6:

Тип 129

Код 0

Идентификатор. Идентификатор из исходного запроса эхо (echo request).

Номер по порядку. Номер по порядку из исходного запроса эхо.

Информация. Данные из исходного запроса эхо.

Описание

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

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

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

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

Оповещение верхнего уровня

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

Сообщение о членстве в группе имеет следующий формат:

Рис. 4.4.1.1.38. Сообщения участия в группе

Поля IPv6:

Адрес места назначения

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

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

Поле Hop Limit = 1 (предельное число шагов)

Поля ICMPv6:

Тип 130 - Запрос членства в группе

131 - Отчет о членстве в группе

132 - Сокращение членства в группе

Код 0

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

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

Не используется. Отправитель записывает нуль, получатель игнорирует.

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

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

Описание

Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].

Интерфейс маршрутизации RSVP

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

Запрос маршрута

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

Ucast_Route_Query( [ SrcAddress, ] DestAddress,

Notify_flag ) -> OutInterface

Mcast_Route_Query( [ SrcAddress, ] DestAddress,

Notify_flag )

-> [ IncInterface, ] OutInterface_list

В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Если флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет.

Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение `No such route' (такой маршрут отсутствует) возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.

Сообщение об изменении маршрута

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

Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

OutInterface

Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

[ IncInterface, ] OutInterface_list

Обнаружение списка интерфейсов

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

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

Интерфейс приложения RSVP

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

Регистрация сессии

Вызов: SESSION( DestAddress , ProtocolId, DstPort

[ , SESSION_object ]

[ , Upcall_Proc_addr ] ) -> Session-id

Этот вызов инициирует RSVP обработку сессии, заданной DestAddress, ProtocolId и, возможно, номером порта DstPort. В случае успеха вызов SESSION возвращает локальный идентификатор сессии Session-id, который может использоваться при последующих вызовах.

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

Определение отправителя

Вызов: SENDER( Session-id

[ , Source_Address ] [ , Source_Port ]

[ , Sender_Template ]

[ , Sender_Tspec ] [ , Adspec ]

[ , Data_TTL ] [ , Policy_data ] )

Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к SENDER для регистрации сессии как `Session-id' заставит RSVP начать рассылку сообщений Path для данной сессии; последующие вызовы будут модифицировать информацию о проходе.

Параметры SENDER интерпретируются следующим образом:

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

Source_Port. Это UDP/TCP порт, через который будут посылаться данные.

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

Sender_Tspec. Этот параметр описывает трафик потока; смотри [RFC 2210].

Adspec. Этот параметр может быть специфицирован для инициализации вычисления свойств QoS вдоль пути; смотри [RFC 2210].

Data_TTL. Это IP TTL параметр, который несут в себе информационные пакеты. Он необходим, чтобы гарантировать условие, при котором сообщения Path не будут попадать за пределы зоны мультикастинг-сессии.

Policy_data. Это опционный параметр несет в себе управляющую информацию для отправителя. Эта информация может задаваться системной службой и для приложения может быть недоступной.

RESERVE

Вызов: RESERVE( session-id, [ receiver_address , ]

[ CONF_flag, ] [ Policy_data, ]

style, style-dependent-parms )

Получатель использует этот вызов, для того чтобы осуществить или модифицировать резервирование для сессии `session-id'. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений.

Опционный параметр `receiver_address' может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр `Policy_data' специфицирует управляющие данные получателя, в то время как параметр `style' указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.

Отбой

Вызов: RELEASE( session-id )

Этот вызов удаляет состояние RSVP для сессии, указанной в session-id. Узел затем шлет соответствующие сообщения отмены (teardown) и прекращает рассылку сообщений обновления для session-id.

Вызовы Error/Event (ошибка/событие)

Общая форма вызова имеет вид:

Обращение: <Upcall_Proc>( ) -> session-id, Info_type,

information_parameters

"Upcall_Proc" представляет собой процедуру, чей адрес был дан при вызове SESSION. Это обращение может произойти асинхронно в любое время после вызова SESSION до вызова RELEASE и служит для индикации ошибки или события.

В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа.

1. Info_type = PATH_EVENT

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

Обращение (отклик): <Upcall_Proc>( ) -> session-id,

Info_type = PATH_EVENT,

Sender_Tspec, Sender_Template

[ , Adspec ] [ , Policy_data ]

Это обращение выдает спецификации Sender_Tspec, Sender_Template, Adspec и управляющую информацию из запроса Path.

2. Info_type = RESV_EVENT

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

Обращение (отклик): <Upcall_Proc>( ) -> session-id,

Info_type = RESV_EVENT,

Style, Flowspec, Filter_Spec_list

[ , Policy_data ]

`Flowspec' - эффективное значение QoS, которое получено. Заметим, что сообщение Resv (стиль FF) может вызвать несколько обращений RESV_EVENT, по одному для каждого дескриптора потока.

3. Info_type = PATH_ERROR

Событие Path Error индицирует ошибку в информации отправителя, которая была специфицирована в запросе SENDER.

Обращение (отклик): <Upcall_Proc>( ) -> session-id,

Info_type=PATH_ERROR,

Error_code , Error_value ,

Error_Node , Sender_Template

[ , Policy_data_list ]

Параметр Error_code определяет ошибку, а Error_value может нести в себе некоторую дополнительную (возможно системно-зависимую) информацию об ошибке. Параметр Error_Node специфицирует IP-адрес узла, который обнаружил ошибку. Параметр Policy_data_list, если он присутствует, содержит любые объекты POLICY_DATA из неудачного сообщения Path.

4. Info_type = RESV_ERR

Событие Resv Error указывает на ошибку в сообщении резервирования, в формирование которого приняло участие данное приложение.

Обращение (отклик): <Upcall_Proc>( ) -> session-id,

Info_type = RESV_ERROR,

Error_code , Error_value ,

Error_Node , Error_flags ,

Flowspec, Filter_spec_list

[ , Policy_data_list ]

Параметр Error_Node специфицирует IP- адрес узла, который обнаружил данное событие.

Имеется два флага Error_flags:

- InPlace

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

- NotGuilty

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

Filter_spec_list и Flowspec содержат соответствующие объекты из ошибки дескриптора потока. List_count специфицирует число FILTER_SPECS в списке Filter_spec_list. Параметр Policy_data_list содержит любые объекты POLICY_DATA из сообщения ResvErr.

5. Info_type = RESV_CONFIRM

Событие Подтверждение указывает, что получено сообщение ResvConf.

Обращение (отклик): <Upcall_Proc>( ) -> session-id,

Info_type = RESV_CONFIRM,

Style, List_count,

Flowspec, Filter_spec_list

[ , Policy_data ]

Параметры интерпретируются также как и для отклика Resv Error.

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

Интерфейс управления трафиком RSVP

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

Объединение RSVP-резервирований необходимо из-за мультикастной доставки данных, при которой информационные пакеты размножаются для отправки последующим узлам. В каждой такой точке размножения, RSVP должен объединять запросы резервирования от последующих узлов путем выбора “максимума” их спецификаций flowspecs. В данном маршрутизаторе или ЭВМ может присутствовать несколько таких точек объединения/размножения.

1. IP-уровень

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

2. Сеть

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

3. Драйвер канального уровня

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

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

Выполнение резервирования

Вызов: TC_AddFlowspec( Interface, TC_Flowspec,

TC_Tspec, TC_Adspec, Police_Flags )

-> RHandle [, Fwd_Flowspec]

Параметр TC_Flowspec определяет желательное значение QoS для управления доступом;. Его значение вычисляется как максимум совокупности спецификаций flowspecs для последующих узлов (см. ниже описание вызова Compare_Flowspecs).
Параметр TC_Tspec определяет эффективное значение спецификации отправителя Tspec Path_Te. Параметр TC_Adspec задает спецификацию Adspec. Параметр Police_Flags несет в себе три флага E_Police_Flag, M_Police_Flag и B_Police_Flag.

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

Модификация резервирования

Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,

TC_Tspec, TC_Adspec, Police_flags )

[ -> Fwd_Flowspec ]

Этот вызов используется для модификации существующего резервирования. TC_Flowspec передается блоку контроля разрешения. Если разрешения нет, текущая спецификация flowspec остается в силе. Соответствующие спецификации фильтров, если таковые имеются, остаются не затронутыми. Другие параметры определены также как и в TC_AddFlowspec. Если система модифицирует flowspec, вызов вернет также модифицированный объект Fwd_Flowspec.

Уничтожение спецификации Flowspec

Вызов: TC_DelFlowspec( Interface, RHandle )

Этот вызов ликвидирует существующее резервирование, включая спецификацию flowspec и все сопряженные спецификации фильтров.

Добавление спецификации фильтра

Вызов: TC_AddFilter( Interface, RHandle,

Session , FilterSpec ) -> FHandle

Этот вызов добавляет новую спецификацию фильтра для резервирования, заданного RHandle. Запрос посылается после успешного вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтра FHandle.

Уничтожение спецификации фильтра

Вызов: TC_DelFilter( Interface, FHandle )

Этот вызов используется для удаления какого-либо фильтра, идентифицируемого FHandle.

Модификация OPWA

Вызов: TC_Advertise( Interface, Adspec,

Non_RSVP_Hop_flag ) -> New_Adspec

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

Запрос резервирования

Обращение (отклик): TC_Preempt() -> RHandle, Reason_code

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

Интерфейсы RSVP

RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ - интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен).

IP

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

В Интернет используется много различных

4.4.1 IP-протокол

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

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.4.1.1		45	45
4.4.1.2		1	87
4.4.1.3		48	48

В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.

Рис. 4.4.1.1. Формат дейтограммы Интернет

Поле версия характеризует версию IP-протокола (например, 4 или 6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса слишком тяжелых последствий это не вызовет. Понятно также, что значение поля версия во избежании непредсказуемых последствий должно контролироваться программой. HLEN - длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (HLEN=5, без опций и заполнителя). Поле полная длина определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные. Одно-октетное поле тип сервиса (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей:

Субполе Приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

0 Обычный уровень

1 Приоритетный

2 Немедленный

3 Срочный

4 Экстренный

5 ceitic/ecp

6 Межсетевое управление

7 Сетевое управление

Формат поля TOS определен в документе RFC-1349.
Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. Так D=1 требует минимальной задержки, T=1 - высокую пропускную способность, R=1 - высокую надежность, а C=1 - низкую стоимость. TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP). В таблице 4.4.1.1 приведены рекомендуемые значения TOS.

Таблица 4.4.1.1. Значения TOS для разных протоколов

Процедура	Минимал. задержка	Максим. пропускная способность	Максим. надежность	Минимал. стоимость	Код TOS
FTP управление, FTP данные
1	0	0	0	0x10
0	1	0	0	0x08
TFTP	1	0	0	0	0x10
DNS, UDP TCP	1	0	0	0	0x00
0	0	0	0	0x10
0	0	0	0	0x00
telnet	1	0	0	0	0x10
ICMP	0	0	0	0	0x00
IGP	0	0	1	0	0x04
SMTP управление SMTP данные
1	0	0	0	0x10
0	1	0	0	0x08
SNMP	0	0	1	0	0x04
NNTP	0	0	0	1	0x02

Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) - надежность.

До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 4.4.1.1a. Биты CU пока не определены. Иногда это поле называется байтом DS (Differentiated Services).

Рис. 4.4.1.1a. Формат поля DSCP.

Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.

Селектор класса	DSCP
Приоритет 1	001000
Приоритет 2	010000
Приоритет 3	011000
Приоритет 4	100000
Приоритет 5	101000
Приоритет 6	110000
Приоритет 7	111000

На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior).

В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

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

Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset) управляют процессом фрагментации и последующей "сборки" дейтограммы. Идентификатор представляет собой уникальный код дейтограммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтограмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 - фрагментация разрешена; 1 - запрещена), бит 2 определяет, является ли данный фрагмент последним (0 - последний фрагмент; 1 - следует ожидать продолжения). Поле время жизни (TTL - time to live) задает время жизни дейтограммы в секундах, т.е. предельно допустимое время пребывания дейтограммы в системе. При каждой обработке дейтограммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтограмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет структуру поля данные (см. табл. 4.4.1.2).

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

Поле опции не обязательно присутствует в каждой дейтограмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, используется заполнитель. Структура октета кода опции отражена на рис. 4.4.1.2.

Таблица 4.4.1.2. Коды протоколов Интернет

Код протокола Интернет	Сокращенное название протокола	Описание
0	-	Зарезервировано
1	ICMP	Протокол контрольных сообщений [rfc792]
2	IGMP	Групповой протокол управления [rfc1112]
3	GGP	Протокол маршрутизатор-маршрутизатор [RFC-823]
4	IP	IP поверх IP (инкапсуляция/туннели)
5	ST	Поток [rfc1190]
6	TCP	Протокол управления передачей [RFC-793]
7	UCL	UCL
8	EGP	Протокол внешней маршрутизации [RFC-888]
9	IGP	Протокол внутренней маршрутизации
10	BBN-MON	BBN-RCC мониторирование
11	NVP-II	Сетевой протокол для голосовой связи [RFC-741]
12	PUP	PUP
13	ARGUS	argus
14	Emcon	emcon
15	Xnet	Перекрестный сетевой отладчик [IEN158]
16	Chaos	Chaos
17	UDP	Протокол дейтограмм пользователя [RFC-768]
18	MUX	Мультиплексирование [IEN90]
19	DCN-MEAS	DCN измерительные субсистемы
20	HMP	Протокол мониторирования ЭВМ (host [RFC-869])
21	PRM	Мониторирование при передаче пакетов по радио
22	XNS-IDP	Xerox NS IDP
23	Trunk-1	Trunk-1
24	Trank-2	Trunk-2
25	Leaf-1	Leaf-1
26	Leaf-2	Leaf-2
27	RDP	Протокол для надежной передачи данных [RFC-908]
28	IRTP	Надежный TP для Интернет [RFC-938]
29	ISO-TP4	ISO транспортный класс 4 [RFC-905]
30	Netblt	Массовая передача данных [RFC-969]
31	MFE-NSP	Сетевая служба MFE
32	Merit-INP	Межузловой протокол Merit
33	SEP	Последовательный обмен
34		не определен
35	IDRP	Междоменный протокол маршрутизации
36	XTP	Xpress транспортный протокол
37	DDP	Протокол доставки дейтограмм
38	IDPR-CMTP	IDPR передача управляющих сообщений
39	TP++	TP++ транспортный протокол
40	IL	IL-транспортный протокол
41	SIP	Простой Интернет-протокол
42	SDRP	Протокол маршрутных запросов для отправителя
43	SIP-SR	SIP исходный маршрут
44	SIP-Frag	SIP-фрагмент
45	IDRP	Интер-доменный маршрутный протокол
46	RSVP	Протокол резервирования ресурсов канала
47	GRE	Общая инкапсуляция маршрутов
49	BNA	BNA
50	SIPP-ESP	SIPP ESЗ
52	I-NLSP	Интегрированная система безопасности сетевого уровня
53	Swipe	IP с кодированием
54	NHRP	nbma протокол определения следующего шага
55-60		не определены
61		Любой внутренний протокол ЭВМ
62	CFTP	CFTP
63		Любая локальная сеть
64	Sat-Expak	Satnet и Expak
65	MIT-Subn	Поддержка субсетей MIT
66	RVD	Удаленный виртуальный диск MIT
67	IPPC	IPPC
68		Любая распределенная файловая система
69	Sat-Mon	Мониторирование Satnet
70	&nbsp	не определен
71	IPCV	Базовая пакетная утилита
75	PVP	Пакетный видео-протокол
76	BRsat-Mon	Резервное мониторирование Satnet
78	Wb-mon	Мониторирование Expak
79	Wb-expak	Широкополосная версия Expak
80	ISO-IP	ISO Интернет протокол
88	IGRP	IGRP (Cisco) - внутренний протокол маршрутизации
89	OSPFIGP	OSPFIGP - внутренний протокол маршрутизации
92	MTP	Транспортный протокол мультикастинга
101-254	&nbsp	не определены
255	&nbsp	зарезервировано

Рис. 4.4.1.2. Формат описания опций

Флаг копия равный 1 говорит о том, что опция должна быть скопирована во все фрагменты дейтограммы. При равенстве этого флага 0 опция копируется только в первый фрагмент. Ниже приведены значения разрядов 2-битового поля класс опции:

Значение поля класс опции	Описание
0	Дейтограмма пользователя или сетевое управление
1	Зарезервировано для будущего использования
2	Отладка и измерения (диагностика)
3	Зарезервировано для будущего использования

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

Класс опции	Номер опции	Длина описания	Назначение
0	0	-	Конец списка опций. Используется, если опции не укладываются в поле заголовка (смотри также поле "заполнитель")
0	1	-	Никаких операций (используется для выравнивания октетов в списке опций)
0	2	11	Ограничения, связанные с секретностью (для военных приложений)
0	3	*	Свободная маршрутизация. Используется для того, чтобы направить дейтограмму по заданному маршруту
0	7	*	Запись маршрута. Используется для трассировки
0	8	4	Идентификатор потока. Устарело.
0	9	*	Жесткая маршрутизация. Используется, чтобы направить дейтограмму по заданному маршруту
2	4	*	Временная метка Интернет

* в колонке "длина" - означает - переменная.

Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут (RR) создает дейтограмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, утилита traceroute). Формат опции записать маршрут в дейтограмме представлен ниже на рис. 4.4.1.3 (предусмотрено место для записи 9 IP-адресов, к сожаления, реализация RR не является обязательной):

Рис. 4.4.1.3 Формат опций записать маршрут

Поле код содержит номер опции (7 в данном случае). Поле длина определяет размер записи для опций, включая первые 3 октета. Указатель отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса).

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

Рис. 4.4.1.3а. Формат опций маршрутизации

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

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

Просмотр маршрутной таблицы происходит в три этапа:

Ищется полное соответствие адресу места назначения. В случае успеха, пакет посылается соответствующему маршрутизатору или непосредственно интерфейсу адресата. Связи точка-точка выявляются именно на этом этапе.

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

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

Для того чтобы посмотреть, как выглядит простая маршрутная таблица, воспользуемся командой netstat -rn (ЭВМ Sun. Флаг -r выводит на экран маршрутную таблицу, а -n отображает IP-адреса в цифровой форме. С целью экономии места таблица в несколько раз сокращена).

routing tables destination	gateway	flags	refcnt	use	interface
193.124.225.72	193.124.224.60	ughd	0	61	le0
192.148.166.1	193.124.224.60	ughd	0	409	le0
193.124.226.81	193.124.224.37	ughd	0	464	le0
192.160.233.201	193.124.224.33	ughd	0	222	le0
192.148.166.234	193.124.224.60	ughd	1	3248	le0
193.124.225.66	193.124.224.60	ughd	0	774	le0
192.148.166.10	193.124.224.60	ughd	0	621	le0
192.148.166.250	193.124.224.60	ughd	0	371	le0
192.148.166.4	193.124.224.60	ughd	0	119	le0
145.249.16.20	193.124.224.60	ughd	0	130478	le0
192.102.229.14	193.124.224.33	ughd	0	13206	le0
default	193.124.224.33	ug	9	5802624	le0
193.124.224.32	193.124.224.35	u	6	1920046	le0
193.124.134.0	193.124.224.50	ugd	1	291672	le0

Колонка destination - место назначение, Default - отмечает маршрут по умолчанию; Gateway - IP-адреса портов подключения (маршрутизаторов); REFCNT (reference count) - число активных пользователей маршрута; USE - число пакетов, посланных по этому маршруту; interface - условные имена сетевых интерфейсов. Расшифровка поля FLAGS приведено ниже:

u	Маршрут работает (up).
g	Путь к маршрутизатору (gateway), если этот флаг отсутствует, адресат доступен непосредственно.
h	Маршрут к ЭВМ (host), адрес места назначения является полным адресом этой ЭВМ (адрес сети + адрес ЭВМ). Если флаг отсутствует, маршрут ведет к сети, а адрес места назначения является адресом сети.
d	Маршрут возник в результате переадресации.
m	Маршрут был модифицирован с помощью переадресации.

Опция временные метки работает также как и опция запись маршрута.

Каждый маршрутизатор на пути дейтограммы делает запись в одном из полей дейтограммы (два слова по 32 разряда; смотри раздел ). Формат этой опции отображен на рисунке 4.4.1.4.

Рис. 4.4.1.4 Формат опции "временные метки"

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

Таблица 4.4.1.3.

Значение флага	Назначение
0	Записать только временные метки; опустить IP-адреса.
1	Записать перед каждой временной меткой IP-адрес (как в формате на предыдущем рисунке).
3	IP-адреса задаются отправителем; маршрутизатор записывает только временные метки, если очередной IP-адрес совпадает с адресом маршрутизатора

Временные метки должны содержать время в миллисекундах, отсчитанное от начала суток. Если маршрутизатору некуда положить свою временную метку (число меток превысило 9), он инкрементирует счетчик переполнение.

Взаимодействие других протоколов с IP можно представить из схемы на рис. 4.4.1.5. В основании лежат протоколы, обеспечивающие обмен информацией на физическом уровне, далее следуют протоколы IP, ICMP, ARP, RARP, IGMP и протоколы маршрутизаторов. Чем выше расположен протокол, тем более высокому уровню он соответствует. Протоколы, имена которых записаны в одной и той же строке, соответствуют одному и тому же уровню. Но все разложить аккуратно по слоям невозможно - некоторые протоколы занимают промежуточное положение, что и отражено на схеме, (области таких протоколов захватывают два уровня. Здесь протоколы IP, ICMP и IGMP помещены на один уровень, для чего имеется не мало причин. Но иногда последние два протокола помещают над IP, так как их пакеты вкладываются в IP-дейтограммы. Так что деление протоколов по уровням довольно условно. На самом верху пирамиды находятся прикладные программы, хотя пользователю доступны и более низкие уровни (например, ICMP), что также отражено на приведенном рисунке (4.4.1.5).

Рис. 4.4.1.5. Распределение протоколов Интернет по уровням

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

IPvадреса с вложенными IPvадресами

Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 4.4.1.1.5:

Рис. 4.4.1.1.5

Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат показанный на рис. 4.4.1.1.6:

Рис. 4.4.1.1.6

IPX Адреса

Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:

Рис. 4.4.1.1.8

Исходящие вызовы

Исходящие вызовы инициируются LNS и заставляют LAC реализовать вызов. Для исходящих вызовов используется три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply, и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, специфицирующий телефонный номер партнера, субадрес и другие параметры. LAC должен реагировать на сообщение Outgoing-Call-Request откликом Outgoing-Call-Reply, так как LAC определяет, что имеется возможность реализовать вызов, который должен быть административно авторизован. Например, разрешено ли LNS осуществлять международные телефонные вызовы? Если для исходящего вызова осуществлено соединение, LAC посылает LNS сообщение Outgoing-Call-Connected, характеризующее окончательный результат попытки вызова.

Исключение циклов сообщений RSVP

Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель "автоматического обновления". Такие петли автоматического обновления сохраняют состояние "вечно", даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов.

Рассмотрим каждый тип сообщения.

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

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

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

Сообщения Resv. Эти сообщения направлены определенному отправителю и не могут иметь циклов. Однако, сообщения Resv с произвольным выбором отправителя (wildcard) (стиль WF) имеет потенциал для запуска циклов обновления.

Сообщения ResvTear. Хотя сообщения ResvTear маршрутизируются также как и сообщения Resv. При повторном проходе по петле состояние будет отсутствовать (аннулировано), и любое сообщение ResvTear будет отброшено.

Сообщения ResvErr. Эти сообщения для стиля резервирования WF могут вызывать зацикливание по той же причине, что и для сообщений Resv.

Сообщения ResvConf. Эти сообщения направляются фиксированному уникастному получателю и не могут приводить к циклам.

Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако, когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.

Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:

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

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

Если объект SCOPE должен быть послан PHOP, следует удалить из набора любого отправителя, который не присылает данные через PHOP.

На рис. 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.

Интерфейс IА	Интерфейс IБ	Интерфейс IВ
Получает	Отправляет	Получает	Отправляет	Получает	Отправляет
WF([S1,S2,S3])	WF([S4])	WF([S2,S3,S4])	WF([S1])	WF([S4,S1])	WF([S2,S3])

Рис. 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF

Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:

Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, соответствующего состоянию резервирования или сообщению, которое вызвало ошибку.

Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.