Телекоммуникационные технологии. Том 1

         

Отклик SEARCH


Содержимое: нуль или более чисел.

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

Пример: S: * SEARCH 2 3 6



Отклик Start-Control-Connection (SCCRP)


Start-Control-Connection-Reply (SCCRP) является управляющим сообщением, посланным в ответ на сообщение SCCRQ. SCCRP используется для индикации того, что SCCRQ было принято и установление туннеля должно быть продолжено. Следующие AVP должны присутствовать в SCCRP:

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

Версия протокола (Protocol Version)

Framing Capabilities

Имя ЭВМ (Host Name)

Присвоенный туннелю ID (Assigned Tunnel ID)

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

Возможности несущего канала (Bearer Capabilities)

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

Имя производителя (Vendor Name)

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

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

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



Отклик STATUS


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

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

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



Отклик в случае, когда не исполняется никакой команды


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



Отклик входящего вызова ICRP (Incoming-Call-Reply)


Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.

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

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

ID, присвоенный сессии (Assigned Session ID)



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


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

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

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

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

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

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

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



Отклики сервера - отклики состояния


Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы.

Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:

ALERT Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание.
NEWNAME За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика.
PARSE Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике.
PERMANENTFLAGS Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике.
READ-ONLY Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only.
READ-WRITE Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write.
TRYCREATE Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE
UIDVALIDITY Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора.
UNSEEN Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen.

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



Отклики сервера - размер почтового ящика


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



Отклики сервера - сообщения о состоянии сервера и почтового ящика


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



Отклики сервера - статусное сообщение


Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения.



Отклики сервера - запрос продолжения команды


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

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

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

Пример: C: A001 LOGIN {11}

S: + Ready for additional command text

C: FRED FOOBAR {7}

S: + Ready for additional command text

C: fat man

S: A001 OK LOGIN completed

C: A044 BLURDYBLOOP {102856}

S: A044 BAD No such command as "BLURDYBLOOP"



Отсутствие следующего заголовка


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



Outgoing-Call-Connected (OCCN)


Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля.

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

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

Скорость обмена ((Tx) Connect Speed)

Тип кадрового обмена (Framing Type)

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

Скорость обмена (Rx Connect Speed)

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



Пакетная процедура


Пакетная процедура проверяет корректность сообщения, вычисляет задержку/смещение и вызывает другие процедуры для отбора данных и выбора источника синхронизации. Тест 1 требует, чтобы переданная временная метка отличалась от последней, полученной от того же партнера. Тест 2 требует, чтобы исходная временная метка соответствовала последней метке, посланной тому же партнеру. В случае широковещательного режима (5) rtt=0 и полная точность операции передачи времени будет недостижимой. Однако, полученная точность может быть вполне приемлемой для многих целей. Процедура вызова коррекции времени использует в качестве параметра peer.hostpoll (peer.peerpoll может быть изменено).

begin packet procedure

peer.rec

/* забрать полученную временную метку */

if (pkt.mode ? 5) begin

test1

/* Тест 1 */
test2

/* Тест 2 */

endif

else begin

pkt.org

/* потеря временной метки из-за ошибки */

pkt.rec

test1; /* ложные тесты */

test2;

endif

peer.org

/* актуализация исходной временной метки */
peer.peerpoll

/* скорректировать период рассылки */

poll-update(peer.hostpoll);

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

test3

rtt и временное смещение по отношению партнера вычисляется следующим образом. Пусть i четное целое число.

Тогда ti-3, ti-2, ti-1 и ti - содержимое переменных pkt.org, pkt.rec, pkt.xmt и peer.rec, соответственно. Смещение часов j, rtt=d и дисперсия e ЭВМ по отношению к партнеру равны:

d = (ti - ti-3) - (ti-1 - ti - 2),

j = ((ti - 2 - ti-3) + ( ti-1 - ti))/2,

e = (1 j (ti - ti-3),

где, как и прежде, j = ntp.maxskew/ntp.maxage. e представляет собой максимальную ошибку или дисперсию, связанную с ошибкой измерения на стороне ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за время после посылки последнего сообщения, посланного партнером. Дисперсия корректируется процедурой фильтра часов (clock-filter).


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

Тест 4 требует, чтобы вычисленная задержка лежала в допустимых пределах:

test4 d| < ntp.maxdisperse И e

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

#ifdef (authentication implemented) /* Тест 5 */

test5

#endef

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

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

Тест 8 требует, чтобы заголовок содержал соответствующие коды в полях pkt.rootdelay и pkt.rootdispersion.

test6 2 and /* Тест 6 */
{pkt.reftime ? pkt.xmt

test7

/* Тест 7 */
{pkt.stratum

test8

/* Тест 8 */
{pkt.rootdispersion

С точки зрения последующей обработки пакеты содержат корректные данные, если успешно проходят тесты 1-4 (test1 & test2 & test3 & test4 = 1), вне зависимости от результатов других тестов. Только пакеты с корректными данными могут использоваться для вычисления смещения (offset), задержки (delay) и дисперсии. Пакеты имеют корректные заголовки, если успешно проходят тесты 5-8 (test5 & test6 & test7 & test8 = 1), вне зависимости от результатов остальных тестов. Только пакеты с корректными заголовками могут использоваться для определения того, может ли партнер быть выбран в качестве источника синхронизации. Заметим, что тесты 1-2 не используются в широковещательном режиме.

Процедура "часовой фильтр" вызывается для вычисления задержки (peer.delay), смещения (peer.offset) и дисперсии (peer.dispersion) для партнера.Спецификация алгоритма часового фильтра не является составной частью протокола NTP. По этой причине описания, приводимые ниже, следует рассматривать как рекомендательные.

if (not valid header) exit;

peer.leap < pkt.leap; /* Копирование переменных пакета */
peer.stratum ;

peer.precision ;

peer.rootdelay ;

peer.rootdispersion ;

peer.refid ;

peer.reftime ;

if (valid data) call clock-filter(q, d, e); /* обработка данных */
end packet procedure;


Пакетные I/O интерфейсы RSVP


Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.

Неизбирательный режим приема сообщений RSVP

Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.

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

Спецификация выходного канала

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

Спецификация адреса источника и TTL

RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path.

Оповещение маршрутизатора

RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).



Пакетные переменные


Номер версии (pkt.version) - целое число индицирующее номер версии отправителя. NTP сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии (ntp.version). Исключения допускаются лишь при смене номера версии.



Ниже описаны параметры для всех


Ниже описаны параметры для всех реализаций, работающих в сети Интернет. Необходимо договориться относительно значений этих параметров для того, чтобы исключить ненужную избыточность и стабилизировать ассоциации партнеров. Приведенные параметры применимы для всех ассоциаций.
Номер версии (ntp.version) - текущий номер версии NTP (3).
Порт NTP (ntp.port) - стандартный номер порта (123), присвоенный протоколу NTP.
Максимальный номер слоя (ntp.maxstratum) - максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).
Максимальный возраст часов (ntp.maxage) - максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться корректными после последней сверки.
Максимальный сбой (ntp.maxskew) - максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.
Максимальное расстояние (ntp.maxdistance) - максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.
Минимальный период рассылки (ntp.minpoll) - минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Максимальный период рассылки (ntp.maxpoll) -максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Минимум избранных часов (ntp.minclock) - минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).
Максимум избранных часов (ntp.maxclock) - максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).
Минимальная дисперсия (ntp.mindisperse) - минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).
Максимальная дисперсия (ntp.maxdisperse) - максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).
Размер регистра доступности (ntp.window) - размер регистра доступности (peer.reach) в битах.
Размер фильтра (ntp.shift) - размер сдвигового регистра фильтра часов (peer.filter) в каскадах.
Вес фильтра (ntp.filter) - вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации).
Выбранный вес (ntp.select) - вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции).

Пары значений-атрибутов управляющих сообщений Формат AVP


Каждая AVP кодируется следующим образом:

0123 4 56 789 101112131415 161718192021 222324252627 28293031
M H rsvd Длина ID производителя
Тип атрибута Значение атрибута
Продолжение поля значение атрибута до границы, заданной полем длина

Рис. 4.

Первые 6 бит представляют собой битовую маску, характеризующую атрибуты AVP.

Два бита определены в этом документе, остальные - зарезервированы на будущее. Зарезервированные биты должны равняться нулю. AVP, полученная с зарезервированным набором бит равным 1, должна рассматриваться как не узнанная AVP.

Обязательный бит M (Mandatory) контролирует реакцию системы на получение нераспознанной AVP. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном с определенной сессией, эта сессия должна быть немедленно завершена. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном со всем туннелем, этот туннель (и все его сессии) должен быть ликвидирован. Если бит M =0, нераспознанную AVP следует игнорировать. Управляющие сообщения должны обрабатываться при этом так, как если бы AVP не было.

Бит сокрытия (H). Идентифицирует скрываемые данные в поле значения атрибута AVP. Эта возможность может использоваться, чтобы исключить передачу важных данных, например пароля пользователя, в незашифрованном тексте AVP. В разделе 4.3 описана процедура выполнения сокрытия AVP.

Длина. Число октетов (включая поля полной длины и маски) в AVP. Длина может быть вычислена как 6 + длина поля значения атрибута в октетах. Поле имеет 10 бит, позволяя закодировать до 1023 октетов в одной AVP. Минимальный код длины AVP равен 6. Если длина равна 6, поле значения атрибута отсутствует.

ID производителя (Vendor ID). IANA определила значения кодов производителей (SMI Network Management Private Enterprise Codes) [RFC1700]. Значение 0, соответствующее атрибутам, адаптированным для IETF, используется для всех AVP, определенных в данном документе. Любой производитель, желающий реализовать свое собственное расширение L2TP, может использовать свой код Vendor ID вместе с частными значениями атрибута, гарантирующие отсутствие столкновений с любыми расширениями других производителей, или будущими расширениями IETF. Заметим, что для ID-производителя выделено 16 бит, что ограничивает максимальное число производителей цифрой 65,535.

Тип атрибута: 2-октетное значение с уникальной интерпретацией для совокупности AVP данного ID-производителя.

Значение атрибута. Действительное значение атрибута для заданного Vendor ID и типа атрибута. Оно следует немедленно после поля типа атрибута, и занимает все пространство октетов, отведенное значением поля длина (т.e., длина минус 6 октетов заголовка). Это поле отсутствует, если длина равна 6.



Переадресация кадров PPP


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

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

Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля.



Переменные аутентификации


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

Бит разрешения аутентификации (peer.authenable) - бит, указывающий, что ассоциация должна работать в режиме аутентификации.

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

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

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

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



Переменные фильтра часов


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

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

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

Смещение (peer.offset) - число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.

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

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



Переменные партнера


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

Бит конфигурации (peer.config) - бит, индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен.

Временная метка актуализации (peer.update) - локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига.

Регистр достижимости (peer.reach) - сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.

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



Первичная частота и стандарты времени


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

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

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

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

Таблица 4.4.15.12. Точность и стабильность часов для различных слоев

Слой Минимальная точность (за день) Минимальная стабильность (за день)
1 1 x 10-11 Не специфицировано
2 1.6 x 10-8 1 x 10-10
3 4.6 x 10-6 3.7 x 10-7
4 3.2 x 10-5 Не специфицировано

Конструкция, работа и характеристики осциллятора слоя 1 предполагаются сопоставимыми с национальными стандартами времени и часто базируются на цезиевом стандарте. Часы слоя 4 соответствуют требованиям обычных цифровых каналов и систем PBX. Слои 2-3 могут использоваться для работы с мощными синхронными каналами связи.



Подтверждение


Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос.

Этот механизм подтверждения имеет следующую последовательность:

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

Получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и он может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.



Политика в области трафика и узлы с не интегрированными услугами


Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях:

Краевые точки сети.

Точки объединения данных от многих отправителей.

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

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

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

E_Police_Flag - управление входом

Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю, флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION.

M_Police_Flag - управление объединением

Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя.

B_Police_Flag -управление ветвлением

Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION.

RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS. Эта информация передается получателям в спецификации Adspecs [RFC 2210].

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



Порядок заголовков расширения


Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:

IPv6 заголовок

Заголовок опций hop-by-hop

Заголовок опций места назначения (destination options header, (1) )

Заголовок маршрутизации

Заголовок фрагмента

Заголовок authentication (2)

Заголовок безопасных вложений (encapsulating security payload, (2) )

Заголовок опций места назначения (destination options header (3) )

Заголовок верхнего уровня.

(1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.

(2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.

(3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута.

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

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

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



Постепенная настройка фазы


Если локальные часы нескорректированы, они продолжают работать со смещением и частотой (при отсутствии дрейфа), установленными при последней коррекции. Корректирующая информация имеет формат 48-битного целого числа со знаком. Это число характеризует целое и дробное число миллисекунд (запятая располагается после 32-го двоичного разряда). Если полученная величина превосходит максимальное значение, заданное CLOCK.MAX, необходима постепенная пошаговая коррекция. В норме величина поправки вычисляется в рамках алгоритма NTP. Однако, если код счетчика PPS больше нуля, вместо него должен использоваться регистр PPS-ADJUST. Пусть u представляет собой 32-битовый код с битами 0-31 равными разрядам 16-47 корректирующего кода. Если некоторые младшие биты корректирующего кода не используются, они устанавливаются равными биту знака. Такие операции сдвигают положение запятой влево по отношению биту 16, что уменьшает влияние ошибок округления. Пусть b число начальных нулей в коде регистра Compliance и пусть c - число начальных нулей в коде счетчика W@atchdog. Тогда b установится равным:

b = b - 16 + clock.comp

b не должно быть меньше нуля (это логарифм постоянной времени обратной связи). Затем установим c равным:

c = 10 - c

Величина c представляет собой логарифм времени интегрирования со времени последней коррекции. Затем вычисляются новые значения кодов для регистров CLOCK.ADJUST и Skew-Compensation.

x = u >> b,

y = y + (u >> (b + b - c)).

В заключение вычисляем экспоненциальное среднее

z = z + (u > clock.weight,

где сдвиг влево переносит положения запятой с целью достижения большей точности.

Для каждого периода подстройки определяется корректирующий код из двух составляющих. Первая составляющая (фаза) определяется как

x >> clock.phase,

эта величина затем вычитается из предшествующего значения регистра Clock-Adjust. Результат становится новым значением кода этого регистра. Вторая компонента - (частота) определяется как

y >> clock.freq.

Совокупность фазы и частоты представляет собой окончательный корректирующий код, который затем добавляется к коду регистра (clock). В заключение, счетчик Watchdog обнуляется.

Величина b вычисленная ранее может использоваться для изменения величины системной переменной, характеризующей период запросов (коррекций) sys.poll.

sys.poll

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



Посылка сообщений RSVP


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

Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.

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

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

Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).

Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.

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

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

Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.

Следующий узел N' запоминает значение LIH в своем состоянии прохода.

Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP).

Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.



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


Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):

FF00:0:0:0:0:0:0:0

FF01:0:0:0:0:0:0:0

FF02:0:0:0:0:0:0:0

FF03:0:0:0:0:0:0:0

FF04:0:0:0:0:0:0:0

FF05:0:0:0:0:0:0:0

FF06:0:0:0:0:0:0:0

FF07:0:0:0:0:0:0:0

FF08:0:0:0:0:0:0:0

FF09:0:0:0:0:0:0:0

FF0A:0:0:0:0:0:0:0

FF0B:0:0:0:0:0:0:0

FF0C:0:0:0:0:0:0:0

FF0D:0:0:0:0:0:0:0

FF0E:0:0:0:0:0:0:0

FF0F:0:0:0:0:0:0:0

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

Адреса для обращения ко всем узлам:

FF01:0:0:0:0:0:0:1

FF02:0:0:0:0:0:0:1

Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы).

Адреса всех маршрутизаторов:

FF01:0:0:0:0:0:0:2

FF02:0:0:0:0:0:0:2

Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).

DHCP server/relay-agent: FF02:0:0:0:0:0:0:C

Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).

Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx

Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:

FF02:0:0:0:0:1:0000:0000

до

FF02:0:0:0:0:1:FFFF:FFFF

Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.



Прерывание сессии


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

LAC или LNS LAC или LNS

CDN ->

(Clean up)

<- ZLB ACK
(Clean up)



к последней минуте текущего дня.


Формат NTP-сообщения, которое следует сразу после UDP-заголовка, показан на рис 4.4.15.1.

Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.



Рис. 4.4.15.1. Формат сообщения NTP.

Номер версии (VN) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).

Режим (Mode) - трехбитовое поле, определяющее режим, значения кодов режима приведены в таблице 4.4.15.2.

Слой (Stratum) - 8-битовое поле, определяющее код слоя, где работают локальные часы. Коды слоя представлены в таблице 4.4.15.3. Возможные значения кодов лежат в интервале от нуля до NTP.INFIN включительно.

Период запросов (poll interval) - 8-битовое поле, указывающее на максимальное значение интервала между запросами. Код, записанный в этом поле, интерпретируется как целое число со знаком и характеризует значение периода в секундах, как ближайшее к величине степени двух. Коды, которые могут быть записаны в этом поле, должны лежать в интервале между NTP.MAXPOLL и NTP.MAXPOLL включительно.

Точность (precision) - 8-битовое поле, обозначающее точность локальных часов в секундах. Код поля интерпретируется как целая степень со знаком числа 2.

Базовая задержка (Root Delay) - 32-битовое поле, характеризующее RTT до эталонного источника в секундах. Код поля интерпретируется как число с фиксированной запятой, размещенной между битами 15 и 16. Заметим, что величина этого кода может иметь и отрицательное значение (зависит от точности часов и величины дрейфа).

Базовая дисперсия (Root Dispersion) - 32-битовое поле, определяющее максимальную ошибку по отношению к эталонному источнику в секундах. Код поля интерпретируется как число с фиксированной запятой (между 15 и 16 битами). Допустимы только положительные значения.

Идентификатор эталонных часов (Reference Clock Identifier) - 32-битовое поле, идентифицирующее конкретные эталонные часы. В случае кода слоя нуль (не специфицировано) или слоя 1 (первичный эталон), это 4-октетная комбинация выравнивается по левому краю и дополняется нулями (ASCII).
Когда идентификатор в NTP не специфицирован, предлагаются ascii- идентификаторы, приведенные в таблице 4.4.15.4.

В случае слоя 2 и больше (вторичный эталон) - это 4-октетный IP-адрес ЭВМ - первичного эталона.

Эталонная временная метка (Reference Timestamp) - поле локального времени (64-битовый формат временных меток), когда часы корректировались в последний раз.

Исходная временная метка (Originate Timestamp) определяет время, когда запрос направлен серверу (стандартный 64-битовый формат временных меток).

Получаемая временная метка (Receive Timestamp) - время, когда запрос прибыл к серверу (стандартный 64-битовый формат временных меток).

Передаваемая временная метка (Transmit Timestamp) - локальное время, когда послан отклик сервером (стандартный 64-битовый формат временных меток).

Аутентификатор (authenticator) (опционно) - поле, содержащее аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.


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


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

Класс сессии

Класс сессии = 1.

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

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

DestAddress

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

Протокол Id

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

Флаги

0x01 = E_Police flag

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

DstPort

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

Класс RSVP_HOP

RSVP_HOP класс = 3.

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

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

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

Класс INTEGRITY

INTEGRITY класс = 4.

Класс TIME_VALUES

TIME_VALUES класс = 5.

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

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

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

Класс ERROR_SPEC

ERROR_SPEC класс = 6.

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




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



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

Флаги

0x01 = InPlace

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

0x02 = NotGuilty

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

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

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

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

Класс SCOPE = 7.



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

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

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

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

Класс STYLE = 8.



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

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

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

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

19 бит: Зарезервировано

2 бита: контроль совместного использования

00b: Зарезервировано

01b: Явное резервирование

10b: Распределенное резервирование

11b: Зарезервировано

3 бита: Управление выбором отправителя



000b: Зарезервировано

001b: Произвольный выбор (Wildcard)

010b: Прямой выбор (Explicit)

011b - 111b: Зарезервировано

Младшие биты вектора опций определяются стилем:

WF 10001b

FF 01010b

SE 10010b

Класс FLOWSPEC

Класс FLOWSPEC = 9.

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

Объект Inv-serv Flowspec: Класс = 9, C-тип = 2

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

Класс FILTER_SPEC = 10.



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

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

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

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



SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ отправителя. Его значение не должно быть равно нулю.

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

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

Класс SENDER_TEMPLATE = 11.

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

Определение то же, что и для объекта IPv4/UDP FILTER_SPEC.

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

Определение то же, что и для объекта IPv6/UDP FILTER_SPEC.

Объект метки потока IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 3

Класс SENDER_TSPEC = 12.

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

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

Класс ADSPEC = 13.

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

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

Класс POLICY_DATA = 14.

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

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

Класс Resv_CONFIRM = 15.

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

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

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

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


a Рекомендации по формированию опций


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

Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.

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

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

Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:

Пример 1

Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):

Рис. 4.4.1.1.27.

Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):

Рис. 4.4.1.1.28

Пример 2

Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):

Рис. 4.4.1.1.29

Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):

Рис. 4.4.1.1.30

Пример 3

Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):

Рис. 4.4.1.1.31

Рис. 4.4.1.1.32



B Коды и значения ошибки


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

Код ошибки = 00: Подтверждение.

Это код зарезервирован для использования в объекте ERROR_SPEC сообщения ResvConf. Значение ошибки также будет равно нулю.

Код ошибки = 01: Отказ системы управления допуском.

Запрос резервирования отвергнут системой управления допуском из-за недостатка ресурсов. Для этого кода ошибки 16 бит поля значение ошибки имеют формат:

ssur cccc cccc cccc

где биты имеют следующие значения:

ss = 00: Младшие 12 бит содержат глобально-определенный субкод (значение приведены ниже).

ss = 10: Младшие 12 бит содержат организационно-специфический субкод. Предполагается, что RSVP интерпретирует этот код как обычное число.

ss = 11: Младшие 12 бит содержат субкод, зависящий от вида услуг. Предполагается, что RSVP интерпретирует этот код как обычное число.

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

u = 0: RSVP отвергает сообщение без модификации локального состояния

u = 1: RSVP может использовать сообщение для модификации локального состояния и для последующей пересылки. Это означает, что сообщение является информационным.

r: зарезервированный бит, должен быть равен нулю.

cccc cccc cccc: 12 битовый код.

Следующие глобально-заданные субкоды могут появиться в младших 12 битах, когда ssur = 0000:

- Субкод = 1: Предел (bound) по задержке не может быть обеспечен.

- Субкод = 2: Запрашиваемая полоса пропускания недоступна.

- Субкод = 3: MTU в flowspec больше чем MTU интерфейса.

Код ошибки = 02: Policy Control failure

Сообщение резервирования или path было отвергнуто по административным причинам, например, не выполнены условия аутентификации, недостаточная квота и т.д.. Этот код ошибки может появиться в сообщении PathErr или ResvErr.


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

Код ошибки = 03: Нет информации о проходе для этого сообщения Resv. Нет состояния прохода для данной сессии. Сообщение Resv не может быть переслано.

Код ошибки = 04: Нет информации отправителя для этого сообщения Resv. Имеется состояние прохода для этой сессии, но оно не включает в себя записи отправителя, соответствующей дескриптору потока, который содержится в сообщении Resv. Сообщение Resv не может быть переслано.

Код ошибки = 05: Конфликт со стилем резервирования. Стиль резервирования конфликтует со стилем существующего состояния резервирования. Поле значение ошибки содержит младшие 16 бит вектора опций существующего стиля, с которым произошел конфликт. Сообщение Resv не может быть переслано.

Код ошибки = 06: Неизвестный стиль резервирования. Стиль резервирования неизвестен. Сообщение Resv не может быть переслано.

Код ошибки = 07: Конфликт портов места назначения. Появились сессии для одного и того же адреса места назначения с нулевым и ненулевым значением полей порта назначения. Этот код ошибки может появиться в сообщении PathErr или ResvErr.

Код ошибки = 08: Конфликт портов отправителя. Для одной и той же сессии имеются нулевые и ненулевые порты отправителя в сообщениях Path. Этот код ошибки может появиться только в сообщении PathErr.

Код ошибки = 09, 10, 11: (зарезервировано)

Код ошибки = 12: Привилегированное обслуживание. Запрос обслуживания, определенный объектом STYLE, и дескриптор потока были административно перехвачены.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ssur cccc cccc cccc

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

Код ошибки = 13: Неизвестный класс объекта. Этот код ошибки содержит 16-битовое слово, состоящее из (Class-Num, C-тип) неизвестного объекта. Эта ошибка должна быть послана только в случае, когда RSVP намеревается отвергнуть сообщение, как это определено старшими битами Class-Num.


Этот код ошибки может появиться в сообщении PathErr или ResvErr.

Код ошибки = 14: Неизвестный объект C-типа. Значение ошибки содержит 6-битовый код, состоящий из (Class-Num, C-тип) объекта.

Код ошибки = 15-19: (зарезервировано)

Код ошибки = 20: Зарезервировано для API. Поле значение ошибки содержит код ошибки API, которая была обнаружена асинхронно и о которой необходимо уведомить систему соответствующим откликом.

Код ошибки = 21: Ошибка управления трафиком. Запрос управления трафиком не прошел из-за формата или содержимого параметров запроса. Сообщения Resv или Path, которые инициировали вызов, не могут быть пересланы, повторные вызовы бесполезны.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ss00 cccc cccc cccc

Ниже представлены значения старших бит ss, как это определено для кода ошибки 01.

Следующие глобально-заданные субкоды могут появляться в младших 12 битах (cccc cccc cccc), когда ss = 00:

Субкод = 01: Конфликт сервиса. Попытка объединить два несовместимых запроса обслуживания.

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

Субкод = 03: Плохое значение Flowspec. Запрос неверного формата или неприемлемые требования.

Субкод = 04: Плохое значение Tspec. Запрос неверного формата или неприемлемых требований.

Субкод = 05: Плохое значение Adspec. Запрос неверного формата или неприемлемые требования.

Код ошибки = 22: Ошибка системы управления трафиком. Модули управления трафиком обнаружели системную ошибку. Значение ошибки будет содержать специфический для системы код, предоставляющий дополнительную информацию об ошибке. Предполагается, что RSVP не может интерпретировать его значение.

Код ошибки = 23: Системная ошибка RSVP

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

Вообще каждое сообщение RSVP переформируется в каждом узле, а узел, в котором генерируется RSVP сообщение, несет ответственность за его правильную структуру.


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

Единственными ошибками формата сообщений, которые доводятся до сведения оконечной системы, являются несоответствия версии.

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

Неверная длина сообщения: Поле длины RSVP не соответствует реальной длине сообщения.

Неизвестная или неподдерживаемая версия RSVP.

Ошибка в контрольной сумме RSVP

Ошибка в INTEGRITY

Нелегальный тип сообщения RSVP

Нелегальная длина объекта: не кратна 4, или меньше 4 байт.

Адрес предыдущего/следующего узла в объекте HOP является нелегальным.

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

Отсутствует необходимый класс объекта

Нелегальный класс объекта для данного типа сообщения.

Нарушение регламентируемого порядка объектов

Неверное число дескрипторов потока для данного типа сообщения или стиля

Неверный дескриптор логического интерфейса

Неизвестный объект Class-Num.

Адрес места назначения сообщения ResvConf не согласуется с адресом получателя в объекте RESV_CONFIRM.


B: Примеры управляющих сообщений B Установление туннеля Lock-step


В этом примере, LAC формирует туннель, при этом реализуется обмен сообщениями в обоих направлениях. В этом примере показано, что окончательное подтверждение посылается в сообщении ZLB ACK. Альтернативой может быть подтверждение, пришедшее в сообщении, посланном в ответ на ICRQ или OCRQ, которые направляются стороной, инициировавшей формирование туннеля.

LAC или LNSLNS или LAC

SCCRQ ->

Nr: 0, Ns: 0

Nr: 1, Ns: 0

SCCCN ->

Nr: 1, Ns: 1

  Nr: 2, Ns: 1



Б Сообщения управления NTP


В сетевой среде должны быть средства управления программами NTP, такие как установка индикатора добавления секунды (Leap-Indicator) со стороны первичного сервера, настройка различных системных параметров и процедур мониторинга. Такие операции могут быть реализованы с привлечением протокола snmp и соответствующего расширения базы данных MIB. Однако в тех случаях, когда такие средства недоступны, эти функции могут быть реализованы с помощью специальных управляющих NTP-сообщений.

Управляющие сообщения NTP имеют код 6 в поле режима первого октета NTP-заголовка. Формат поля данных специфичен для каждой из команд или отклика. Однако, в большинстве случаев формат конструируется так, чтобы облегчить его непосредственное чтение. Как правило, он состоит из ASCII-строк. Если используется аутентификатор, поле данных дополняется нулями до границы, кратной целому числу 32-битных слов.

IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 октетов; однако, некоторые команды или отклики могут содержать данные, непомещающиеся в одну дейтограмму. Для решения данной проблемы все октеты сообщения нумеруются, начиная с нуля. При передаче фрагментов сообщения номер первого октета записывается в поле смещения (offset), а число октетов в поле длины. Бит (M - more) устанавливается во всех фрагментах за исключением последнего.

Большинство контрольных функций включает посылку команды и получение отклика. Отправитель выбирает ненулевой порядковый номер и устанавливает статусное поле и биты R и E равными нулю. Получатель интерпретирует код операции и дополнительную информацию, содержащуюся в поле данных, вносит изменение в поле статуса и устанавливает бит R=1, а также возвращает три 32-битного слова заголовка вместе с другой дополнительной информацией поля данных. В случае неверного формата сообщения или ошибки в поле данных получатель заносит соответствующий код в поле статуса, устанавливает биты R и E равными 1, и опционно записывает диагностическое сообщение в поле данных.

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

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



C UDP-инкапсуляция


Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы.

Базовая схема UDP-инкапсуляции использует два предположения:

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

Маршрутизаторы первого/последнего узлов должны поддерживать RSVP.

Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов.

Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов.

В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'.

Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'.

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

D является портом назначения (DestAddress) конкретной сессии.

G* является стандартным групповым адресом формата 224.0.0.14, т.е., группа ограничена пределами локальной сети.


Pu и Pu' являются стандартными UDP-портами для UDP-инкапсуляции RSVP, с номерами 1698 и 1699.

Ra равен IP-адресу интерфейса маршрутизатора `a'.

Интерфейс маршрутизатора `a' локально доступен для Hu и Hr.

Таблица 4.4.9.6.1. Правила UDP- инкапсуляции для уникастных сообщений Path и Resv

(D - уникастный адрес места назначения; R - маршрутизатор; Raw - режим произвольных операций сетевого ввода/вывода.)

Узел RSVP посылает RSVP получает
Hu UDP(D/Ra,Pu) [1] UDP(D,Pu) и UDP(D,Pu’) [2]
Hr Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)
RAW()

и UDP(D, Pu) [2]

(игнорировать Pu’)
R (интерфейс а) Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)
RAW()

и UDP(Ra, Pu)

(игнорировать Pu’)
[1] Hu посылает уникастные сообщения Path либо по адресу D, если D является локальным, либо по адресу Ra маршрутизатора первого узла. Ra предполагается известным.
[2] Здесь D является адресом локального интерфейса, через который приходит сообщение.
[3] Это предполагает, что приложение присоединилось к группе D.
Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path

Узел RSVP посылает RSVP получает
Hu UDP(G*,Pu) UDP(D,Pu’) [3] и UDP(G*,Pu)
Hr Raw(D,Tr) и,
если (UDP),

тогда UDP(D, Pu’)
RAW()

и UDP(G*, Pu)

(игнорировать Pu’)
R (интерфейс а) Raw(D,Tr)

и, если (UDP),

тогда UDP(D, Pu’)
RAW()

и UDP(G*, Pu)

(игнорировать Pu’)
Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора.

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


Процесс RSVP, который получает UDP- инкапсулированное сообщение Path или PathTear должен использовать поле Send_TTL общего RSVP-заголовка для извлечения значения TTL. В тех случаях, когда это по каким-либо причинам не приемлемо, значение TTL может быть задано вручную при конфигурации.

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

Hu может запускать как уникастные, так и мультикастные сессии в UDP(Ra,Pu) с TTL=Ta. Здесь Ta должно быть достаточным, чтобы достичь R. Если Ta слишком мало, сообщение Path не дойдет до R. Если Ta слишком велико, R и последующие маршрутизаторы могут переправлять UDP-пакет до тех пор, пока не иссякнет запас по TTL. Это включит UDP-инкапсуляцию между маршрутизаторами в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Hu должна быть непосредственно сконфигурирована с использованием Ra и Ta.

Конкретная ЭВМ локальной сети, соединенная с Hu может считаться “транспортной ЭВМ RSVP". Транспортная ЭВМ будет прослушивать (G*,Pu) и переправлять любое сообщение Path непосредственно R, хотя это и не будет маршрутом передачи данных. Транспортная ЭВМ должна быть сконфигурирована с использованием Ra и Ta.


Г Временная шкала NTP и ее хронометрия


Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени.

Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны.



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


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

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

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

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

Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77].



Последующее является записью для соединения


Последующее является записью для соединения IMAP 4.1. (Данный пример и нижеприведенное описание синтаксиса практически без изменения взято из документа RFC-2060).

S: * OK IMAP4rev1 Service Ready

C: a001 login mrc secret

S: a001 OK LOGIN completed

C: a002 select inbox

S: * 18 EXISTS

S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

S: * 2 RECENT

S: * OK [UNSEEN 17] Message 17 is the first unseen message

S: * OK [UIDVALIDITY 3857529045] UIDs valid

S: a002 OK [READ-WRITE] SELECT completed

C: a003 fetch 12 full

S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"

RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"

"IMAP4rev1 WG mtg summary and minutes"

(("Terry Gray" NIL "gray" "cac.washington.edu"))

(("Terry Gray" NIL "gray" "cac.washington.edu"))

(("Terry Gray" NIL "gray" "cac.washington.edu"))

((NIL NIL "imap" "cac.washington.edu"))

((NIL NIL "minutes" "CNRI.Reston.VA.US")

("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL

"")

BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))

S: a003 OK FETCH completed

C: a004 fetch 12 body[header]

S: * 12 FETCH (BODY[HEADER] {350}

S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)

S: From: Terry Gray gray@cac.washington.edu

S: Subject: IMAP4rev1 WG mtg summary and minutes

S: To: imap@cac.washington.edu

S: cc: minutes@CNRI.Reston.VA.US, John Klensin KLENSIN@INFOODS.MIT.EDU

S: Message-Id: B27397-0100000@cac.washington.edu

S: MIME-Version: 1.0

S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

S:

S: )

S: a004 OK FETCH completed

C: a005 store 12 +flags \deleted

S: * 12 FETCH (FLAGS (\Seen \Deleted))

S: a005 OK +FLAGS completed

C: a006 logout

S: * BYE IMAP4rev1 server terminating connection

S: a006 OK LOGOUT completed


Примеры уникастных адресов


Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы MAC адреса, может служить:

Рис. 4.4.1.1.3

Где 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 mac адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса не доступны, могут использоваться другие типы адресов связного уровня, такие как E.164 адреса, в качестве идентификаторов интерфейсов.

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

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

Рис. 4.4.1.1.4

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



Приоритет


4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.

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

Таблица 4.4.1.1.2. Значения кодов приоритета

Код приоритета Назначение
0 Нехарактеризованный трафик
1 Заполняющий трафик (например, сетевые новости)
2 Несущественный информационный трафик (например, электронная почта)
3 Резерв
4 Существенный трафик (напр., FTP, HTTP, NFS)
5 Резерв
6 Интерактивный трафик (напр. telnet, x)
7 Управляющий трафик Интернет (напр., маршрутные протоколы, snmp)

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

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



Процедура часовой фильтр (clock-filter)


Процедура часовой фильтр исполняется по прибытии сообщения NTP или другого события, в результате которого получены новые данные. Она использует аргументы (q, d, e), где q - результат измерения смещения часов, содержащийся в записи, а d и e соответственно RTT и дисперсия. Процедура определяет значение отфильтрованного смещения часов (filtered clock offset - peer.offset), RTT (peer.delay) и дисперсии (peer.dispersion). Она также корректирует дисперсию хранящихся записей и текущее показание часов (peer.update).

Процедура часового фильтра использует сдвиговый регистр (peer.filter), который состоит из NTP.SHIFT каскадов, каждый каскад содержит значения qi, di и e i, которые пронумерованы, начиная с нуля, слева направо. Фильтр инициализируется процедурой очистки при этом заносятся значения [0, 0, NTP.MAXDISPERSE] во всех каскадах. Новые данные записей вдвигаются в фильтр с левого конца. Пакетная процедура выдает записи в формате (q ,d, e), когда приходят новые корректирующие данные, в то время как процедура передачи выдает записи в форме [0, 0, NTP.MAXDISPERSE], когда истекает два периода запроса без поступления свежих данных. Когда одни и те же символы (q, d, e) используютсядля аргументов, содержимого часового фильтра и переменных партнера, их значения обычно понятно из контекста. Ниже представлена псевдопрограмма, поясняющая работу данной процедуры.

begin clock-filter procedure (q, d, e)

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

for (i from ntp.size 1 to 1) begin /* коррекция дисперсии */

[qi, di, ei] q{i-1}, d{i-1}, e{i-1}];



/* shift stage right */

ei = ei + ft;

add [li ? ei + {|di|}/2, i] to temporary list;

endfor;

[q0, d0, e0] q, d, e]; /* ввести новую запись */
add [l ? e + {|d|}/2, 0] to temporary list;

peer.update

/* сбросить показание часов */
sort temporary list by increasing [distance index];

где [distance index] представляет собой объединение полей расстояния и индекса (расстояние занимает старшую позицию). Дисперсия фильтра es вычисляется и включается в дисперсию партнера. Заметим, что временный список для этой цели уже упорядочен.

es

for (i from ntp.shift-1 to 0) /* вычисление дисперсии фильтра */
if (peer.dispersionindex[i] ? NTP.MAXDISPERSE or |qi

- q0 > NTP.MAXDISPERSE)

es es + NTP.MAXDISPERSE) * NTP.FILTER;

else

es es + |qi

- q0|) * NTP.FILTER;

Смещение партнера q0, задержка d0 и дисперсия e0 выбираются как величины, соответствующие записи с минимальным расстоянием; другими словами, записи, соответствующей первому элементу временного списка (в данной нотации имеет индекс 0).

peer.offset q0; /* корректировка переменных партнера */
peer.delay d0;

peer.dispersion e0 + es, NTP.MAXDISPERSE);

end clock-filter procedure

Переменные peer.offset и peer.delay представляют смещение шкалы часов и RTT для локальных часов, измеренные относительно часов партнера. Обе они усредняются по большому числу измерений в течение длительного периода времени. Переменная peer.dispersion характеризует максимальную ошибку из-за неточности измерений, дрейфа и вариации записей. Все три переменные используются при выборе часов для синхронизации.


Процедура initialization-instantiation


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

begin initialization-instantiation procedure

peer.config

#ifdef (authentication implemented)

peer.authenable

peer.authentic

peer.hostkeyid

peer.peerkeyid

#endef;

peer.peeraddr

/* копирование переменных */

peer.peerport

peer.hostaddr

peer.hostport

peer.mode

peer.peerpoll

peer.timer

peer.delay

peer.offset

call clear; /* инициализация ассоциации */

end initialization-instantiation procedure;



Процедура коррекции показаний часов


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

begin clock-update procedure

call clock-select; /* Выбор базовых часов */

if (sys.peer ? peer) exit;

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

Процедура расстояния вычисляет базовую (root) задержку d, базовую дисперсию e и базовое расстояние синхронизации l. ЭВМ не будет синхронизовать выбранного партнера, если расстояние больше чем ntp.maxdistance.

l andistance(peer); /* обновление системных переменных */

if (l ? ntp.maxdistance) exit;

sys.leap

sys.stratum

sys.refid

call local-clock;

if (local clock reset) begin /* если сброс, очистить системные переменные */

sys.leap 2;

for (all peers) call clear;

endif

else begin

sys.peer

/* если нет, то подстроить локальные часы */

sys.rootdelay d;

sys.rootdispersion e + max (ex

+ |t|, ntp.mindisperse);

endif

sys.reftime

end clock-update procedure;

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

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



Процедура очистки


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

begin clear procedure

peer.org

/* пометка неопределенных временных меток */

peer.rec

peer.xmt

peer.reach

/* сброс переменных состояния */
peer.filter

/* все ступени */

peer.valid

peer.dispersion

{peer.hostpoll

/* первичная установка периода рассылки */

call poll-update;

call clock-select; /* Выбор эталонных часов */

end clear procedure;



Процедура передачи


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

Нижеприведенный фрагмент программы инициализирует пакетный буфер и копирует пакетные переменные.

pkt.peeraddr

/* копирование системных и партнерских переменных */

pkt.peerport

pkt.hostaddr

pkt.hostport

pkt.leap

pkt.version

pkt.mode

pkt.stratum

pkt.poll

pkt.precision

pkt.rootdelay

if (sys.leap = 112 or (sys.clock - sys.reftime) > ntp.maxage)

skew

else

skew j (sys.clock - sys.reftime);

{pkt.rootdispersion

pkt.refid

pkt.reftime

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

pkt.org

/* копирование временных меток */

pkt.rec

pkt.xmt

peer.xmt

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

peer.reach

/* актуализация доступности */

if (peer.reach = 0 and peer.config =0)

begin

ликвидируем ассоциацию;

exit;

endif

Если корректные данные введены в сдвиговый регистр фильтра хотя бы раз за время предыдущих двух периодов рассылки (младший бит peer.reach равен 1), счетчик корректных данных увеличивается на 1. После восьми таких удачных периодов интервал рассылки увеличивается. Процедура выбора часов вызывается, если необходимо заменить источник синхронизации.

if (peer.reach & 6 ? 0) /* Проверка младших двух бит */
if (peer.valid << ntp.shift) /* получены корректные данные */

peer.valid <- peer.valid + 1;

else peer.hostpoll <- peer.hostpoll + 1;

else begin

peer.valid

/* ничего не слышно */

peer.hostpoll

call clock-filter(0, 0, ntp.maxdisperse);

call clock-select; /* выбираем источник синхронизации */

endif

call poll-update;

end transmit procedure;



Процедура получения


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

begin receive procedure

if (pkt.version ? ntp.version>) exit;

#ifdef (control messages implemented)

if (pkt.mode = 6) call control-message;

#endef

for (all associations) /* Здесь выполняется управление доступом */

match addresses and ports to associations;

if (no matching association)

call receive-instantiation procedure; /* создаем ассоциацию */

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

#ifdef (authentication implemented)

call decrypt;

#endef

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

if (pkt.mode = 0) /* для совместимости со старыми версиями */

mode;

else

mode

case (mode, peer.hostmode)

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

error: if (peer.config = 0) demobilize association;

break;

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

recv: call packet; /* обработать пакет */
if (valid header) begin /* если правильный заголовок, актуализовать внутренние часы */
<
peer.reach

if (valid data) call clock-update;

endif

else

if (peer.config = 0) ликвидировать ассоциацию;

break;

В случае xmit, пакет обрабатывается и посылается промежуточный отклик. Ассоциация затем ликвидируется.

xmit: call packet; /* обработать пакет */
peer.hostpoll

/* послать немедленно отклик */
call poll-update;

call transmit;

if (peer.config = 0) ликвидировать ассоциацию;

break;

В случае pkt, пакет обрабатывается, а ассоциация помечается как достижимая при условии, что тесты 5-8 (правильный заголовок), перечисленные в пакетной процедуре, прошли успешно. Если, кроме того, прошли тесты 1-4 (корректные данные), вызывается процедура коррекции показаний локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она сразу после отклика ликвидируется.

pkt: call packet; /* обработка пакета */
if (valid header) begin /* если заголовок правилен, поправляется показание местных часов */
.reach

if (valid data) call clock-update;

endif

else if (peer.config = 0) begin

peer.hostpoll

/* послать немедленно отклик */
poll-update;

call transmit;

ликвидировать ассоциацию;

endif

endcase

end receive procedure;


Процедура primary clock-instantiation


Эта процедура вызывается из процедуры инициализации для того, чтобы установить переменные состояния для первичных часов. Значение peer.precision определяется из спецификации радио-часов и аппаратного интерфейса. Значение peer.rootdispersion номинально равно удесятеренной максимальной ошибке радио-часов, например, 10 мсек для WWVB или радио-часов goes и 100 мсек для менее точных радио-часов WWV.

begin clock-instantiation procedure

peer.config

/* копирование переменных */

peer.peeraddr

peer.peerport

peer.hostaddr

peer.hostport

peer.leap 2;

peer.mode

peer.stratum

peer.peerpoll

peer.precision

peer.rootdelay

peer.rootdispersion

peer.refid

peer.reftime

peer.timer

peer.delay

peer.offset

call clear; /* инициализация ассоциации */

end clock-instantiation procedure;

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



Процедура расстояния синхронизации (synchronization distance)


Процедура расстояния вычисляет расстояние синхронизации на основе переменных партнеров.

begin distance(peer) procedure;

d

e f (sys.clock - peer.update)};

le + |d|/2;

end distance procedure;

Заметим, что, в то время как d может быть в некоторых случаях отрицательной, e и l всегда положительны.



Процедура receive-instantiation


Процедура receive-instantiation вызывается процедурой приема, когда обнаруживается новый партнер. Она инициализирует переменные партнера и формирует ассоциацию. Если сообщение получено от партнера, работающего в режиме клиента (3), ЭВМ переводится в режим сервера (4); в противном случае, она устанавливается в симметрично пассивный режим (2).

begin receive-instantiation procedure

#ifdef (authentication implemented)

peer.authenable

peer.authentic

peer.hostkeyid

peer.peerkeyid

#endef

peer.config

/* Копирование переменных */

peer.peeraddr

peer.peerport

peer.hostaddr

peer.hostport

if (pkt.mode = 3) /* Определение режима */

peer.mode

else

peer.mode

peer.peerpoll

peer.timer

peer.delay

peer.offset

call clear; /* инициализация ассоциации */

end receive-instantiation procedure;



Процедура выбора часов


Процедура выбора часов использует переменные партнера q, d, e и t, она вызывается, когда эти переменные изменились или изменился статус доступности. Процедура включает в себя две составные части: алгоритм пересечения (intersection algorithm) и алгоритм кластеризации (clustering algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них. Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния синхронизации. Системная переменная sys.peer представляет собой указатель на наиболее вероятного кандидата, если таковой имеется, или на нулевую величину в противном случае.