Справочник по сетевым протоколам

PPPS

АТМ Bridge Frame Relay HDLC

Протокол PPP (Point-to-Point Protocol)

ОГЛАВЛЕНИЕ

	1. Введение
	2. Общее описание протокола PPP
	3. Инкапсуляция PPP
	3.1. Принцип инкапсуляции
	3.2. Формат кадра РРР при инкапсуляции
	4. Функционирование звена PPP
	4.1. Краткий обзор
	4.2. Диаграмма стадий PPP
	4.3. Стадия "Выключено"
	4.4. Стадия "Установление связи"
	4.5. Стадия "Аутентификация"
	4.6. Стадия "Протокол сетевого уровня"
	4.7. Стадия "Завершение связи"
	5. Автомат согласования опций
	5.1. Таблица переходов состояний
	5.2. Состояния
	5.3. События
	5.4. Действия
	5.5. Предотвращение зацикливания
	5.6. Счетчики и таймеры
	6. Форматы пакетов LCP
	6.1. Формат пакетов LCP "Запрос конфигурации"
	6.2. Формат пакетов LCP "Подтверждение конфигурации"
	6.3. Формат пакетов LCP "Неподтверждение конфигурации"
	6.4. Формат пакетов LCP "Сброс конфигурации"
	6.5. Формат пакетов LCP "Запрос разъединения" и "Подтверждение разъединения"
	6.6. Формат пакетов LCP "Сброс кода"
	6.7. Формат пакетов LCP "Сброс протокола"
	6.8. Формат пакетов LCP "Запрос эха" и "Ответ эха"
	6.9. Формат пакетов LCP "Запрос сброса"
	7. Опции конфигурации LCP
	7.1. Максимальный размер принимаемого блока
	7.2. Протокол аутентификации
	7.3. Протокол качества
	7.4. Мagic-номера
	7.5. Сжатие поля протокола
	7.6. Сжатие полей адреса и управления
	Список литературы
	Список используемых сокращений и терминов

1. Введение

С конца 1980-х годов в сети Internet наблюдается резкий рост числа главных вычислительных машин (ГВМ или хостов), работающих с протоколами TCP/IP. Их преобладающее большинство было подключено к локальным вычислительным сетям различных типов, наиболее популярной среди которых была сеть Ethernet. Большая часть других хостов соединялась через глобальные сети, такие как сети передачи данных общего пользования типа Х.25. Сравнительно небольшое число ГВМ было подключено к каналам связи с непосредственным соединением точка-точка (т.е.

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

Одной из причин малого числа каналов связи TCP/IP с непосредственным соединением было отсутствие стандартного протокола нижележащего уровня для передачи дейтаграмм через последовательные линии связи. Для разрешения этой проблемы и был разработан протокол PPP (Point-to-Point Protocol - протокол канала связи с непосредственным соединением). Помимо решения задачи формирования стандартных пакетов данных IP для каналов с непосредственным соединением, РРР также должен был решить другие проблемы, в том числе присвоение и управление адресами IP, асинхронное (старт-стопное) и синхронное (бит-ориентированное) формирование пакета данных, конфигурацию канала связи, проверку его качества, обнаружение ошибок, согласование способа сжатия информации и т.д. В РРР эти вопросы решаются путем использования протокола управления каналом LCP (Link Control Protocol) и семейства протоколов управления сетью NCP (Network Control Protocols), которые позволяют согласовывать необязательные параметры конфигурации и различные возможности. Сегодня PPP, помимо IP, обеспечивает поддержку также и других протоколов, в том числе IPX и DECnet.

2. Общее описание протокола PPP

Компоненты PPP

РРР обеспечивает метод передачи дейтаграмм через последовательные каналы связи с непосредственным соединением типа "точка-точка" (point-to-point). Он включает три основных компонента:

	Метод инкапсуляции (метод формирования дейтаграмм для передачи по последовательным каналам). РРР в качестве базиса для формирования дейтаграмм при прохождении через каналы с непосредственным соединением использует кадры, подобные кадрам процедуры HDLC (High-level Data Link Control - управление каналом передачи данных высокого уровня).
	Расширяемый протокол контроля канала LCP (Link Control Protocol). LCP предназначен для организации, выбора конфигурации и проверки соединения канала передачи данных.
	Семейство протоколов контроля сети NCP (Network Control Protocols). Служит для организации и выбора конфигурации различных протоколов сетевого уровня.

<

/p>

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

Основные принципы работы

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

Требования, определяемые физическим уровнем

РРР может работать через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA RS-423 и МСЭ-Т V.35). Единственным абсолютным требованием, которое предъявляет РРР, является требование обеспечения дублированных схем (либо специально назначенных, либо переключаемых), которые могут работать как в синхронном, так и в асинхронном последовательном режиме, прозрачном для блоков данных канального уровня РРР. Протокол РРР не предъявляет каких-либо ограничений, касающихся скорости передачи информации, кроме тех, которые определяются используемым интерфейсом DTE/DCE.

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

РРР использует принципы, терминологию и структуру блока данных процедур HDLC (ISO 3309-1979) Международной организации по стандартизации (ISO - International Standards Organization), модифицированных стандартом ISO 3309-1984/PDAD1 "Addendum 1:Start/stop Trasmission" (Приложение 1: Стартстопная передача").

ISO 3309- 1979 определяет структуру блока данных HLDC для применения в синхронных окружениях. ISO 3309-1984/PDAD1 определяет предложенные для стандарта ISO 3309-1979 модификации, которые позволяют его использование в асинхронных окружениях. Процедуры управления РРР используют определение и кодирование управляющих полей, стандартизированных ISO 4335-1979 и ISO 4335-1979/Addendum 1-1979.

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

Инкапсуляция

Инкапсуляция PPP обеспечивает мультиплексирование различных протоколов сетевого уровня одновременно в одном и том же канале (звене передачи данных - ЗПД). Метод инкапсуляции PPP разработан для сохранения совместимости с наиболее часто используемыми аппаратными средствами поддержки.

Для проведения инкапсуляции при использовании по умолчанию кадров, подобных кадрам HDLC, необходимы только 8 дополнительных октетов. В системах, где требуется повышенная пропускная способность, для инкапсуляция и формирования кадров выделяются лишь 2 или 4 октета.

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

Протокол контроля канала LCP

Протокол PPP для достаточной универсальности и применимости к широкому разнообразию систем включает протокол контроля канала LCP (Link Control Protocol). LCP используется, чтобы автоматически согласовывать опции формата инкапсуляции, изменять пределы размеров пакетов, обнаруживать зацикливание звена и другие ошибочные ситуации, связанные с различиями конфигураций, и разрывать связь.

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

Процесс LCD проходит через четыре четко различаемые фазы:

	Организация канала и согласование его конфигурации. Прежде, чем может быть произведен обмен какими-либо дейтаграммами сетевого уровня (например, IP), LCP сначала должен открыть связь и согласовать параметры конфигурации. Эта фаза завершается после того, как будет отправлен и принят пакет подтверждения конфигурации.
	Определение качества канала связи. LCP обеспечивает необязательную фазу определения качества канала, которая следует за фазой организации канала и согласования его конфигурации. В этой фазе проверяется канал с целью выяснения, является ли качество канала достаточным для вызова протоколов сетевого уровня. Эта фаза является полностью факультативной. LСP может задержать передачу информации протоколов сетевого уровня до завершения этой фазы.
	Согласование конфигурации протоколов сетевого уровня. После того, как LСP завершит фазу определения качества канала связи, соответствующими NCP может быть выбрана конфигурация сетевых протоколов, и они могут быть в любой момент вызваны и освобождены для последующего использования. Если LCP закрывает данный канал, он информирует об этом протоколы сетевого уровня, чтобы они могли принять соответствующие меры.
	Прекращение действия канала. LCP может в любой момент закрыть канал. Это обычно делается по запросу пользователя, но может произойти также из-за какого-нибудь физического события, такого, как потеря носителя или истечение периода бездействия таймера.

Существует три класса пакетов LCP:

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

<

/p>

Эти пакеты используются для достижения работоспособности каждой из фаз LCP.

Протоколы контроля сети (NCPs)

Каналы РРР имеют много проблем с используемым семейством сетевых протоколов. Например, назначение и управление адресов IP, которые являются проблемой даже в ЛВС, являются особенно трудными для коммутируемых каналов точка-точка (point-to-point). Эти проблемы решаются семейством протоколов контроля сети (NCPs - Network Control Protocols), каждый из которых отвечает за определенные функции, требуемые соответствующими протоколами сетевого уровня.

Конфигурация

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

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

3. Инкапсуляция PPP

3.1. Принцип инкапсуляции

Инкапсуляция PPP используется для прозрачной передачи дейтаграмм различных протоколов. Она требует указаний на начало и конец инкапсуляции.

В соответствии с RFC 1661 [1] протокольный блок данных PPP имеет следующий вид (где поле "Информация" - содержит данные, инкапсулируемые в РРР). Поля передаются слева направо.

Протокол

(8/16 бит)

Информация

Дополнение

Рассмотрим особенности использования данных полей подробнее.

Поле "Протокол"

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

Наиболее значащие октеты поля передаются первыми.

Структура этого поля соответствует механизму расширения стандарта ISO 3309 для полей адреса. Все значения поля "Протокол" должны быть нечетными; наименее значащий бит наименее значащего октета должен равняться "1". Кроме того наименее значащий бит наиболее значащего октета должен равняется нулю.

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

Значения полей "Протокол" в диапазоне от 0*** до 3*** идентифицируют протокол сетевого уровня специальных пакетов, а значения от 8*** до b*** идентифицируют пакеты, принадлежащие соответствующим протоколам контроля сети (NCPs), если таковые имеются в наличии.

Значения полей "Протокол" в диапазоне от 4*** до 7*** используются для протоколов с низким объемом трафика, которые не соответствуют NCP. Значения полей "Протокол" в диапазоне от c*** до f*** идентифицируют пакеты протоколов уровня ЗПД (таких, как LCP).

Значения поля "Протокол" определяются в последнем издании "Assigned Numbers RFC" [3]. В настоящее время эта спецификация определяет следующие значения:

Значение (в 16-ричном виде)	Наименование протокола
0001	Протокол дополнения
0003..001f	Резерв
007d	Резерв
00cf	Резерв
00ff	Резерв
8001..801f	Не используется
807d	Не используется
80cf	Не используется
80ff	Не используется
C021	Протокол LCP
C023	Протокол аутентификации пароля
C025	Сообщение о качестве связи
C223	Отклик протокола аутентификации в режиме подтверждения

Разработчики новых протоколов должны получить номер для разрабатываемого ими протокола в Отделе назначения номеров Internet (IANA - Internet Assigned Numbers Authority), по адресу IANA@isi.edu.

Поле "Информация"

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

Максимальная длина поля "Информация", включая поле "Дополнение", но не включая поле "Протокол", называется максимальным размером блока (MRU - Maximum Receive Unit), который не должен превышать 1500 октетов. Приложения PPP путем согласования могут использовать другие значения MRU.

Поле "Дополнение"

Поле "Информация" при передаче может дополняться произвольным числом октетов, вплоть до значения MRU. Каждый протокол должен иметь возможность отличать дополнительные октеты от реальной информации.

3.2. Формат кадра РРР при инкапсуляции

Ниже приведен пример формата кадра РРР при инкапсуляции.

Длина поля в байтах: 1	1	1	2/1	Переменная	2 или 4
Флаг	Адрес	Управление	Протокол	Данные	FCS

Рассмотрим назначение указанных полей.

Последовательность "Флаг"

Длина последовательности "Флаг" равна одному байту; она указывает на начало или конец блока данных. Эта последовательность имеет вид: 01111110.

Поле "Адрес"

Длина поля "Адрес" равна 1 байту; поле содержит двоичную последовательность 11111111, представляющую собой стандартный широковещательный адрес. РРР не присваивает индивидуальных адресов станциям.

Поле "Управление"

Поле "Управление" составляет 1 байт и содержит двоичную последовательность 00000011, которая требует от пользователя передачи информации непоследовательным кадром. Предусмотрены услуги без установления соединения канала связи, аналогичные услугам LLC Type 1.

Поле "Протокол"

Длина поля "Протокол" равна 2 байтам (или 1 байту); его значение идентифицирует протокол, заключенный в информационном поле блока данных. Большинство современных значений поля "Протокол" определены в последнем выпуске Assigned Numbers Request for Comments (RFC).

Поле "Данные"

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

Конец информационного поля определяется локализацией замыкающей последовательности "флаг" и предоставлением двух байтов полю FCS. Максимальная длина информационного поля по умолчанию равна 1500 байтам. В соответствии с априорным соглашением, реализации РРР могут использовать другие значения максимальной длины информационного поля.

Поле FCS

Поле проверочной последовательности блока данных (FCS - frame check sequence) обычно составляет 16 бит (два байта). В соответствии с априорным соглашением реализации РРР могут использовать 32-х битовое (четырехбайтовое) поле FCS, чтобы улучшить процесс выявления ошибок.

4. Функционирование звена PPP

4.1. Краткий обзор

Чтобы установить соединение по каналу типа "точка-точка", каждое окончание канала PPP должно сначала послать пакеты LCP, чтобы сконфигурировать и протестировать канал данных. После того, как связь установлена, одноранговый объект может быть подвергнут аутентификации.

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

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

4.2. Диаграмма стадий PPP

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

Основные характеристики данных стадий подробнее рассмотрены ниже.

4.3. Стадия "Выключено"

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

В течении этой стадии автомат LCP (рассматривается ниже) находится в состояниях "Начальное" или "Старт". Переход к стадии "Установление связи" выполняется по сигналу "Включение" автомату LCP.

Примечание:

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

4.4. Стадия "Установление связи"

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

Важно заметить, что с использованием LCP конфигурируются только те опции конфигурации, которые являются независимыми от специфических протоколов сетевого уровня. Конфигурация индивидуальных протоколов сетевого уровня выполняется в соответствии c отдельными протоколами контроля сети (NCPs) в течение стадии "Протокол сетевого уровня".

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

Получение запроса конфигурации LCP вызывает переход из стадий "Протокол сетевого уровня" или "Аутентификация" к стадии "Установление связи".

4.5. Стадия "Аутентификация"

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

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

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

Переход от стадии "Аутентификация" к стадии "Протокол сетевого уровня" не должен наступать до завершения аутентификации. Если установление подлинности не выполнено, то должен произойти переход к стадии "Завершение связи".

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

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

Приложение, которое не признало подлинность однорангового объекта, инициирует стадию "Завершение связи".

4.6. Стадия "Протокол сетевого уровня"

Когда PPP завершает предыдущие стадии, каждый протокол сетевого уровня (такой как IP, IPX или AppleTalk) должен быть индивидуально сконфигурирован согласно соответствующему протоколу контроля сети (NCP). Каждый NCP может быть открыт и закрыт в любое время.

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

Примечание:

Когда LCP находится в состоянии "Открыто", любой пакет протокола, который не поддерживается приложением, должен быть указан в пакете сброса протокола (Protocol-Reject), описанном ниже.

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

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

4.7. Стадия "Завершение связи"

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

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

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

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

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

5. Автомат согласования опций

Для согласования параметров канала связи в протоколе РРР предусмотрено использования специального автомата с конечным числом состояний. Переходы из одного состояния в другое определяются событиями и действиями. События состоят в поступлении внешних команд, таких как "Открыть" и "Закрыть", истечение таймера перезапуска и прием пакетов от однорангового объекта.

Действия включают старт таймера перезапуска и передачу пакетов одноранговому объекту.

Некоторые типы пакетов: "Неподтверждение конфигурации" (Configure-Naks) и "Сброс конфигурации" (Configure-Rejects) или "Сброс кода" (Code-Rejects) и "Сброс протокола" (Protocol-Rejects) или "Запрос эха" (Echo-Requests), "Ответ эха" (Echo-Replies) и "Запрос сброса" (Discard-Requests) - не дифференцируются в описании автомата. Как будет показано ниже, эти пакеты выполняют различные функции, но они всегда вызывают одни и те же переходы.

События:	Действия:
Up = включение нижнего уровня	tlu = этот уровень включается
Down = выключение нижнего уровня	tld = этот уровень выключается
Open = административное открытие	tls = этот уровень начинается
Close= административное закрытие	tlf = этот уровень завершается
TO+ = таймаут со счетчиком > 0	irc = счетчик перезапуска инициализируется
TO- = таймаут с истекшим счетчиком	zrc = счетчик перезапуска обнуляется
RCR+ = принят запрос конфигурации (удовлетворительный)	scr = посылается запрос конфигурации
RCR- = принят запрос конфигурации (неудовлетворительный)
RCA = принято подтверждение конфигурации	sca = посылается подтверждение конфигурации
RCN = принято неподтверждение/сброс конфигурации	scn = посылается неподтверждение/сброс конфигурации
RTR = принят запрос разъединения	str = посылается запрос разъединения
RTA = принято подтверждение разъединения	sta = посылается подтверждение разъединения
RUC = принят нераспознанный код	scj = посылается сброс кода
RXJ+ = принят сброс кода (разрешаемый) или сброс протокола
RXJ- = принят сброс кода (аварийный) или сброс протокола
RXR = принят запрос эха или ответ эха или запрос сброса	ser = посылается ответ эха

5.1. Таблица переходов состояний

Ниже представлена полная таблица переходов состояний. Состояния указаны по горизонтали, а события - по вертикали.

Переходы состояний и действия представлены в форме действие/ новое состояние. Многократные действия отделяются запятыми и могут осуществляться в любом порядке. Состояние может помечаться буквой p, r или x, где:

p - пассивная опция (см. состояние "Стоп");

r - опция рестарта (см. событие "Открытие");

x - перекрестное соединение (см. событие RCA).

Дефис ( "- ") указывает на отсутствие перехода.

	Состояния
События	0. Начальное	1. Старт	2. Закрыто	3. Стоп	4. Закрытие	5. Остановка
Up	2	irc, scr/6	-	-	-	-
Down	-	-	0	tls/1	0	1
Open	tls/1	1	irc, scr/6	3r	5r	5r
Close	0	tlf/0	2	2	4	4
TO+	-	-	-	-	str/4	str/5
TO-	-	-	-	-	tlf/2	tlf/3
RCR+	-	-	sta/2	irc, scr, sca/8	4	5
RCR-	-	-	sta/2	irc, scr, scn/6	4	5
RCA	-	-	sta/2	sta/3	4	5
RCN	-	-	sta/2	sta/3	4	5
RTR	-	-	sta/2	sta/3	sta/4	sta/5
RTA	-	-	2	3	tlf/2	tlf/3
RUC	-	-	scj/2	scj/3	scj/4	scj/5
RXJ+	-	-	2	3	4	5
RXJ-	-	-	tlf/2	tlf/3	tlf/2	tlf/3
RXR	-	-	2	3	4	5

	Состояния
События	6. Послан запрос	7. Принято подтверждение	8. Послано подтверждение	9. Открыто
Up	-	-	-	-
Down	1	1	1	tld/1
Open	6	7	8	9r
Close	irc, str/4	irc, str/4	irc, str/4	tld, irc, str/4
TO+	scr/6	scr/6	scr/8	-
TO-	tlf/3p	tlf/3p	tlf/3p	-
RCR+	sca/8	sca, tlu/9	sca/8	tld, scr, sca/8
RCR-	scn/6	scn/7	scn/6	tld, scr, scn/6
RCA	irc/7	scr/6x	irc, tlu/9	tld, scr/6x
RCN	irc, scr/6	scr/6x	irc, scr/8	tld, scr/6x
RTR	sta/6	sta/6	sta/6	tld, zrc, sta/5
RTA	6	6	8	tld, zrc, sta/5
RUC	scj/6	scj/7	scj/8	scj/9
RXJ+	6	6	8	9
RXJ-	tlf/3	tlf/3	tlf/3	tld, irc, str/5
RXR	6	7	9	ser/9

Состояния, в которых работает таймер рестарта, идентифицируются присутствием событий TO. Действия scr (посылается запрос конфигурации), str (посылается запрос разъединения) и zrc (счетчик перезапуска обнуляется) запускают или перезапускают таймер рестарта.

При переходе от любого состояния, где таймер работает, к состоянию, где таймер не работает, таймер рестарта останавливается.

5.2. Состояния

Рассмотрим каждое состояние автомата более подробно.

Начальное

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

Старт

Состояние "Старт" - стыкуется с состоянием "Начальное". Административное событие "Открытие" было инициировано, но нижележащий уровень все еще недоступен (выключен). Таймер рестарта в состоянии "Старт" не работает.

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

Закрыто

В состоянии "Закрыто" связь доступна (включена), но события "Открытие" не произошло. Таймер рестарта в состоянии "Закрыто" не работает.

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

Стоп

Состояние "Стоп" стыкуется с состоянием "Закрыто". Оно наступает, когда автомат ждет события "Выключение" после действия tlf ("этот уровень завершается") или после посылки подтверждения разъединения. Таймер рестарта в состоянии "Стоп" не работает.

На прием пакетов "Запрос выбора конфигурации" посылается соответствующий ответ. На прием других пакетов посылается подтверждение разъединения. Пакеты "Подтверждение разъединения" сбрасываются без уведомления во избежание зацикливания.

Пояснение:

"Стоп" - состояние перехода при завершении связи, неполадках конфигурации связи и других режимах отказа автомата. Эти потенциально отдельные состояния были объединены.

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

Это предотвращает размножение копий.

Опции приложения:

Если одноранговый объект не в состоянии ответить на запрос конфигурации, то приложение может ждать, пока одноранговый объект не пошлет запрос конфигурации. В этом случае действие tlf ("этот уровень завершается") не используется для событий TO в состояниях "Послан запрос", "Принято подтверждение" и "Послано подтверждение".

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

Закрытие

В состоянии "Закрытие" делается попытка расторжения связи. Посылается запрос на разъединение, таймер рестарта работает, но подтверждение разъединения еще не получено.

После получения запроса разъединения наступает состояние "Закрыто".

После истечения таймера рестарта посылается новый запрос разъединения, и таймер рестарта запускается заново. После того, как таймер рестарта превысил величину максимального времени разъединения, наступает состояние "Закрыто".

Остановка

Состояние "Остановка" стыкуется с состоянием "Закрытие". Запрос разъединения был послан, таймер рестарта работает, но подтверждение разъединения еще не получено.

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

Запрос послан

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

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

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

Послано подтверждение

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

Открыто

В состоянии "Открыто" подтверждение конфигурации было послано и получено. Таймер рестарта не работает.

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

5.3. События

Переходы и действия в автомате вызываются событиями, рассмотренными ниже.

Включение

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

Оно также может использоваться протоколом LCP для сигнализации NCP о том, что звено вошло в стадию "Протокол сетевого уровня". То есть действие tlu ("этот уровень включается") от протокола LCP вызывает событие "Включение" в NCP.

Выключение

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

Оно также может использоваться протоколом LCP для сигнализации NCP о том, что звено вышло из стадии "Протокол сетевого уровня". То есть действие tld ("этот уровень выключается") от протокола LCP вызывает событие "Выключение" в NCP.

Открытие

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

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

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

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

Опции приложения:

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

Так как это не означает события "Открытие", предлагается, что когда команда пользователя "Открыть" выполняется в состояниях "Открыто", "Закрытие", "Остановка" или "Стоп", приложение запускает событие "Выключение", за которым немедленно следует событие "Включение". Необходимо позаботиться о том, чтобы событие "Выключение" не происходило от другого источника.

Событие "Выключение", за которым немедленно следует событие "Включение", вызывает обычную переустановку связи, переход от состояния "Старт" к состоянию "Послан запрос". Это вызывает переинициализацию связи без каких-либо побочных эффектов.

Закрытие

Этот событие указывает, что связь не доступна для трафика, т.е. администратор сети (человек или программа) указал, что не разрешается открывать связь. Когда происходит это событие, а связь не находится в состоянии "Закрыто", автомат пытается разорвать связь. Дальнейшие попытки переконфигурировать канал отклоняются, пока не происходит новое событие "Открытие".

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

Так как связь административно доступна (по определению), это может быть выполнено путем моделирования протоколом LCP события "Закрытие", за которым немедленно следует событие "Открытие". Необходимо побеспокоиться, чтобы событие "Закрытие" не могло происходить от другого источника.

Событие "Закрытие", сопровождаемое событием "Открытие", вызывает обычное завершение связи, переход от состояния "Закрытие" к состоянию "Остановка", а действие tlf ("этот уровень завершается") может разъединить связь. Автомат ждет в состоянии "Стоп" или "Старт" следующую попытку связи.

Таймаут (ТО +, ТО-)

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

Принят запрос конфигурации, удовлетворительный или неудовлетворительный (RCR+, RCR-)

Это событие происходит, когда от однорангового объекта получен пакет "Запрос конфигурации". Пакет "Запрос конфигурации" указывает на желание открыть связь и может определять опции конфигурации. Формат пакета "Запрос конфигурации" описан в п. 6.1.

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

Принято подтверждение конфигурации (RCA)

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

Так как корректный пакет уже был получен перед достижением состояний "Принято подтверждение" или "Открыто", то чрезвычайно маловероятно, что будет прибывать другой такой пакет. Как определено, все недействительные пакеты подтверждения, неподтверждения, сброса (Ack/Nak/Rej) - сбрасываются без уведомления и не влияют на переходы автомата.

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

Принято неподтверждение/сброс конфигурации (RCN)

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

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

Принят запрос разъединения (RTR)

Это событие происходит, когда получен пакет "Запрос разъединения". Данный пакет указывает на желание однорангового объекта закрыть связь.

Событие "Принят запрос разъединения" не идентично событию "Закрытие" (см. выше) и не делает перенос команды "Открыть" локального администратора сети. Приложение должно быть подготовлено к получению нового запроса конфигурации без вмешательства администратора сети.

Принято подтверждение разъединения (RTA)

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

Принят нераспознанный код (RUC)

Это событие происходит, когда от однорангового объекта получен не интерпретируемый пакет. В ответ посылается пакет "Сброс кода".

Принят сброс кода (разрешаемый или аварийный) или сброс протокола (RXJ +, RXJ-)

Это событие происходит, когда от однорангового объекта получен пакет "Сброс кода" или "Сброс протокола".

Событие RXJ+ наступает, когда отклоненная величина является приемлемой, например, сброс расширенного кода или сброс протокола NCP. Они находятся в пределах нормального действия. Приложение должно прекратить отправку нежелательных пакетов.

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

Принят запрос эха, ответ эха или запрос сброса (RXR)

Это событие происходит, когда от однорангового объекта получен пакет "Запрос эха", "Ответ эха" или "Запрос сброса". Пакет "Ответ эха" - это ответ на пакет "Запрос эха". На пакет "Ответ эха" или "Запрос сброса" никакого ответа не предусмотрено.

5.4. Действия

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

Незаконное событие (-)

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

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

Этот уровень включается (tlu - This-Layer-Up)

Это действие указывает верхним уровням, что автомат входит в состояние "Открыто". Обычно, это действие используется протоколом LCP для сообщения о включении протоколу NCP, протоколу аутентификации (AP - Authentication Protocol) или протоколу качества связи (LQP - Link Quality Protocol) или может использоваться протоколом NCP, чтобы показать, что связь для трафика сетевого уровня доступна.

Этот уровень выключается (tld - This-Layer-Down)

Это действие указывает верхним уровням, что автомат выходит из состояния "Открыто". Обычно, это действие используется протоколом LCP для сигнализации о выключении протоколу NCP, протоколу аутентификации AP или протоколу качества связи LQP или может использоваться протоколом NCP, чтобы показать, что связь для трафика сетевого уровня более не доступна.

Этот уровень начинается (tls - This-Layer-Started)

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

Этот уровень завершается (tlf - This-Layer-Finished)

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

Обычно, это действие может использовать LCP, чтобы перейти к стадии "Выключено" или может использоваться протоколом NCP для указания протоколу LCP, что связь может быть расторгнута, когда нет никакого другого открытого протокола NCP. Результаты этого действия в значительной степени зависят от приложения.

Счетчик перезапуска инициализируется (irc - Initialize-Restart-Count)

Это действие устанавливает счетчик перезапуска в соответствующее значение: максимум разъединения (МТ - Max-Terminate) или максимум конфигурации (МС - Max-Configure). Счетчик декрементируется с каждой передачей, включая первую.

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

Счетчик перезапуска обнуляется (zrc - Zero-Restart-Count)

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

Посылается запрос конфигурации (scr - Send-Configure-Request)

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

Посылается подтверждение конфигурации (sca - Send-Configure-Ack)

Пакет "Запрос конфигурации" передан. Это подтверждает прием пакета "Запрос конфигурации" с приемлемым набором опций конфигурации.

Посылается неподтверждение конфигурации (scn - Send-Configure-Nak)

Передаются пакеты "Неподтверждение конфигурации" или "Сброс конфигурации". Этот отрицательный ответ сообщает о приеме пакета "Запрос конфигурации" с недопустимым набором опций конфигурации.

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

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

Посылается запрос разъединения (str - Send-Terminate-Request)

Пакет "Запрос разъединения" передан. Это указывает на желание закрыть связь. Чтобы предотвратить потери пакетов, когда пакет "Запрос разъединения" передан, запускается таймер рестарта. Счетчик рестарта декрементируется всякий раз, когда посылается запрос разъединения.

Посылается подтверждение разъединения (sta - Send-Terminate-Ack)

Пакет "Подтверждение разъединения" передан. Это подтверждает прием пакета "Запрос разъединения" или служит для синхронизации автоматов.

Посылается сброс кода (scj - Send-Code-Reject)

Пакет "Сброс кода" передан. Это указывает на прием пакета неизвестного типа.

Посылается ответ эха (ser - Send-Echo-Reply)

Пакет "Ответ эха" передан. Это подтверждает прием пакета "Запрос эха".

5.5. Предотвращение зацикливания

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

5.6. Счетчики и таймеры

Таймер рестарта

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

По умолчанию его следует устанавливать на 3 секунды.

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

Вместо постоянной величины, таймер рестарта может начинаться с начальной небольшой величины при увеличении ее до сконфигурированной конечной величины. Начальная величина таймера должна быть достаточно большой, чтобы учесть размер пакетов, двойное время передачи туда и обратно со скоростью канала связи и по крайней мере еще 100 миллисекунд, чтобы позволить одноранговому объекту обработать пакеты перед ответом. Некоторые цепи добавляют еще 200 миллисекунд спутниковой задержки. Время передачи пакета туда и обратно для модемов, работающих в режиме 14,4 кбит/с, находятся в пределах от 160 до более, чем 600 миллисекунд.

Maксимальное число пакетов "Запрос разъединения" (МТ - Max-Terminate)

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

Maксимальное число пакетов "Запрос конфигурации" (МС - Max-Configure)

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

Максимальное число пакетов "Неподтверждение конфигурации" (MF - Max-Failure)

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

6. Форматы пакетов LCP

Имеются три класса пакетов LCP:

1) пакеты конфигурации связи, используемые для установления и конфигурирования канала связи ("Запрос конфигурации", "Подтверждение конфигурации", "Неподтверждение конфигурации" и "Сброс конфигурации").

2) пакеты разъединения связи, используемые для разрыва связи ("Запрос разъединения", "Подтверждение разъединения").

3) пакеты обслуживания связи, используемые для управления и отладки звена связи ("Сброс кода", "Сброс протокола", "Запрос эха", "Ответ эха" и "Запрос сброса").

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

Независимо от того, какие опции конфигурации разрешаются, все пакеты конфигурации звена LCP, разъединения связи и сброса кода (кодирование от 1 до 7) посылаются всегда, как будто никакие опции конфигурации не были установлены. В частности, каждая опция конфигурации имеет значение по умолчанию. Это гарантирует постоянную распознаваемость пакетов LCP.

В информационном поле PPP инкапсулируется только один пакет LCP, где поле протокола PPP показывает тип c021 (протокол контроля звена LCP).

Общий формат пакетов протокола LCP показан ниже.

Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Данные ...

Поле "Код"

Поле "Код" - один октет, задает вид пакета LCP. Когда пакет получен с неопределенным полем "Код", передается пакет "Сброс кода".

Значения поля "Код" протокола LCP определяются в наиболее позднем издании "Assigned Numbers" RFC [3]. В настоящее время этот документ определяет следующие величины:

1 Запрос конфигурации

2 Подтверждение конфигурации

3 Неподтверждение конфигурации

4 Сброс конфигурации

5 Запрос разъединения

6 Подтверждение разъединения

7 Сброс кода

8 Сброс протокола

9 Запрос эха

10 Ответ эха

11 Запрос сброса

Поле "Идентификатор"

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

Поле "Длина"

Поле "Длина" (два октета) указывает длину пакетов LCP, включая поля "Код", "Идентификатор", "Длина" и "Данные". Длина не должна превышать величину MRU для звена передачи данных.

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

Поле "Данные"

Поле "Данные" содержит нуль или более октетов, как показано в поле "Длина". Формат поля "Данные" определяется полем "Код".

Особенности форматов различных типов пакетов протокола LCP более подробно рассмотрены ниже.

6.1. Формат пакетов LCP "Запрос конфигурации"

Общее описание

Приложение, желая открыть связь, должно передать пакет "Запрос конфигурации" (Configure-Request). Поле "Опции" заполняется любыми желательными изменениями величин, установленных по умолчанию.

Опции конфигурации не должны включать величины по умолчанию.

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

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Опции ...

Поле "Код"

Для запроса конфигурации принимает значение, равное 1.

Поле "Идентификатор"

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

Поле "Опции"

Поле "Опции" имеет переменную длину и содержит нуль или более опций конфигурации, которые отправитель желает установить. Все опции конфигурации всегда устанавливаются одновременно. Формат опций конфигурации описан ниже.

6.2. Формат пакетов LCP "Подтверждение конфигурации"

Общее описание

Если каждая опция конфигурации, полученная при запросе конфигурации, распознана, и все значения приемлемы, тогда приложение должно передать пакет "Подтверждение конфигурации" (Configure-Ack). Подтвержденные опции конфигурации нельзя повторно заказывать или изменять любым способом.

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

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Опции ...

Поле "Код"

Для подтверждения конфигурации принимает значение, равное 2.

Поле "Идентификатор"

Поле "Идентификатор" - это копия поля "Идентификатор" пакета "Запрос конфигурации", который вызвал это подтверждение конфигурации.

Поле "Опции"

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

6.3. Формат пакетов LCP "Неподтверждение конфигурации"

Общее описание

Если каждая из опций конфигурации распознаваема, но некоторые значения не приемлемы, то приложение должно передать пакет "Неподтверждение конфигурации" (Configure-Nak). При этом поле "Опции" заполняется единственным недопустимым значением опции конфигурации из запроса конфигурации. Для опций, которые не имеют численных значений (логические опции), вместо этого ответа должен использоваться "Сброс конфигурации".

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

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

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

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

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

Формат пакетов "Неподтверждение конфигурации" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Опции ...

Поле "Код"

Для неподтверждения конфигурации принимает значение, равное 3.

Поле "Идентификатор"

Поле "Идентификатор" - это копия поля "Идентификатор" запроса конфигурации, который вызвал это неподтверждение конфигурации.

Поле "Опции"

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

6.4. Формат пакетов LCP "Сброс конфигурации"

Общее описание

Если некоторые опции конфигурации, полученные в запросе конфигурации, не распознаваемы или не приемлемы, то приложение должно передать пакет "Сброс конфигурации" (Configure-Reject). Поле "Опции" пакета при этом содержит значение единственной недопустимой опции конфигурации из запроса конфигурации. Все распознанные и приемлемые опции конфигурации не изменяются при сбросе конфигурации, но, с другой стороны, опции конфигурации нельзя повторно заказывать или изменять.

При приеме сброса конфигурации поле "Идентификатор" должно соответствовать последнему переданному запросу конфигурации.

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

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

Формат пакетов "Сброс конфигурации" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Опции ...

Поле "Код"

Для сброса конфигурации принимает значение, равное 4.

Поле "Идентификатор"

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

Поле "Опции"

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

6.5. Формат пакетов LCP "Запрос разъединения" и "Подтверждение разъединения"

Общее описание

Для обеспечения механизма закрытия связи протокол LCP использует пакеты "Запрос разъединения" (Terminate-Request) и "Подтверждение разъединения" (Terminate-Ack).

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

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

Формат пакетов "Запрос разъединения" и " Подтверждение разъединения" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Данные...

Поле "Код"

Для запроса разъединения принимает значение, равное 5. Для подтверждения разъединения принимает значение, равное 6.

Поле "Идентификатор"

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

При приеме поле "Идентификатор" пакета "Запрос разъединения" копируется в поле "Идентификатор" пакета "Подтверждение разъединения".

Поле "Данные"

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

6.6. Формат пакетов LCP "Сброс кода"

Общее описание

Прием пакета протокола LCP с неизвестным кодом указывает, что одноранговый объект работает с другой версией. Об этом должно быть сообщено отправителю неизвестного кода путем передачи пакета "Сброса кода" (Code-Reject).

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

Формат пакетов "Сброс кода" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина	Сброшенный пакет...

Поле "Код"

Для сброса кода принимает значение, равное 7.

Поле "Идентификатор"

Поле "Идентификатор" должно изменяться для каждого посланного сброса кода.

Поле "Сброшенный пакет"

Поле " Сброшенный пакет" содержит копию пакета LCP, которая отклонена. Оно начинается с информационного поля и не включает никакие заголовки уровня звена передачи данных (ЗПД) и контрольную сумму (FCS). Для согласования c величиной MRU, установленной одноранговым объектом, поле "Сброшенный пакет" может сегментироваться.

6.7. Формат пакетов LCP "Сброс протокола"

Общее описание

Прием пакета PPP с неизвестным полем протокола указывает, что одноранговый объект пытается использовать протокол, который не поддерживается. Это обычно происходит, когда одноранговый объект пытается сконфигурировать новый протокол. Если автомат LCP находится в состоянии "Открыто", то об этом должно быть сообщено одноранговому объекту путем передачи пакета "Сброс протокола" (Protocol-Reject).

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

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина
Сброшенный протокол	Сброшенная информация...

Поле "Код"

Для сброса протокола принимает значение, равное 8.

Поле "Идентификатор"

Поле "Идентификатор" должно изменяться для каждого посланного сброса протокола.

Поле "Сброшенный протокол"

Поле "Сброшенный протокол" включает два октета и содержит поле протокола PPP пакета, который был сброшен.

Поле "Сброшенная информация"

Поле "Сброшенная информация" содержит копию пакета, который сброшен. Оно начинается с информационного поля и не включает заголовки уровня ЗПД и контрольную сумму (FCS). Поле "Сброшенная информация" должно сегментироваться, чтобы согласовываться c величиной MRU, установленной одноранговым объектом.

6.8. Формат пакетов LCP "Запрос эха" и "Ответ эха"

Общее описание

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

При приеме запроса эха в состояние LCP "Открыто", должен быть передан ответ эха. Пакеты "Запрос эха" (Echo-Request) и "Ответ эха" (Echo-Reply) должны посылаться только, когда LCP находится в состоянии "Открыто". Пакеты "Запрос эха" и "Ответ эха", полученные в любом другом состоянии, следует сбрасывать без уведомления. Формат пакетов "Запрос эха" и "Ответ эха" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина
Номер	Данные...

Поле "Код"

Для запроса эха принимает значение, равное 9. Для ответа эха принимает значение, равное 10.

Поле "Идентификатор"

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

Magic-номер

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

Поле "Данные"

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

Конец области определяется полем "Длина".

6.9. Формат пакетов LCP "Запрос сброса"

Общее описание

Для обеспечения механизма сброса уровня ЗПД при контроле канала в направлении от местной к отдаленной стороне в протоколе LCP предусмотрен код запроса сброса. Это полезно при отладке, тестировании работоспособности и для многих других функций.

Пакеты "Запрос сброса" (Discard-Request) должны посылаться только, когда LCP находится в состоянии "Открыто". При приеме любой пакет "Запрос сброса" должен сбрасываться без уведомления. Формат пакетов "Запрос сброса" показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Код	Идентификатор	Длина
Номер	Данные...

Поле "Код"

Для запроса сброса принимает значение, равное 11.

Поле "Идентификатор"

Поле "Идентификатор" должно изменяться для каждого посланного запроса сброса.

Magic-номер

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

Поле "Данные"

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

7. Опции конфигурации протокола LCP

Опции конфигурации протокола LCP позволяют модифицировать величины, установленные по умолчанию, для связи "точка-точка". Если опции конфигурации не включены в пакет "Запрос конфигурации", то для данной опции конфигурации используется значение, принятое по умолчанию.

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

Конец списка опций конфигурации определяется полем "Длина" пакетов LCP.

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

Общие понятия

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

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

0	1
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9
Тип	Длина	Данные...

Поле "Тип"

Поле "Тип" содержит один октет и указывает тип опций конфигурации. В настоящее время значения поля "Тип" протокола LCP определены в последнем издании "Assigned Numbers" RFC [3]. Возможны следующие значения:

0	Резерв
1	Максимальный размер принимаемого блока (MRU - Maximum-Receive-Unit)
3	Протокол аутентификации (Authentication-Protocol)
4	Протокол качества (Quality-Protocol)
5	Magic-номер
7	Сжатие полей протокола (Protocol-Field-Compression)
8	Сжатие адресных и управляющих полей (Address-and-Control-Field-Compression)

Поле "Длина"

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

Поле "Данные"

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

Формат и длина поля "Данные" определяются полями "Длина" и "Тип". Когда поле "Данные" определено длиной так, что оно простирается до конца информационного поля и далее, весь пакет сбрасывается без воздействия на автомат.

7.1. Максимальный размер принимаемого блока

Общее описание

Эту опцию конфигурации можно посылать, чтобы сообщить одноранговому объекту, что приложение может получить пакеты больших размеров, или запрашивать, чтобы одноранговый объект посылал меньшие пакеты. Максимальный размер принимаемого блока (MRU - Maximum-Receive-Unit) по умолчанию составляет 1500 октетов. Если требуются пакеты меньших размеров, приложение тем не менее должно быть способно получать полное 1500-октетное информационное поле.

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

Формат опции конфигурации MRU показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Тип	Длина	MRU

Поле "Тип"

Имеет значение, равное 1

Поле "Длина"

Принимает значение, равное 4

Поле "MRU"

Поле "MRU" содержит два октета и определяет максимальное число октетов в информационном поле и поле заполнения. Сюда не включаются заголовок кадра, поле протокола, контрольная сумма (FCS), биты или байты прозрачности.

7.2. Протокол аутентификации

Общее описание

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

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

Приложение не должно включать несколько опций конфигурации протокола аутентификации (AP - Authentication-Protocol) в пакетах "Запрос конфигурации". Вместо этого, ему следует попытаться вначале задать наиболее желательный протокол. Если опции этого протокола не подтверждаются, тогда приложению следует попытаться согласовать следующий наиболее желательный протокол в следующем запросе конфигурации.

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

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

Формат опции конфигурации протокола аутентификации показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Тип	Длина	Протокол аутентификации	Данные...

Поле "Тип"

Принимает значение, равное 3.

Поле "Длина"

Не менее 4 октетов.

Поле "Протокол аутентификации"

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

В настоящее время значения поля "Протокол аутентификации" определены в последнем издании "Assigned Numbers" RFC [3]. Текущие значения определены следующим образом:

Величина в 16-ричном виде	Протокол
C023 -	Протокол установления подлинности пароля PAP (Password Authentication Protocol);
C223 -	Протокол аутентификации запроса диалога CHAP (Challenge Handshake Authentication Protocol).

<

/p>

Поле "Данные"

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

7.3. Протокол качества

Общее описание

На некоторых линиях связи требуется определять, когда и как часто канал теряет данные. Этот процесс называется контролем качества канала связи. Существует опция конфигурации, которая обеспечивает согласование типа протокола качества (QP - Quality-Protocol) канала связи. По умолчанию контроль качества связи не осуществляется.

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

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

Формат опции конфигурации протокола качества показан ниже. Поля передаются слева направо.

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Тип	Длина	Протокол качества	Данные...

Поле "Тип"

Имеет значение, равное 4.

Поле "Длина"

Не менее 4 октетов.

Поле "Протокол качества "

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

В настоящее время значения поля "Протокол качества" определены в последнем издании "Assigned Numbers" RFC [3]. Текущие значения определены следующим образом:

Величина в 16-ричном виде	Протокол
C025	Сообщение качества канала связи LQR (Link Quality Report)

<

/p>

Поле "Данные"

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

7.4. Magic-номер

Общее описание

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

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

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

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

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

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

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

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

Число повторений	Вероятность
1	1/2**32= 2.3 E-10
2	1/2322 = 5.4 E-20
3	1/2323 = 1.3 E-29

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

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

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

Magic-номер может использоваться, чтобы обнаружить зацикленные звенья во время нормальной работы, а также в течение согласования опций конфигурации. Пакеты протокола LCP "Запрос эха", "Ответ эха" и "Запрос сброса" имеют поле "Мagic-номер". Если magic-номер был успешно согласован, то приложение должно передать эти пакеты с полем magic-номера, имеющим значение согласованного magic-номера.

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

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

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

Формат опции конфигурации magic-номера показан ниже. Поля передаются слева направо.

0	1	2 3 4
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
Тип	Длина	Мagic-номер

Поле "Тип"

5

Поле "Длина"

6 октетов.

Поле "Magic-номер "

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

7.5. Сжатие поля протокола

Общее описание

Эта опция конфигурации обеспечивает метод согласования сжатия полей протокола PPP (PFC - Protocol-Field-Compression). По умолчанию все приложения должны передать пакеты с двухоктетными полями протокола PPP.

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

Поле протокола использует механизм расширения, соответствующий механизму расширения ISO 3309 для полей адреса; наименее значащий бит (LSB - Least Significant Bit) каждого октета используется для указания на расширение поля протокола. Двоичный "0" в качестве LSB указывает, что поле протокола будет продолжаться в следующем октете. Присутствие двоичной единицы в качестве LSB свидетельствует о том, что этот октет поля протокола - последний.

Заметим, что к полю может быть присоединено любое число нулевых октетов, и двоичное значение будет тем же самым (например, вот два двоичных представления числа 3: 00000011 и 00000000 00000011).

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

Сжатые поля протокола не должны передаваться, если эта опция конфигурации не была согласована.

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

Поле протокола никогда не сжимается при посылке любого пакета LCP. Это правило гарантирует однозначное распознавание пакетов LCP. Когда поле протокола сжато, поле FCS уровня ЗПД рассчитывается не по исходному, а по сжатому кадру.

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

0	1
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5
Тип	Длина

Поле "Тип"

7

Поле "Длина"

2 октета.

7.6. Сжатие полей адреса и контроля

Общее описание

Эта опция конфигурации обеспечивает метод согласования сжатия полей адреса и контроля (ACFC - Address-and-Control-Field-Compression) ЗПД. По умолчанию все приложения должны передавать кадры с полями адреса и контроля в соответствии с правилами созданием кадров ЗПД.

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

Поля адреса и контроля не должны быть сжаты при посылке любого пакета LCP. Это правило гарантирует однозначное распознавание пакетов LCP. Когда поля адреса и контроля сжаты, поле FCS уровня ЗПД рассчитывается не по исходному, а по сжатому кадру.

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

0	1
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5
Тип	Длина

Поле "Тип"

8

Поле "Длина"

2 октета.

Список литературы

1. Simpson W., "The Point-to-Point Protocol (PPP)", Network Working Group, Request for Сomments 1661, STD: 51, July 1994.

2. Perkins, D., "Requirements for an Internet Standard Point-to-Point Protocol", RFC 1547, Carnegie Mellon University, December 1993.

3. Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/ Information Sciences Institute, July 1992.

Список используемых сокращений и терминов

ACFC (Address-and-Control-Field-Compression) - сжатие полей адреса и контроля;

AP (Authentication Protocol) - протокол аутентификации;

DCE (Data Communications Equipment) - аппаратура канала данных; устройства, обеспечивающие организацию и разрыв соединений, а также управление ими для передачи данных. Примером такого устройства является модем;

DTE (Data Terminal Equipment) - оконечное оборудование данных (ООД), оборудование пользователя, подключаемое к сети. Это может быть как просто терминал, так и большая ЭВМ. DTE и DCE могут объединяться в одном устройстве, как, например, в случае персонального компьютера с внутренним модемом;

FCS (frame check sequence) - проверочная последовательность кадра;

HDLC (High-level Data Link Control) - процедура управления каналом передачи данных высокого уровня);

IANA (Internet Assigned Numbers Authority) - отдел назначения номеров Internet;

ISO (International Standards Organization) - Международная организация по стандартизации;

LCP (Link Control Protocol) - протокол контроля канала;

LQP (Link Quality Protocol) - протокол качества связи;

LSB (Least Significant Bit) - наименее значащий бит;

MRU (Maximum Receive Unit) - максимальный размер блока;

NCP (Network Control Protocol) - протокол контроля сети;

PFC (Protocol-Field-Compression) - сжатие поля протокола;

PPP (Point-to-Point Protocol) - протокол канала связи с непосредственным соединением;

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

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

ЗПД - звено передачи данных (второй уровень Эталонной модели взаимодействия открытых систем);

Кадр - блок передаваемых данных на уровне ЗПД. Наряду с некотором числом единиц данных кадр может включать заголовок и/или хвостовик;

ЛВС - локальная вычислительная сеть;

МСЭ-Т - Сектор стандартизации электросвязи Международного союза электросвязи;

Одноранговый объект - другое окончание канала связи типа "точка-точка";

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

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

<

Содержание раздела