Перевод RFC 1661

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

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

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

Только 8 дополнительных октетов необходимы для формирования инкапсуляции при использовании в рамках HDLC-подобного фреймирования. В условиях, когда полоса пропускания не велика инкапсуляция и фреймирование могут быть сокращены до 2 или 4 октетов.

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

Протокол управления соединением (Link Control Protocol-LCP)

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

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

Протоколы управления сетью (Network Control Protocols - NCPs)

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

Конфигурирование.

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

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

1.1 Соглашения

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

ДОЛЖНО Это слово или прилагательное «требуемый»

обозначает абсолютно необходимое требование.

НЕ ДОЛЖНО Эта фраза обозначает абсолютный запрет.

СЛЕДУЕТ Это слово или прилагательное «рекомендуемый»

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

НЕ СЛЕДУЕТ Это слово и прилагательное «опциональный» означает,

что этот пункт один из разрешенного набора альтернатив. Реализация, которая не содержит эту опцию, ДОЛЖНА быть готова взаимодействовать с другой реализацией, которая включает в себя эту опцию.

1.2 Терминология

Этот документ часто использует следующие термины: Датаграмма Единица, передаваемая на сетевом уровне (таком как

IP). Датаграмма может быть инкапсулирована в один

или больше пакетов передаваемый через соединение

канального уровня. Фрейм Единица, передаваемая на канальном уровне. Фрейм

может включать заголовок и\или трейлер, наряду с

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

через интерфейс между сетевым уровням и канальным уровнем. Пакет обычно отображается во фрейм, за исключением того случая, когда выполняется фрагментация уровня звена данных или когда в один фрейм объединяются несколько пакетов. Сторона (peer) Другой конец соединения точка-точка. Отбрасывание Реализация отбрасывает пакеты без последующей (silently обработки. Реализации СЛЕДУЕТ предоставлять

discard) возможность логирования ошибок, включая

содержимое отброшенных пакетов, и СЛЕДУЕТ записывать события в статистический счетчик.

2 PPP инкапсуляция

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

Кратко РРР инкапсуляция показана ниже. Поля передаются с лева на право.

Protocol 8\16 бит Information Padding

Поле Protocol

Поле Protocol состоит из одного или двух октетов и его значение идентифицирует датаграмму, инкапсулированную в поле Information. При передаче и приеме первым является старший октет.

Структура этого поля совместима с механизмом расширения для адресных полей ISO 3309. Все протоколы ДОЛЖНЫ быть нечетными. Младший значащий бит в младшем значащем октете ДОЛЖЕН быть равен «1». Также, значение поля должно быть присвоено так, чтобы младший значащий бит старшего значащего октета был равен «0». Полученные фреймы, не удовлетворяющие этим правилам должны быть трактоваться как имеющие неопознанный протокол.

Значения поля Protocol в диапазоне от «0***» до «3***» идентифицируют специфические пакеты сетевого уровня и значения в диапазоне от «8***» до «B***» идентифицируют пакеты, принадлежащие соответствующему протоколу из семейства NCP.

Значения поля Protocol в диапазоне от «4***» до «7***» использованы для протоколов не имеющих соответствующего NCP. Значения поля в диапазоне от «с***» до «f***» идентифицируют пакеты как протоколы управления соединением (такие как LCP).

Современные значения поля Protocol содержатся в RFC «Assigned Numbers» [2]. Эта спецификация резервирует следующие значения:


	Шестнадцатеричное значение	Имя протокола
	0001	Padding Protocol
	0003 to 001f	Зарезервировано (transparency inefficient)
	007d	Зарезервировано (Control Escape)
	00cf	Зарезервировано (PPP NLPID)
	00ff	Зарезервировано (compression inefficient)
	8001 to 801f	Не используется
	807d	Не используется
	80cf	Не используется
	80ff	Не используется


	c021	Link Control Protocol
	c023	Password Authentication Protocol
	c025	Link Quality Report
	c223	Challenge Handshake Authentication Protocol

Разработчики новых протоколов ДОЛЖНЫ получить номер в Internet Assigned Numbers Authority (IANA), на IANA@isi.edu.

Поле Information

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

Максимальная длинна для поля Information, включая Padding, но, не включая поле Protocol определяется переменной Maximum Receive Unit (MRU), имеющей значение по умолчанию 1500 октетов. При согласовании совместимые реализации РРР могут установить другие значение MRU.

Заполнение

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

3 Работа РРР соединения

3.1 Обзор

Чтобы установить сообщение через соединения точка-точка, каждый конец РРР соединения ДОЛЖЕН сначала послать LCP пакеты, чтобы сконфигурировать и протестировать соединение. После того как соединение установлено, стороны МОГУТ быть аутентифицированы.

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

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

3.2 Фазная диаграмма

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

На диаграмме указаны не все переходы. Следующая семантика ДОЛЖНА преследоваться.

3.3 Фаза Link Dead

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

В течение этой фазы, LCP автомат (описанный ниже) будет находиться в состояниях Initial и Starting. Переход в фазу Link Establishment будет сигналом Up для LCP автомата.

Примечание: Обычно соединение возвращается в эту фазу после разъединения модема. В случае фиксированного соединения (hardwired link) эта фаза может быть крайне непродолжительной – достаточно просто определить присутствие другого устройства.

3.4 Фаза Link Establishment

LCP используется для установления соединения путем обмена пакетами Configure. После того как этот обмен завершается, LCP переходит в состояние Opened, обменявшись пакетами Configure-Ack (описанными ниже).

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

Важно заметить, что LCP могут быть настроены только те конфигурационные опции, которые не зависят от специфики протоколов сетевого уровня. Конфигурирование протоколов сетевого уровня выполняется отдельными протоколами управления сетью (Network Control Protocols - NCPs) в течение фазы Network-Layer Protocol.

Любые не LCP пакеты, полученные в течение этой фазы ДОЛЖНЫ быть отброшены.

Получение пакета LCP Configure-Request вызывает возвращение в фазу Link Establishment из фаз Network-Layer Protocol и Authentication.

3.5 Фаза Authentication

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

По умолчанию, аутентификация не обязательна. Если реализация желает, чтобы удаленная сторона была аутентифицирована с использованием специфического протокола аутентификации, то она ДОЛЖНА запросить использование этого протокола аутентификации в течение фазы Link Establishment.

Аутентификацию СЛЕДУЕТ провести после установления соединения как можно быстрее, насколько это возможно. Тем не менее, определение качества соединения МОЖЕТ проходить одновременно. Реализация МОЖЕТ НЕ позволить обмен пакетами определения качества соединения, чтобы задерживать аутентификацию бесконечно. Если аутентификация неудачна, СЛЕДУЕТ перейти к фазе Link Termination.

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

Примечание: Реализации НЕ СЛЕДУЕТ считать неудачной аутентификацию по истечении таймаута или при отсутствии ответа. Аутентификации СЛЕДУЕТ позволять несколько методов повторной передачи и выполнять фазу Link Termination только при превышении некоторого числа попыток.

За начало фазы Link Termination ответственна та реализация, которая отклонила аутентификацию удаленной стороне.

3.6 Фаза Network-Layer Protocol

После того как РРР закончил предыдущую фазу, каждый протокол сетевого уровня (такой как IP, IPX, или AppleTalk) ДОЛЖЕН быть отдельно сконфигурирован соответствующим протоколом управления сетью (Network Control Protocol - NCP).

Каждый NCP может быть в состоянии Opened или Closed.

Примечание: Так как реализация в начальной стадии может использовать значительное количество времени на определение качества соединения, реализации СЛЕДУЕТ избегать фиксированных таймаутов при ожидании конфигурирования сторонами NCPs.

После того как NCP достигнет состояния Opened, РРР будет переносить пакеты соответствующего протокола сетевого уровня. Любые пакеты поддерживаемых протоколов сетевого уровня, полученные до того как соответствующий NCP достигнет состояния Opened, ДОЛЖНЫ быть отброшены.

Примечание: Пока LCP в состоянии Opened, любой пакет неподдерживаемого реализацией протокола ДОЛЖЕН быть возвращен в Protocol-Reject (описан ниже). Только поддерживаемые протоколы должны отбрасываться.

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

3.7 Фаза Link Termination

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

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

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

После обмена пакетами Terminate, реализации СЛЕДУЕТ сигнализировать физическому уровню об отсоединении, чтобы заставить соединение завершится, особенно в случае со сбоем аутентификации. Отправителю пакета Terminate-Request СЛЕДУЕТ отключиться после получения пакета Terminate-Ack или по истечении счетчика Restart. Получателю пакета Terminate-Request СЛЕДУЕТ ждать отключения удаленной стороны и он НЕ ДОЛЖЕН отключаться пока не пройдет как минимум один интервал Restart после отправки Terminate-Ack. РРР СЛЕДУЕТ перейти в фазу Link Dead.

Все не LCP-пакеты, полученные в течение этой фазы ДОЛЖНЫ быть отброшены.

Примечание: Закрытие соединения с помощью LCP является достаточным. NCP нет необходимости слать шквалы пакетов Terminate. Напротив, тот факт, что NCP закрыт, не является достаточным основанием для закрытия РРР соединения, даже если этот NCP в настоящее время единственным в состоянии Opened.

4 Опциональный автомат согласования

Конечный автомат определен событиями, действиями и переходами состояний. События включают в себя получение внешних команд, таких как Open и Close, истечение таймера Restart, прием пакетов от удаленной стороны. Действия включают в себя запуск таймера Restart и передача пакетов удаленной стороне.

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

События

Up = lower layer is Up Down = lower layer is Down Open = administrative Open Close= administrative Close

TO+ = Timeout with counter > 0 TO- = Timeout with counter expired

RCR+ = Receive-Configure-Request (Good)

RCR- = Receive-Configure-Request (Bad)

RCA = Receive-Configure-Ack

RCN = Receive-Configure-Nak/Rej

RTR = Receive-Terminate-Request

RTA = Receive-Terminate-Ack

RUC = Receive-Unknown-Code

RXJ+ = Receive-Code-Reject (permitted)

or Receive-Protocol-Reject RXJ- = Receive-Code-Reject (catastrophic)

or Receive-Protocol-Reject RXR = Receive-Echo-Request

or Receive-Echo-Reply

or Receive-Discard-Request

Действия

tlu = This-Layer-Up tld = This-Layer-Down tls = This-Layer-Started tlf = This-Layer-Finished

irc = Initialize-Restart-Count zrc = Zero-Restart-Count

scr = Send-Configure-Request

sca = Send-Configure-Ack scn = Send-Configure-Nak/Rej str = Send-Terminate-Request sta = Send-Terminate-Ack scj = Send-Code-Reject

ser = Send-Echo-Reply

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

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


События	Состояния
	0	1	2	3	4	5
	Initial	Starting	Closed	Stopped	Closing	Stopping
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,sca/6	4	4
RCA	-	-	sta/2	sta/3	4	4
RCN	-	-	sta/2	sta/3	4	4
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
	Req-Sent	Ack-Rcvd	Ack-Sent	Opened
Up	-	-	-	-
Down	1	1	1	tld/1
Open	6	7	8	9r
Close	irc,str/4	irc,str/4	ire,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	ire/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,scr/6
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	8	ser/9

Состояния, в которых таймер Restart запущен, опознаваемы по присутствию событий TO. Только действия Send-Configure-Request, Send-Terminate-Request и Zero-Restart-Count запускают или перезапускают таймер Restart. Таймер Restart останавливается, когда происходит переход из состояния, где таймер работает, в состояние, где таймер не работает.

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

[p] Пассивная опция. Смотри обсуждение состояния Stopped.

[r] Рестарт опции. Смотри обсуждение состояния Open.

[x] Пересекающееся соединение. Смотри обсуждение события RCA.

4.2 Состояния

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

Initial

В состояние Initial нижний уровень недоступен. Таймер Restart не работает в состоянии Initial.

Starting

Состояние Starting является копией Open для состояния Initial. Было инициировано административное открытие, но нижний уровень все еще не доступен. Таймер Restart не работает в этом состоянии.

Когда нижний уровень станет доступен (Up), посылается Configure-Request.

Closed

В состоянии Closed соединение доступно (Up), но событие Open еще не произошло. Таймер Restart не работает в состоянии Closed.

В ответ на прием пакетов Configure-Request посылается Terminate-Ack. Terminate-Ack отбрасывается для предотвращения образования петли.

Stopped

Состояние Stopped является копией Open для состояния Closed. Это состояние возникает, когда автомат ждет события Down после действия This-Layer-Finished или после отправки Terminate-Ack. Таймер Restart не работает в состоянии Stopped.

В ответ на прием пакетов Configure-Request, посылается соответствующий ответ.

В ответ на прием других пакетов посылается Terminate-Ack. Terminate-Ack отбрасывается для предотвращения образования петли.

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

Это вид условий между ответом на событие Down (от действия This-Layer-Finished) и событием Receive-Configure-Request. Когда Configure-Request приходит перед событием Down, то событие Down будет вытеснено возвратом автомата в состояние Starting. Это предотвращает атаку на повторение.

Опция реализации: После того как удаленная сторона не ответила Configure-Requests, реализация МОЖЕТ пассивно ждать, когда удаленная сторона пошлет Configure-Requests. В этом случае действие This-Layer-Finished не используется для события TO- в состояниях Req-Sent, Ack-Rcvd и Ack-Sent.

Эта опция применима на выделенных каналов связи или для каналов не имеющих статусных сигналов, но НЕ СЛЕДУЕТ использовать ее для коммутируемых каналов.

Closing

В состоянии Closing делается попытка прекратить соединение. Послан Terminate-Request и запушен таймер Restart, но Terminate-Ack все еще не получен.

При получении Terminate-Ack произойдет переход в состояние Closed. При истечении таймера Restart посылается новый Terminate-Request и таймер перезапускается. После того как таймер истек Max-Terminate раз, происходит переход в состояние Closed.

Stopping

Состояние Stopping является двойником Open для состояния Closing. Terminate-Request был послан и таймер Restart запущен, но Terminate-Ack все еще не получен.

Логическое обоснование: Состояние Stopping предоставляет хороший шанс завершить соединения до того как появится новый трафик. После того как соединение прекращено может произойти новое конфигурирование через состояния Stopped или Starting.

Request-Sent

Состояние Request-Sent является попыткой конфигурировать соединение. Configure-Request уже послан, таймер Restart запущен, но Configure-Ack все еще не получен, так же как не один не послан.

Ack-Sent

В состоянии Ack-Sent Configure-Request и Configure-Ack были посланы, но Configure-Ack не был получен. Таймер Restart запущен с тех пор как Configure-Ack не был получен.

Opened

В состоянии Opened Configure-Ack был и послан и получен. Таймер Restart не запущен.

Когда реализация перешла в состояние Opened, ей СЛЕДУЕТ сигнализировать верхнему уровню, что произошло Up. Наоборот, покидая состояние Opened, ей СЛЕДУЕТ сигнализировать верхнему уровню, что теперь произошло Down.

4.3 События

Переходы и действия в автомате происходят по причине событий.

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

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

Его так же использует LCP, чтобы сигнализировать каждому NCP, что соединения переходит в фазу Network-Layer Protocol. То есть, действие This-Layer-Up LCP вызывает событие Up в NCP.

Down

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

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

Его так же использует LCP, чтобы сигнализировать каждому NCP, что соединение покидает фазу Network-Layer Protocol. То есть, действие This-Layer-Down LCP вызывает событие Down в NCP.

Open

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

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

Когда получен Terminate-Request или произошли другие события, которые приведут к недоступности соединения, автомат перейдет в состояние, где соединение будет готово повторно открыться. Никакого дополнительного административного состояния не требуется.

Замечания реализации: Когда аутентификация не удалась, соединения СЛЕДУЕТ разорвать, чтобы предотвратить атаку на повторение и отказ в обслуживании других пользователей. Так как соединение административно доступно (по определению), это может быть достигнуто имитацией события Close для LCP, немедленно следующего за событием Open. Нужно позаботиться о том, чтобы событие Close не могло произойти от другого источника.

Close, следующий за Open будет приводить к правильному завершению соединения, проходящему через состояния Closing и Stopping, когда действие This-Layer-Finished может отключить соединение. Автомат будет ждать в состоянии Stopped или Starting для следующей попытки соединения.

Timeout (TO+,TO-)

Это событие показывает истечение таймера Restart. Этот таймер используется для ответа на пакеты Configure-Request и Terminate-Request.

Событие TO+ показывает, что счетчик Restart продолжает быть больше нуля, что вызывает повторную отправку пакетов Configure-Request и Terminate-Request.

Событие TO- показывает, что счетчик Restart не больше нуля и больше не требуется осуществлять повторную пересылку пакетов.

Receive-Configure-Request (RCR+,RCR-)

Это событие происходит, когда от удаленной стороны получен пакет Configure-Request. Пакет Configure-Request указывает на желание открыть соединение и может содержать Configuration Options. Пакет Configure-Request полностью будет описан ниже.

Событие RCR+ говорят о том, что Configure-Request был принят и вызвал отправку соответствующего пакета Configure-Ack.

Событие RCR- показывает, что пакет Configure-Request не был принят и вызвал отправку соответствующего пакета Configure-Nak или Configure-Reject.

Замечания по реализации: Эти события могут произойти, когда соединение уже находится в состоянии Opened. Реализация ДОЛЖНА быть готова повторно согласовать конфигурационные опции.

Receive-Configure-Ack (RCA)

Это событие происходит, когда от удаленной стороны получен допустимый пакет Configure-Ack. Пакет Configure-Ack является положительным ответом на пакет Configure-Request. Пакеты вне последовательности или другие недопустимые пакеты отбрасываются.

Замечания по реализации: Так как корректный пакет уже был получен перед тем как было достигнуто состояние Ack-Rcvd или Opened, крайне неприятно если прибудет другой такой же пакет. Как было описано выше, все недопустимые пакеты Ack/Nak/Rej отбрасываются, чтобы не повлиять на переходы состояние автомата.

Однако, возможно, что корректно сформированный пакет прибудет через по-совпадению установленное перекрестное соединение (a coincidentally-timed cross-connection). Наиболее вероятно это будет результатом ошибки реализации. По крайней мере, это пришествие СЛЕДУЕТ занести лог.

Receive-Configure-Nak/Rej (RCN)

Это событие происходит, когда от удаленной стороны был получен допустимый пакет Configure-Nak или Configure-Reject. Configure-Nak и Configure-Reject являются отрицательным ответом на пакет Configure-Request. Пакеты вне последовательности или другие недопустимые пакеты отбрасываются.

Замечания по реализации:

Хотя Configure-Nak и Configure-Reject вызывают одинаковый переход состояния автомата, эти пакеты оказывают значительно отличающиеся эффекты на Configuration Options, посылаемые в результатирующем пакете Configure-Request.

Receive-Terminate-Request (RTR)

Это событие происходит при получении пакета Terminate-Request. Terminate-Request показывает на желание удаленной стороны закрыть соединение.

Замечания по реализации: Это событие не идентично событию Close (смотри выше) и не перекрывает команду Open локального сетевого администратора. Реализация ДОЛЖНА быть готова получить новый пакет Configure-Request без вмешательства сетевого администратора.

Receive-Terminate-Ack (RTA)

Это событие происходит, когда от удаленной стороны получен пакет Terminate-Ack. Пакет Terminate-Ack обычно является ответом на пакет Terminate-Request. Так же он может указывать на то, что удаленная сторона находится в состоянии Closed или Stopped, а так же служит для повторной синхронизации конфигурации соединения.

Receive-Unknown-Code (RUC)

Это событие происходит, когда от удаленной стороны получен пакет не поддающийся интерпретации. В ответ отправляется пакет Code-Reject.

Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)

Это событие происходит, когда от удаленной стороны получен пакет Code-Reject или Protocol-Reject.

Событие RXJ+ возникает, когда отброшенное значение приемлемо, такое как Code-Reject из расширенного кода или Protocol-Reject из NCP. Это в пределах нормального функционирования. Реализация ДОЛЖНА прекратить посылать этот тип пакета.

Событие RXJ- возникает, когда отброшенное значение катастрофично, такое как Code-Reject на Configure-Request или Protocol-Reject на LCP! Это событие вызывает невосстановимую ошибку и прекращает соединение.

Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request (RXR)

Это событие происходит при получении от удаленной стороны пакетов Echo-Request, Echo-Reply или Discard-Request. Пакет Echo-Reply является ответом на пакет Echo-Request. На пакеты Echo-Reply или Discard-Request ответа не может быть.

4.4 Действия

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

Illegal-Event (-)

Это действие показывает, что событие не могло произойти в правильно реализованном автомате. Реализация имеет внутренние ошибки, которые должны быть занесены в лог. Переходов состояний не происходит и реализации НЕ СЛЕДУЕТ делать сброс или останавливаться.

This-Layer-Up (tlu)

Это действие показывает верхнему уровню, что автомат перешел в состояние Opened. Обычно это действие использует LCP для того, чтобы отправить событие Up в NCP, Authentication Protocol или Link Quality Protocol. Оно так же может быть использовано NCP для того, чтобы показать, что соединение доступно для трафика сетевого уровня.

This-Layer-Down (tld)

Это действие показывает верхнему уровню, что автомат покидает состояние Opened. Обычно это действие использует NCP для того, чтобы отправить событие Down в NCP, Authentication Protocol или Link Quality Protocol. Оно так же может быть использовано NCP для того, чтобы показать, что соединение больше не доступно для трафика сетевого уровня.

This-Layer-Started (tls)

Это действие показывает нижнему уровню, что автомат вошел в состояние Starting, и что нужен нижний уровень для установления соединения. Нижнему уровню СЛЕДУЕТ ответить событием Up, когда нижний уровень будет доступен.

Результат этого действия обуславливается реализацией.

This-Layer-Finished (tlf)

Это событие показывает нижнему уровню, что автомат перешел в состояния Initial, Closed или Stopped и что нижний уровень больше не нужен для поддержания соединения. Нижнему уровню СЛЕДУЕТ ответить событие Down.

Обычно это действие МОЖЕТ использовать LCP для предотвращения фазы Link Dead, или МОЖЕТ быть использовано NCP для индикации отсутствия открытых экземпляров NCP и прекращения соединения.

Результат этого действия обуславливается реализацией.

Initialize-Restart-Count (irc)

Это действие устанавливает в счетчик Restart соответствующее значение (Max-Terminate или Max-Configure). Счетчик уменьшается после каждой отправки, включая первую.

Замечания по реализации: В дополнение к установке счетчика Restart реализация ДОЛЖНА установить таймаут в начальное значение, когда будет использоваться откат таймера Restart.

Zero-Restart-Count (zrc)

Это действие устанавливает таймер Restart в ноль.

Замечания по реализации:

Это действие позволяет FSA для приостановки перед установлением желаемого финального состояния, позволяя трафику быть обработанным удаленной стороной. В дополнение к обнулению счетчика Restart реализация ДОЛЖНА установить таймаут в соответствующее значение.

Send-Configure-Request (scr)

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

Send-Configure-Ack (sca)

Передается Configure-Ack. Он подтверждает прием пакета Configure-Request с приемлемым набором конфигурационных опций.

Send-Configure-Nak (scn)

Отправлены пакеты Configure-Nak или Configure-Reject. Эти пакеты являются отрицательным ответом на получение пакета Configure-Request с неприемлемым набором конфигурационных опций.

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

Send-Terminate-Request (str)

Передан пакет Terminate-Request. Он указывает на желание закрыть соединение. При передаче пакета Terminate-Request стартует таймер Restart. Счетчик Restart декрементируется при каждой повторной передаче Terminate-Request.

Send-Terminate-Ack (sta)

Передан пакет Terminate-Ack. Этот пакет подтверждает прием пакета Terminate-Request или служит для синхронизации автоматов.

Send-Echo-Reply (ser)

Передан пакет Echo-Reply. Он подтверждает прием пакета Echo-Request.

4.5 Предотвращение петель.

Протокол делает разумные попытки избавится от петель согласования конфигурационных опций. Однако протокол НЕ гарантирует, что эти петли не будут появляться. Как в случае с любым согласованием, можно сконфигурировать две реализации РРР с конфликтующими политиками, которые никогда не перекроются. Также можно сконфигурировать политики, которые позволяют перекрывание, но сделают это за значительный промежуток времени. Разработчики должны иметь это ввиду, им также СЛЕДУЕТ реализовать механизм детектирования петель или высокоуровневых таймаутов.

4.6 Счетчики и таймеры

Таймер Restart

В автомате используется один таймер. Таймер Restart используется для измерения времени передачи пакетов Configure-Request и Terminate-Request. Истечение этого таймера вызывает событие Timeout и повторную передачу пакетов Configure-Request или Terminate-Request. Таймер Restart ДОЛЖЕН быть конфигурируемым, но по умолчанию СЛЕДУЕТ установить значение три (3) секунды.

Замечания по реализации: СЛЕДУЕТ установить зависимость таймера Restart от скорости соединения. Значение по умолчанию выбрано для низкоскоростных (от 2400 до 9600 bps) коммутируемых соединений с низкой латентностью (типичная телефонная линия). Для высокоскоростных соединений или соединений с низкой латентностью СЛЕДУЕТ выбирать меньшие значения.

Вместо постоянного значения, таймер Restart МОЖЕТ начинать с начального маленького значения и повышать его до сконфигурированного конечного значения. Каждое последующее значение, меньшее финального, СЛЕДУЕТ применять как минимум в два раза больше предыдущего. Начальному значению СЛЕДУЕТ быть достаточно большим, чтобы покрывать двойное время передачи пакета при текущей скорости соединения и как минимум 100 миллисекунд, чтобы позволить удаленной стороне обработать пакет перед ответом. Некоторые линии добавляют еще 200 миллисекунд спутниковой задержки. Двойное время передачи для модемов, работающих на скорости 14400 bps от 160 до 600 миллисекунд.

Max-Terminate

Счетчик Max-Terminate показывает число отправленных пакетов Max-Terminate без получения Terminate-Ack, перед тем как будет сделан вывод о том, что удавленная сторона не отвечает. Счетчик Max-Terminate ДОЛЖЕН быть конфигурируемым. Значение по умолчанию следует установить в две (2) отправки.

Max-Configure

Счетчик Max-Configure показывает число отправленных пакетов Configure-Request без получения пакетов Configure-Ack, Configure-Nak или Configure-Reject, перед тем как будет сделан вывод о том, что удавленная сторона не отвечает. Счетчик Max-Configure ДОЛЖЕН быть конфигурируемым. Значение по умолчанию СЛЕДУЕТ установить в десять (10) отправок.

Max-Failure

Счетчик Max-Failure показывает число отправленных пакетов Configure-Nak без получения пакета Configure-Ack перед тем как будет сделан вывод о том, что конфигурация не сходится. Любые дополнительные пакеты Configure-Nak для опций, запрошенных удаленной стороной будут преобразованы в пакеты Configure-Reject и опции, требуемые локально больше не применяются. Счетчик Max-Failure ДОЛЖЕН быть конфигурируемым. Значение по умолчанию СЛЕДУЕТ установить в пять (5) отправок.

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

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

1. Пакеты конфигурации линии, используемые для установления и конфигурирования соединения (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject).

2. Пакеты завершения соединения (Terminate-Request и Terminate-Ack).

3. Пакеты обслуживания и отладки соединения (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

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

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

В поле PPP Information инкапсулируется ровно один LCP пакет, если поле Protocol показывает тип 0хc021 (Link Control Protocol).

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

15/16

Code

Identifier

Length

Data ...

Code

Поле Code имеет длину один октет и идентифицирует тип LCP пакета. Когда получен пакет с неизвестным полем Code, передается пакет Code-Reject.

Современные значения поля Code определены в «Assigned Numbers» RFC [2]. Этот документ затрагивает следующие значения:

1. Configure-Request

2. Configure-Ack

3. Configure-Nak

4. Configure-Reject

5. Terminate-Request

6. Terminate-Ack

7. Code-Reject

8. Protocol-Reject

9. Echo-Request

10. Echo-Reply

11. Discard-Request

Identifier

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

Length

Поле Length состоит из двух октетов и показывает длину LCP пакета. Значение поля Length НЕ ДОЛЖНО превышать MRU на соединении. Октеты за пределами диапазона, заданного полем Length трактуются как заполнение и игнорируются при приеме пакета. Если поступает пакет с неверным значением поля Length, то он отбрасывается без воздействия на автомат.

Data

Поле Data имеет ноль или большее число октетов, в соответствии со значением поля Length. Формат поля Data зависит от поля Code.

5.1 Configure-Request

Описание

Реализация, желающая открыть соединение ДОЛЖНА передать Configure-Request. Поле Options заполняется любыми желательными значениями, изменяющими значения по умолчанию.

При получении пакета Configure-Request ДОЛЖНО быть отправлено соответствующее значение.

Краткий формат пакета Configure-Request показан ниже. Поля передаются слева направо.

0 8 15/16 24 31

Code

Identifier

Length

Options ...

Code

Для Configure-Request равно 1.

Identifier

Поле Identifier должно изменяться всякий раз, когда меняется содержание поля Options и всякий раз, когда поступает допустимый ответ на предыдущий запрос. При повторной отправке Identifier МОЖЕТ оставаться неизменным.

Options

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

5.2 Configure-Ack

Описание

Если каждая конфигурационная опция, полученная в Configure-Request, опознана и все значения приемлемы, то реализация ДОЛЖНА отправить Configure-Ack. Подтвержденные конфигурационные опции НЕ ДОЛЖНЫ быть переупорядочены или изменены другим путем.

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

Краткий формат пакета Configure-Ack показан ниже. Поля передаются с лева на право.

0 8 15/16 24 31

Code

Identifier

Length

Options ...

Code

2 для Configure-Ack.

Identifier

Поле Identifier копирует поле в пакете Configure-Request, в ответ на который отправляется Configure-Ack.

Options

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

5.3 Configure-Nak

Описание

Если полученные конфигурационные опции опознаваемы, но некоторые значения не приемлемы, реализация ДОЛЖНА передать пакет Configure-Nak. Поле Options заполняется только неприемлемыми конфигурационными опциями из пакета Configure-Request. Приемлемые конфигурационные опции отфильтрованы в Configure-Nak, иначе конфигурационные опции из пакета Configure-Request ДОЛЖНЫ быть повторно согласованы.

Опции, не имеющие никаких значений (булевских опций) ДОЛЖНЫ использовать Configure-Reject при ответе.

Каждая конфигурационная опция, которая допустима только в единственном экземпляре, ДОЛЖНА быть изменена на приемлемое значение отправителем Configure-Nak. МОЖЕТ быть использовано значение по умолчанию, если оно отличается от запрошенного значения.

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

Наконец, реализация может быть сконфигурирована запрашивать согласование определенной конфигурационной опции. Если эта опция не перечислена, тогда эта опция МОЖЕТ быть добавлена в список конфигурационных опций, как подсказка удаленной стороне включить эту опцию в следующий пакет Configure-Request. Значения для опции ДОЛЖНЫ означать приемлемость значений для отправителя Configure-Nak.

При получении Configure-Nak поле Identifier должно совпадать с тем, что было передано с последним пакетом Configure-Request. Неправильные пакеты должны отбрасываться.

Отклик на приемлемый Configure-Nak показывает, что когда послан новый пакет Configure-Request конфигурационные опции МОГУТ быть изменены так, как указано в пакете Configure-Nak. Когда в пакете присутствует множество экземпляров конфигурационной опции, удаленной стороне СЛЕДУЕТ выбрать одно значение и включить его в следующий пакет Configure-Request.

Некоторые конфигурационные опции имеют переменную длину. Так как Nak'd Option была модифицирована удаленной стороной, реализация ДОЛЖНА быть способна обрабатывать длину Option, отличную от той, что была в первоначальном пакете Configure-Request.

Кратко формат пакета Configure-Nak показан ниже. Поля передаются с лева направо.

15/16

Code

Identifier

Length

Options ...

Code

3 для Configure-Nak.

Identifier

Поле копирует поле Identifier пакета Configure-Request, вызвавшего отправку Configure-Nak.

Options

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

5.4 Configure-Reject

Описание

Если некоторые конфигурационные опции получены в пакете Configure-Request и не могут быть опознаны или неприемлемы при согласовании (как сконфигурировано сетевым администратором), то реализация ДОЛЖНА передать Configure-Reject. Поле Options заполнено только неприемлемыми конфигурационными опциями из Configure-Request. Все узнаваемые и согласуемые конфигурационные опции отфильтровываются из Configure-Reject, иначе

конфигурационные опции НЕ ДОЛЖНЫ быть переупорядочены или модифицированы любым путем.

При принятии Configure-Reject поле Identifier ДОЛЖНО совпадать с тем, что было передано в последнем Configure-Request. В дополнение, конфигурационные опции в пакете Configure-Reject ДОЛЖНЫ быть правильным подмножеством тех, что были в последнем Configure-Request. Неправильные пакеты отклоняются.

Получение правильного Configure-Reject показывает, что когда новый Configure-Request будет послан, он НЕ ДОЛЖЕН включать любую из опций, содержащихся в Configure-Reject.

Кратко формат пакета Configure-Reject показан ниже. Поля передаются с лева направо.

15/16

Code

Identifier

Length

Options ...

Code

4 для Configure-Reject.

Identifier

Поле Identifier копирует поле Identifier пакета Configure-Request, который вызвал отправку Configure-Reject.

Options

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

5.5 Terminate-Request и Terminate-Ack

Описание

LCP включает пакеты Terminate-Request и Terminate-Ack для предоставления механизма закрытия соединения.

Реализации, желающей закрыть соединение, СЛЕДУЕТ передать пакет Terminate-Request. Пакет Terminate-Request СЛЕДУЕТ продолжать посылать до тех пор, пока не будет получен Terminate-Ack и нижний уровень не покажет, что он начинает закрываться или пока не будет передано достаточно большое число пакетов, позволяющее с разумной умеренностью считать, что удаленная сторона отключится.

При получении пакета Terminate-Request пакет Terminate-Ack ДОЛЖЕН быть отправлен.

Получение не ожидавшегося пакета Terminate-Ack показывает, что удаленная сторона находится в состояниях Closed или Stopped, в противном случае требуется повторное согласование.

Кратко формат пакетов Terminate-Request и Terminate-Ack показан ниже. Поля передаются с лева направо.

15/16

Code

Identifier

Length

Data ...

Code

5 for Terminate-Request;

6 for Terminate-Ack.

Identifier

При передаче поле Identifier ДОЛЖНО быть изменено, когда меняется содержимое поля

Data или когда был получен допустимый ответ на предыдущий запрос. При передаче, поле Identifier МОЖЕТ меняться.

При приеме поле Identifier пакета Terminate-Request копируется в поле Identifier пакета Terminate-Ack.

Data

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

5.6 Code-Reject

Описание

Получение LCP пакета с неизвестным Code показывает, что удаленная сторона использует другую версию протокола. Это ДОЛЖНО быть сообщено удаленной стороне передачей пакета Code-Reject.

При получении Code-Reject на код, который является фундаментальным в этой версии реализации протокола, СЛЕДУЕТ сообщить о проблеме и прекратить сообщение, так как маловероятно, что проблема может быть исправлена автоматически.

Кратко формат пакета Code-Reject показан ниже. Поля передаются с лева направо.

15/16

Code

Identifier

Length

Отброшенный пакет

Code

7 для Code-Reject

Identifier

Поле идентификатор ДОЛЖНО изменяться при каждой отправке пакета Code-Reject.

Rejected-Packet

Поле Rejected-Packet содержит копию LCP пакета, который был отброшен. Оно начинается с поля Information и не включает заголовки канального уровня и FCS.

Rejected-Packet ДОЛЖЕН быть усечен для соблюдения MRU, установленного удаленной стороной.

5.7 Protocol-Reject

Описание

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

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

Пакеты Protocol-Reject могут посылаться только когда LCP находится в состоянии Opened. Пакеты Protocol-Reject могут приниматься в любом состоянии, отличном от состояния Opened, в котором эти пакеты СЛЕДУЕТ отбрасывать.

Кратко формат пакета Protocol-Reject показан ниже. Поля передаются с лева направо.

0 8 15/16 24 31


Code	Identifier	Length
Rejected-Protocol		Rejected-Information...

Code

8 для Protocol-Reject.

Identifier

Поле Identifier должно изменяться при каждой отправке Protocol-Reject.

Rejected-Protocol

Поле Rejected-Protocol состоит из двух октетов, которые содержат поле PPP Protocol пакета, который был отброшен.

Rejected-Information

Поле Rejected-Information содержит копию пакета, который был отброшен. Оно начинается с поля Information и не включает ни заголовки канального уровня, ни FCS. Поле Rejected-Information ДОЛЖНО быть усечено для соблюдения MRU, установленного удаленной стороной.

5.8 Echo-Request и Echo-Reply

Описание

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

При получении пакета Echo-Request, когда LCP находится в состоянии Opened, ДОЛЖЕН быть отправлен пакет Echo-Reply.

Пакеты Echo-Request и Echo-Reply ДОЛЖНЫ посылаться только когда LCP находится в состоянии Opened. В любых других состояниях они должны отбрасываться.

Кратко формат пакетов Echo-Request и Echo-Reply показан ниже. Поля передаются слева направо.

15/16

Code

Identifier

Length

Magic-Number

Data ...

Code

9 для Echo-Request;

10 для Echo-Reply.

Identifier

При передаче, поле Identifier ДОЛЖНО быть изменено, когда меняется содержимое поля Data или когда был получен допустимый ответ на предыдущий запрос. При повторной передаче поле МОЖЕТ не изменяться.

При получении Echo-Request, поле Identifier копируется в поле Identifier пакета Echo-Reply.

Magic-Number

Поле Magic-Number состоит из четырех октетов и служит для определения соединений, которые находятся в состоянии петли. До тех пор пока конфигурационная опция Magic-Number успешно согласована, Magic-Number ДОЛЖЕН передаваться как ноль. Смотри подробное объяснение в разделе «Конфигурационная опция Magic-Number».

Data

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

5.9 Discard-Request

Описание

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

Пакет Discard-Request может быть послан только когда LCP автомат находится в состоянии Opened. При приеме в других состояниях, получатель ДОЛЖЕН отбросить пакет Discard-Request.

Кратко формат пакета Discard-Request показан ниже. Поля передаются с лева направо.

0 8 15/16 24 31

Code

Identifier

Length

Magic-Number

Data ...

Code

11 для Discard-Request.

Identifier

Поле Identifier ДОЛЖНО быть изменено при каждой отправке пакета.

Magic-Number

Поле Magic-Number состоит из четырех октетов и служит для определения соединений, которые находятся в состоянии петли. До тех пор пока Magic-Number конфигурационная опция успешно согласована, Magic-Number ДОЛЖЕН передаваться как ноль. Смотри подробное объяснение в разделе «Конфигурационная опция Magic-Number».

Data

6 Конфигурационные опции LCP

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

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

Конец списка конфигурационных опций определяется полем Length LCP пакета.

Пока не определено другое, все конфигурационные опции применяются в полудуплексном стиле. Обычно это направление приема с точки зрения отправителя Configure-Request.

Философия разработки. Опции показывают дополнительные возможности или требования реализации, которые требуют опцию. Реализации, не понимающей какую-нибудь опцию, СЛЕДУЕТ взаимодействовать с той реализаций, которая поддерживает все опции.

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

Отправка значений опций по умолчанию в пакете Configure-Request не требуется.

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

0 8 15


Type	Length	Data...

Type

Поле Type состоит из одного октета и показывает тип опции. На сегодняшний день опции LCP определены в самой последней версии RFC «Assigned Numbers» [2].

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

1 Maximum-Receive-Unit

3 Authentication-Protocol

4 Quality-Protocol

5 Magic-Number 7 Protocol-Field-Compression

8 Address-and-Control-Field-Compression

Length

Поле Length состоит из одного октета и показывает длину этой опции, включая поля Type, Length и Data.

Если распознаваемая опция получена в пакете Configure-Request, имеющая неверное поле Length, то СЛЕДУЕТ отправить Configure-Nak, включающий желаемую опцию с заполненными полями Length и Data.

Data

Поле Data имеет ноль или большее количество октетов, содержащих информацию, специфичную для опции. Формат и длинна поля Data определяется полями Type и Length.

Когда поле Data, показываемое полем Length выходит на пределы поля Information, то пакет отбрасывается без воздействия на автомат.

6.1 Maximum-Receive-Unit (MRU)

Описание

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

Значение по умолчанию 1500 октетов. Если запрошены меньшие пакеты, реализация ДОЛЖНА оставаться способной принимать полноразмерные информационные поля в случае потери синхронизации в соединении.

Замечание по реализации: Эта опция используется для того чтобы продемонстрировать возможности реализации. Удаленная сторона не требует максимального использования ёмкости. Например, когда MRU показывает 2048 октетов, удаленная сторона не требует посылать пакеты в 2048 октетов. Удаленной стороне не требуется посылать пакет Configure-Nak, чтобы показать, что она будет посылать только маленькие пакеты, т.к. от реализации всегда будет требоваться поддержка как минимум 1500 октетов.

Кратко формат Maximum-Receive-Unit показан ниже. Поля передаются с лева на право.

0 8 15/16 24 31


Type	Length	Maximum-Receive-Unit

Type

Length

Maximum-Receive-Unit

Поле Maximum-Receive-Unit состоит из двух октетов, и определяет максимальное число октетов в полях Information и Padding. Оно не включает фрейм, поле Protocol, FCS, ни любые другие прозрачные биты и байты.

6.2 Authentication-Protocol

Описание

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

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

Реализация НЕ ДОЛЖНА включать многочленные конфигурационные опции Authentication-Protocol в свои пакеты Configure-Request. Вместо этого ей СЛЕДУЕТ пытаться первой конфигурировать желательный протокол аутентификации. Если этот протокол запрошен с помощью Configure-Nak, тогда реализации СЛЕДУЕТ пробовать следующий наиболее желательный протокол в следующем пакете Configure-Request.

Реализация, посылающая Configure-Request показывает, что она ожидает аутентификацию от другой стороны. Если реализация посылает Configure-Ack, то она принимает аутентификацию по указанному протоколу. Реализации получившей Configure-Ack СЛЕДУЕТ ожидать аутентификации удаленной стороны по подтвержденному протоколу.

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

Краткий формат Authentication-Protocol Configuration Option показан ниже. Поля передаются с лева на право.

0 8 15/16 24 31


Type	Length	Authentication-Protocol

Data...

Type

Length

>= 4

Authentication-Protocol

Поле Authentication-Protocol состоит из двух октетов, и показывает желаемый протокол аутентификации. Значения для этого поля всегда те же самые, как для поля PPP Protocol для этого же самого протокола аутентификации.

Современные значения поля Authentication-Protocol указаны в RFC «Assigned Numbers» [2]. Текущие присвоенные значения:

Значение Протокол

c023 Password Authentication Protocol (PAP)

c223 Challenge Handshake Authentication Protocol (CHAP)

Data

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

6.3 Quality-Protocol

Описание

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

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

Реализация, посылающая Configure-Request, показывает, что ожидает получения информации мониторинга от удаленной стороны. Если реализация посылает Configure-Ack, то она принимает этот протокол. Реализации, получающей Configure-Ack, СЛЕДУЕТ ожидать от удаленной стороны отправки пакетов подтвержденного протокола.

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

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

0 8 15/16 24 31


Type	Length	Quality-Protocol

Data...

Type

Length

>= 4

Quality-Protocol

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

Современные значения поля Quality-Protocol указаны в RFC «Assigned Numbers» [2]. Текущие присвоенные значения:

Значение Протокол

c025 Link Quality Report

Data

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

6.4 Magic-Number

Описание

Эта конфигурационная опция предоставляет метод определения соединений с обратной петлей (looped-back links) и других аномалий канального уровня. Эта конфигурационная опция МОЖЕТ быть затребована некоторыми другими конфигурационными опциями, такими как Quality-Protocol. По умолчанию Magic-Number не согласовывается и вместо него используется ноль.

Перед тем как эта конфигурационная опция будет затребована, реализация ДОЛЖНА выбрать этот Magic-Number. Рекомендуется выбирать Magic-Number случайным образом, для того, чтобы гарантировать с высокой степенью вероятности, что реализация получить уникальный номер. Хороший способ выбрать уникальное случайное число, начать с уникального источника. Предложенные источники уникальности включают серийные номера машин, другие сетевые аппаратные адреса, показания часов и т.п. Чрезвычайно хороший источник случайных номеров это точное измерение интервалов между физическими событиями, такими как получение пакетов в других присоединенных сетях, время отклика сервера или скорость нажатия клавиш человеком.

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

Получение Configure-Nak с Magic-Number, отличным от того, что был послан удаленной стороне с последним Configure-Nak демонстрирует, что соединение не является петлевым и показывает уникальный Magic-Number. Если Magic-Number совпадает с последним посланным в пакете Configure-Nak, то вероятность существования петли на соединении увеличивается и ДОЛЖЕН быть выбран новый Magic-Number. В любом случае, новый Configure-Request должен быть послан с новым Magic-Number.

Если соединение действительно является петлевым, что последовательность (передать Configure-Request, получить Configure-Request, передать Configure-Nak, получить Configure-Nak) будет повторяться снова и снова. Если соединение не является петлевым, эта последовательность может произойти несколько раз, но очень маловероятно. Более вероятно, что Magic-Numbers, выбранные с обоих концов быстро разойдутся, прекратив последовательность. Следующая таблица показывает вероятность коллизий присвоения одинаковых Magic-Numbers с совершенно одинаковым распределением.

Число Вероятность коллизий

1 2.3 E-10

2 5.4 E-20

3 1.3 E-29

Для того, чтобы это случилось, требуется хороший источник уникальности или случайности. Если хороший источник уникальности не может быть найден, то рекомендуется не использовать эту конфигурационную опцию. Пакеты Configure-Request пакеты с этой опцией НЕ следует передавать, и любые Magic-Number посылаемые удаленной стороной СЛЕДУЕТ либо подтверждать, либо отбрасывать. В этом случае петлевые соединения не могут быть надежно определены реализацией, несмотря на это, они могут быть определены удаленной стороной.

Если реализация передает Configure-Request с конфигурационной опцией Magic-Number, то она НЕ ДОЛЖНА отвечать пакетом Configure-Reject, если получит Configure-Request с конфигурационной опцией Magic-Number. То есть если реализация желает использовать Magic-Number, то она ДОЛЖНА позволить удаленной стороне делать то же. Если реализация получила Configure-Reject в ответ на Configure-Request с конфигурационной опцией Magic-Number, то это означает, что соединение не является петлевым и что удаленная сторона не будет использовать Magic-Number. В этом случае реализации СЛЕДУЕТ действовать, как если бы согласование было успешным (как если бы был получен Configure-Ack).

Magic-Number так же может быть использована для определения петлевых соединений как в течении нормального функционирования так и в процессе согласования конфигурационных опций. Все пакеты LCP Echo-Request, Echo-Reply и Discard-Request имеют поле Magic-Number.

Поле Magic-Number в этих пакетах СЛЕДУЕТ проверять при их получении. Все полученные поля Magic-Number ДОЛЖНЫ быть равны либо нулю, либо уникальному Magic-Number стороны, в зависимости от того, согласовали стороны Magic-Number или нет.

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

Процедуры для восстановления в этом случае не описываются и могут отличаться от реализации к реализации. Несколько пессимистическая процедура - это предположить, что произошло событие LCP Down. Следующее событие Open начнет процесс повторного установления соединения, которое не сможет быть закончено до тех пор, пока не будут устранены условия возникновения петли и Magic-Numbers не будут успешно согласованы. Более оптимистичная процедура (в случае петлевого соединения) это начать передавать пакеты LCP Echo-Request до тех пор, пока не будут получены правильные пакеты Echo-Reply, указывающие на устранение условий возникновения петли.

Краткий формат Magic-Number показан ниже. Поля передаются слева направо.

0 8 15/16 24 31


Type	Length	Magic-Number
Magic-Number

Type

Length

Magic-Number

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

6.5 Protocol-Field-Compression (PFC)

Описание

Эта конфигурационная опция предоставляет метод согласовать компрессию PPP поля Protocol. По умолчанию, все реализации ДОЛЖНЫ передавать пакеты с двумя октетами поля Protocol.

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

Как уже говорилось выше, поле Protocol использует механизм расширения, не противоречащий механизму расширения ISO 3309 для поля Address. Младший значащий байт каждого октета (Least Significant Bit - LSB) используется, чтобы показать расширение поля Protocol. Бинарный «0» как LSB показывает, что поле продолжается в следующем октете. Присутствие «1» как LSB помечает последний октет поля Protocol. Заметьте, что любое число «0» октетов может быть представлено в поле и при этом показывать все то же значение (рассмотрите два бинарных представления для 3, 00000011 и 00000000 00000011).

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

Сжатые поля Protocol НЕ ДОЛЖНЫ передаваться пока не будет согласована эта конфигурационная опция. Когда она согласована, реализация PPP ДОЛЖНА принимать PPP пакеты двух типов, с двух-

октетным и одно-октетным полем Protocol и НЕ ДОЛЖНА видеть различий между ними.

Поле Protocol никогда не сжимается при отправке LCP пакетов. Это правило гарантирует недвусмысленное опознание LCP пакетов.

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

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

15/16


	Type	Length

Type

Length

6.6 Address-and-Control-Field-Compression (ACFC)

Описание

Эта опция предоставляет метод согласования компрессии полей канального уровня Address и Control. По умолчанию все реализации ДОЛЖНЫ передавать фреймы с полями Address и Control присущими методу фреймирования.

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

Если сжатый фрейм был получен при несогласованной опции Address-and-Control-Field-Compression, реализация МОЖЕТ быть отбросить фрейм.

Поля Address и Control НЕ ДОЛЖНЫ быть сжаты когда посылается LCP пакет. Это правило гарантирует недвусмысленное распознавание LCP пакетов.

Когда поля Address и Control сжаты, FCS на канальном уровне вычисляется по сжатому фрейму, а не по оригинальному несжатому фрейму.

Краткий формат конфигурационной опции Address-and-Control-Field-Compression показан ниже. Поля передаются с лева на право.

0 8 15/16 24 31


	Type	Length

Type

Length

7 Соображения безопасности

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

Ссылки

[1] Perkins, D., "Requirements for an Internet Standard Point-to- Point

Protocol", RFC 1547, Carnegie Mellon University, December 1993.

[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC

1340, USC/Information Sciences Institute, July 1992

Признания

Этот документ является продуктом Рабочей группы по протоколу точка-точка (Point-to-Point Protocol Working Group) Internet Engineering Task Force (IETF). Комментарии следует представлять на рассмотрение в лист рассылки ietf-ppp@merit.edu.

Многое из текста этого документа взято из требований рабочей группы [1], RFC 1171 и RFC 1172 Дрю Перкинсом (Drew Perkins) из Университета Карнеги Меллон (Carnegie Mellon University) и Руссом Хобби (Russ Hobby) из Калифорнийского университета в Дэвисе.

Вильям Симпсон (William Simpson) был преимущественно ответствен за введение последовательной терминологии и философии, и редизайн фазы согласования машин.

Много людей потратили существенное время на разработку РРР. Полный список людей слишком велик. Следующие люди заслуживают особую благодарность: Рик Адамс (Rick Adams), Кен Аделман (Ken Adelman), Фред Бакер (Fred Baker), Майк Баллард (Mike Ballard), Краиг Фокс (Craig Fox), Карл Фокс (Karl Fox), Фил Гросс (Phill Gross), Кори Хамзех (Kory Hamzeh), Дэвид Кауфман (David Kaufman), Марк Льюис (Mark Lewis), Джон ЛоВерсо (John LoVerso), Билл Мелон (Bill Melohn), Майк Паттон (Mike Patton), Грэг Сац (Greg Satz), Джон Шривер (John Shriver), Вернон Шривер (Vernon Schryver), и Ашер Валдфогел (Asher Waldfogel).

Специальная благодарность Morning Star Technologies за предоставление компьютерных ресурсов и сетевого доступа для написания этой спецификации.

Адрес кафедры

С рабочей группой можно контактировать через:

Fred Baker

Advanced Computer Communications

315 Bollay Drive

Santa Barbara, California 93117

fbaker@acc.com

Адрес редактора

Вопросы по этому документу могут быть направлены:

William Allen Simpson

Daydreamer

Computer Systems Consulting Services

1384 Fontaine

Madison Heights, Michigan 48071


	На главную
	Перевод Игорь Шеваров issh@onego.ru, 11.01.2005 Network Working Group W. Simpson, Editor Request for Comments: 1661 Daydreamer STD: 51 July 1994 Obsoletes: 1548 Category: Standards Track Протокол точка-точка Point-to-Point Protocol (PPP)

	Статус	этого документа

	Этот документ описывает стандарт Интернет для сообщества Интернет, обсуждения запросов и предложения по усовершенствованию. Для получения информации о статусе этого протокола обращайтесь к текущей версии "Internet Official Protocol Standards" (STD 1). Распространение этого документа не ограничено. К*раткий обзор* Point-to-Point Protocol (PPP) предоставляет стандартный метод для транспортировки мультипротокольных датаграмм через соединения точка-точка. PPP включает три основных компонента: 1. Метод инкапсуляции мультипротокольных датаграмм. 2. Протокол управления соединением (Link Control Protocol - LCP) 3. Семейство сетевых управляющих протоколов (Network Control Protocols - NCPs) для установления и конфигурирования протоколов сетевого уровня. Этот документ определяет организацию и методологию PPP и PPP-инкапсуляцию вместе с расширяемой опцией механизма согласования способного согласовать богатый ассортимент конфигурационных параметров и предоставить дополнительный набор функций управления. PPP Link Control Protocol (LCP) описан в терминах этого механизма. С*одержание* Статус этого документа ............................................................................................ 1 Краткий обзор ..................................................................................................... 1 Содержание ........................................................................................................ 1 1 Введение ......................................................................................................... 2 1.1 Соглашения ............................................................................................... 3 1.2 Терминология ............................................................................................ 3 2 PPP инкапсуляция ............................................................................................. 4 3 Работа РРР соединения ...................................................................................... 5 3.1 Обзор ........................................................................................................ 5 3.2 Фазная диаграмма ...................................................................................... 5 3.3 Фаза Link Dead ........................................................................................... 6 3.4 Фаза Link Establishment .............................................................................. 6 3.5 Фаза Authentication .................................................................................... 7 3.6 Фаза Network-Layer Protocol ........................................................................ 7 3.7 Фаза Link Termination ................................................................................. 7 4 Опциональный автомат согласования ................................................................. 8 4.1 Таблица переходов состояний ..................................................................... 9 4.2 Состояния ............................................................................................... 10 4.3 События .................................................................................................. 11

	1



	4.4 Действия ................................................................................................. 14 4.5 Предотвращение петель. . ......................................................................... 16 4.6 Счетчики и таймеры ................................................................................. 16 5 Форматы пакетов LCP.. .................................................................................... 17 5.1 Configure-Request ..................................................................................... 18 5.2 Configure-Ack ........................................................................................... 19 5.3 Configure-Nak .......................................................................................... 19 5.4 Configure-Reject ....................................................................................... 21 5.5 Terminate-Request и Terminate-Ack ............................................................ 21 5.6 Code-Reject ............................................................................................. 22 5.7 Protocol-Reject ......................................................................................... 23 5.8 Echo-Request и Echo-Reply ........................................................................ 24 5.9 Discard-Request ........................................................................................ 25 6 Конфигурационные опции LCP ......................................................................... 26 6.1 Maximum-Receive-Unit (MRU) ..................................................................... 27 6.2 Authentication-Protocol .............................................................................. 28 6.3 Quality-Protocol ........................................................................................ 29 6.4 Magic-Number .......................................................................................... 30 6.5 Protocol-Field-Compression (PFC) ................................................................ 32 6.6 Address-and-Control-Field-Compression (ACFC) ............................................ 33 7 Соображения безопасности ............................................................................. 34 Ссылки ................................................................................................................. 34 Признания ............................................................................................................ 34

	1 Введение РРР разработан для простых линий связи, которые транспортируют пакеты между двумя равноправными узлами. Эти соединения предоставляют полнодуплексное двунаправленное функционирование и берут на себя последовательную доставку пакетов. Предполагается, что РРР предоставляет общее решение для простого соединения территориально разнесенных хостов, мостов и маршрутизаторов [1]. Инкапсуляция РРР - инкапсуляция предусмотрена для мультиплексирования различных протоколов сетевого уровня в одно соединение. РРР – инкапсуляция была разработана для сохранения совместимости с большинством наиболее часто используемого аппаратного обеспечения. Только 8 дополнительных октетов необходимы для формирования инкапсуляции при использовании в рамках HDLC-подобного фреймирования. В условиях, когда полоса пропускания не велика инкапсуляция и фреймирование могут быть сокращены до 2 или 4 октетов. Для поддержки высокоскоростных реализаций, инкапсуляция по умолчанию использует только простые поля, только одно из которых должно быть рассмотрено для выполнения демультиплексирования. Заголовок по умолчанию и информационные поля находятся в 32-битных границах. Трейлер так же может быть добавлен в произвольных границах. Протокол управления соединением (Link Control Protocol-LCP) Для обеспечения достаточной универсальности и переносимости в широком спектре окружений, РРР предоставляет протокол управления соединением (Link Control Protocol-LCP). LCP используется для автоматического установления опций формата инкапсуляции, управления различными ограничениями в размерах пакетов, детектирования петлей в соединении и других ошибок конфигурирования и терминирования соединения. Другие дополнительные возможности предоставляются для

	2



	3.5 Фаза Authentication В некоторых случаях желательно запросить удаленную сторону аутентифицировать себя, перед тем как позволить протоколу сетевого уровня начать обмен пакетами. По умолчанию, аутентификация не обязательна. Если реализация желает, чтобы удаленная сторона была аутентифицирована с использованием специфического протокола аутентификации, то она ДОЛЖНА запросить использование этого протокола аутентификации в течение фазы Link Establishment. Аутентификацию СЛЕДУЕТ провести после установления соединения как можно быстрее, насколько это возможно. Тем не менее, определение качества соединения МОЖЕТ проходить одновременно. Реализация МОЖЕТ НЕ позволить обмен пакетами определения качества соединения, чтобы задерживать аутентификацию бесконечно. Если аутентификация неудачна, СЛЕДУЕТ перейти к фазе Link Termination. В данной фазе может происходить обмен пакетами LCP, протокола аутентификации и пакетами мониторинга качества соединения. Все пакеты других протоколов, полученные в течение этой фазы, должны быть отброшены. Примечание: Реализации НЕ СЛЕДУЕТ считать неудачной аутентификацию по истечении таймаута или при отсутствии ответа. Аутентификации СЛЕДУЕТ позволять несколько методов повторной передачи и выполнять фазу Link Termination только при превышении некоторого числа попыток. За начало фазы Link Termination ответственна та реализация, которая отклонила аутентификацию удаленной стороне. 3.6 Фаза Network-Layer Protocol После того как РРР закончил предыдущую фазу, каждый протокол сетевого уровня (такой как IP, IPX, или AppleTalk) ДОЛЖЕН быть отдельно сконфигурирован соответствующим протоколом управления сетью (Network Control Protocol - NCP). Каждый NCP может быть в состоянии Opened или Closed. Примечание: Так как реализация в начальной стадии может использовать значительное количество времени на определение качества соединения, реализации СЛЕДУЕТ избегать фиксированных таймаутов при ожидании конфигурирования сторонами NCPs. После того как NCP достигнет состояния Opened, РРР будет переносить пакеты соответствующего протокола сетевого уровня. Любые пакеты поддерживаемых протоколов сетевого уровня, полученные до того как соответствующий NCP достигнет состояния Opened, ДОЛЖНЫ быть отброшены. Примечание: Пока LCP в состоянии Opened, любой пакет неподдерживаемого реализацией протокола ДОЛЖЕН быть возвращен в Protocol-Reject (описан ниже). Только поддерживаемые протоколы должны отбрасываться. В течение этой фазы, трафик соединения состоит из любой возможной комбинации пакетов LCP,NCP, и протокола сетевого уровня. 3.7 Фаза Link Termination РРР может завершить соединение в любое время. Это может произойти потому, что потеряна связь, произошел сбой аутентификации, ухудшилось

	7



	качество соединения. Истечение периода бездействия или административное закрытие соединения. LCP используется для закрытия соединения через обмен пакетами Terminate. Когда соединение закрыто, РРР сообщает протоколам сетевого уровня, что они могут осуществить соответствующее действие. После обмена пакетами Terminate, реализации СЛЕДУЕТ сигнализировать физическому уровню об отсоединении, чтобы заставить соединение завершится, особенно в случае со сбоем аутентификации. Отправителю пакета Terminate-Request СЛЕДУЕТ отключиться после получения пакета Terminate-Ack или по истечении счетчика Restart. Получателю пакета Terminate-Request СЛЕДУЕТ ждать отключения удаленной стороны и он НЕ ДОЛЖЕН отключаться пока не пройдет как минимум один интервал Restart после отправки Terminate-Ack. РРР СЛЕДУЕТ перейти в фазу Link Dead. Все не LCP-пакеты, полученные в течение этой фазы ДОЛЖНЫ быть отброшены. Примечание: Закрытие соединения с помощью LCP является достаточным. NCP нет необходимости слать шквалы пакетов Terminate. Напротив, тот факт, что NCP закрыт, не является достаточным основанием для закрытия РРР соединения, даже если этот NCP в настоящее время единственным в состоянии Opened. 4 Опциональный автомат согласования Конечный автомат определен событиями, действиями и переходами состояний. События включают в себя получение внешних команд, таких как Open и Close, истечение таймера Restart, прием пакетов от удаленной стороны. Действия включают в себя запуск таймера Restart и передача пакетов удаленной стороне. Некоторые типы пакетов - Configure-Naks и Configure-Rejects, или Code-Rejects и Protocol-Rejects, или Echo-Requests, Echo-Replies и Discard-Requests не различаются в описаниях автомата. Как будет показано ниже, эти пакеты действительно обслуживают различные функции. Однако они вызывают одни и те же переходы.

	События Up = lower layer is Up Down = lower layer is Down Open = administrative Open Close= administrative Close TO+ = Timeout with counter > 0 TO- = Timeout with counter expired RCR+ = Receive-Configure-Request (Good) RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack RCN = Receive-Configure-Nak/Rej RTR = Receive-Terminate-Request RTA = Receive-Terminate-Ack RUC = Receive-Unknown-Code RXJ+ = Receive-Code-Reject (permitted) or Receive-Protocol-Reject RXJ- = Receive-Code-Reject (catastrophic) or Receive-Protocol-Reject RXR = Receive-Echo-Request or Receive-Echo-Reply or Receive-Discard-Request	Действия tlu = This-Layer-Up tld = This-Layer-Down tls = This-Layer-Started tlf = This-Layer-Finished irc = Initialize-Restart-Count zrc = Zero-Restart-Count scr = Send-Configure-Request sca = Send-Configure-Ack scn = Send-Configure-Nak/Rej str = Send-Terminate-Request sta = Send-Terminate-Ack scj = Send-Code-Reject
		ser = Send-Echo-Reply

	8



	4.5 Предотвращение петель. Протокол делает разумные попытки избавится от петель согласования конфигурационных опций. Однако протокол НЕ гарантирует, что эти петли не будут появляться. Как в случае с любым согласованием, можно сконфигурировать две реализации РРР с конфликтующими политиками, которые никогда не перекроются. Также можно сконфигурировать политики, которые позволяют перекрывание, но сделают это за значительный промежуток времени. Разработчики должны иметь это ввиду, им также СЛЕДУЕТ реализовать механизм детектирования петель или высокоуровневых таймаутов. 4.6 Счетчики и таймеры Таймер Restart В автомате используется один таймер. Таймер Restart используется для измерения времени передачи пакетов Configure-Request и Terminate-Request. Истечение этого таймера вызывает событие Timeout и повторную передачу пакетов Configure-Request или Terminate-Request. Таймер Restart ДОЛЖЕН быть конфигурируемым, но по умолчанию СЛЕДУЕТ установить значение три (3) секунды. Замечания по реализации: СЛЕДУЕТ установить зависимость таймера Restart от скорости соединения. Значение по умолчанию выбрано для низкоскоростных (от 2400 до 9600 bps) коммутируемых соединений с низкой латентностью (типичная телефонная линия). Для высокоскоростных соединений или соединений с низкой латентностью СЛЕДУЕТ выбирать меньшие значения. Вместо постоянного значения, таймер Restart МОЖЕТ начинать с начального маленького значения и повышать его до сконфигурированного конечного значения. Каждое последующее значение, меньшее финального, СЛЕДУЕТ применять как минимум в два раза больше предыдущего. Начальному значению СЛЕДУЕТ быть достаточно большим, чтобы покрывать двойное время передачи пакета при текущей скорости соединения и как минимум 100 миллисекунд, чтобы позволить удаленной стороне обработать пакет перед ответом. Некоторые линии добавляют еще 200 миллисекунд спутниковой задержки. Двойное время передачи для модемов, работающих на скорости 14400 bps от 160 до 600 миллисекунд. Max-Terminate Счетчик Max-Terminate показывает число отправленных пакетов Max-Terminate без получения Terminate-Ack, перед тем как будет сделан вывод о том, что удавленная сторона не отвечает. Счетчик Max-Terminate ДОЛЖЕН быть конфигурируемым. Значение по умолчанию следует установить в две (2) отправки. Max-Configure Счетчик Max-Configure показывает число отправленных пакетов Configure-Request без получения пакетов Configure-Ack, Configure-Nak или Configure-Reject, перед тем как будет сделан вывод о том, что удавленная сторона не отвечает. Счетчик Max-Configure ДОЛЖЕН быть конфигурируемым. Значение по умолчанию СЛЕДУЕТ установить в десять (10) отправок. Max-Failure

	16



Счетчик Max-Failure показывает число отправленных пакетов Configure-Nak без получения пакета Configure-Ack перед тем как будет сделан вывод о том, что конфигурация не сходится. Любые дополнительные пакеты Configure-Nak для опций, запрошенных удаленной стороной будут преобразованы в пакеты Configure-Reject и опции, требуемые локально больше не применяются. Счетчик Max-Failure ДОЛЖЕН быть конфигурируемым. Значение по умолчанию СЛЕДУЕТ установить в пять (5) отправок.

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

Существует три класса пакетов LCP: 1. Пакеты конфигурации линии, используемые для установления и конфигурирования соединения (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject). 2. Пакеты завершения соединения (Terminate-Request и Terminate-Ack). 3. Пакеты обслуживания и отладки соединения (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request). В интересах упрощения, в пакетах отсутствует поле версии LCP пакета. Правильно функционирующая реализация LCP будет всегда отвечать на незнакомые Protocols и Codes легко узнаваемым LCP пакетом, предоставляя, таким образом, детерминированный механизм нейтрализации неисправности для реализаций других версий. Несмотря на разрешенные конфигурационные опции, все пакеты LCP Link Configuration, Link Termination и Code-Reject (коды от1 до 7) всегда посылаются как если бы конфигурационные опции не были согласованы. В частности каждая конфигурационная опция содержит значения по умолчанию. Это гарантирует, что такие LCP пакеты всегда будут опознаваемы, даже если один конец соединения ошибочно считает, что соединение отрыто. В поле PPP Information инкапсулируется ровно один LCP пакет, если поле Protocol показывает тип 0хc021 (Link Control Protocol). Формат пакета LCP показан ниже. Поля передаются с лева направо.

о	8		15/16	24	31

Code		Identifier		Length

Data ...

Code

Поле Code имеет длину один октет и идентифицирует тип LCP пакета. Когда получен пакет с неизвестным полем Code, передается пакет Code-Reject. Современные значения поля Code определены в «Assigned Numbers» RFC [2]. Этот документ затрагивает следующие значения: 1. Configure-Request 2. Configure-Ack

17



3. Configure-Nak 4. Configure-Reject 5. Terminate-Request 6. Terminate-Ack 7. Code-Reject 8. Protocol-Reject 9. Echo-Request 10. Echo-Reply 11. Discard-Request Identifier Поле Identifier имеет длину один октет и помогает в согласовании запросов и ответов. Когда получен пакет с неверным полем Identifier, пакет отбрасывается без воздействия на автомат. Length Поле Length состоит из двух октетов и показывает длину LCP пакета. Значение поля Length НЕ ДОЛЖНО превышать MRU на соединении. Октеты за пределами диапазона, заданного полем Length трактуются как заполнение и игнорируются при приеме пакета. Если поступает пакет с неверным значением поля Length, то он отбрасывается без воздействия на автомат.

Data

Поле Data имеет ноль или большее число октетов, в соответствии со значением поля Length. Формат поля Data зависит от поля Code.

5.1 Configure-Request Описание

Реализация, желающая открыть соединение ДОЛЖНА передать Configure-Request. Поле Options заполняется любыми желательными значениями, изменяющими значения по умолчанию. При получении пакета Configure-Request ДОЛЖНО быть отправлено соответствующее значение. Краткий формат пакета Configure-Request показан ниже. Поля передаются слева направо. 0 8 15/16 24 31

Code	Identifier	Length

Options ...

Code Для Configure-Request равно 1. Identifier Поле Identifier должно изменяться всякий раз, когда меняется содержание поля Options и всякий раз, когда поступает допустимый ответ на предыдущий запрос. При повторной отправке Identifier МОЖЕТ оставаться неизменным.

Options

18



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

5.2 Configure-Ack Описание

Если каждая конфигурационная опция, полученная в Configure-Request, опознана и все значения приемлемы, то реализация ДОЛЖНА отправить Configure-Ack. Подтвержденные конфигурационные опции НЕ ДОЛЖНЫ быть переупорядочены или изменены другим путем. При получении Configure-Ack поле Identifier должно совпадать со значением, переданным в Configure-Request. Кроме того, конфигурационные опции в Configure-Ack и последнем переданном пакете Configure-Request должны точно совпадать. Неверные пакеты отбрасываются. Краткий формат пакета Configure-Ack показан ниже. Поля передаются с лева на право. 0 8 15/16 24 31

Code	Identifier	Length

Options ...

Code 2 для Configure-Ack. Identifier Поле Identifier копирует поле в пакете Configure-Request, в ответ на который отправляется Configure-Ack. Options Поле Options имеет переменную длину и содержит ноль или более конфигурационных опций, которые отправитель желает подтвердить. Все конфигурационные опции всегда подтверждаются одновременно.

5.3 Configure-Nak Описание

Если полученные конфигурационные опции опознаваемы, но некоторые значения не приемлемы, реализация ДОЛЖНА передать пакет Configure-Nak. Поле Options заполняется только неприемлемыми конфигурационными опциями из пакета Configure-Request. Приемлемые конфигурационные опции отфильтрованы в Configure-Nak, иначе конфигурационные опции из пакета Configure-Request ДОЛЖНЫ быть повторно согласованы. Опции, не имеющие никаких значений (булевских опций) ДОЛЖНЫ использовать Configure-Reject при ответе.

19



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

5.4 Configure-Reject Описание

Если некоторые конфигурационные опции получены в пакете Configure-Request и не могут быть опознаны или неприемлемы при согласовании (как сконфигурировано сетевым администратором), то реализация ДОЛЖНА передать Configure-Reject. Поле Options заполнено только неприемлемыми конфигурационными опциями из Configure-Request. Все узнаваемые и согласуемые конфигурационные опции отфильтровываются из Configure-Reject, иначе конфигурационные опции НЕ ДОЛЖНЫ быть переупорядочены или модифицированы любым путем. При принятии Configure-Reject поле Identifier ДОЛЖНО совпадать с тем, что было передано в последнем Configure-Request. В дополнение, конфигурационные опции в пакете Configure-Reject ДОЛЖНЫ быть правильным подмножеством тех, что были в последнем Configure-Request. Неправильные пакеты отклоняются. Получение правильного Configure-Reject показывает, что когда новый Configure-Request будет послан, он НЕ ДОЛЖЕН включать любую из опций, содержащихся в Configure-Reject. Кратко формат пакета Configure-Reject показан ниже. Поля передаются с лева направо.

о	8		15/16	24	31

Code		Identifier		Length

Options ...

Code 4 для Configure-Reject. Identifier Поле Identifier копирует поле Identifier пакета Configure-Request, который вызвал отправку Configure-Reject. Options Поле имеет переменную длину, и содержит список из нуля или более конфигурационных опций, которые отправитель отверг. Все конфигурационные опции всегда отвергаются одновременно. 5.5 Terminate-Request и Terminate-Ack Описание LCP включает пакеты Terminate-Request и Terminate-Ack для предоставления механизма закрытия соединения.

21



Identifier Поле Identifier должно изменяться при каждой отправке Protocol-Reject. Rejected-Protocol Поле Rejected-Protocol состоит из двух октетов, которые содержат поле PPP Protocol пакета, который был отброшен. Rejected-Information Поле Rejected-Information содержит копию пакета, который был отброшен. Оно начинается с поля Information и не включает ни заголовки канального уровня, ни FCS. Поле Rejected-Information ДОЛЖНО быть усечено для соблюдения MRU, установленного удаленной стороной. 5.8 Echo-Request и Echo-Reply Описание LCP включает коды Echo-Request и Echo-Reply, чтобы предоставить канальному уровню механизм обратной петли для проверки обоих направлений соединения. Он может быть использован для отладки, определения качества линии, тестирования производительности и во множестве других функций. При получении пакета Echo-Request, когда LCP находится в состоянии Opened, ДОЛЖЕН быть отправлен пакет Echo-Reply. Пакеты Echo-Request и Echo-Reply ДОЛЖНЫ посылаться только когда LCP находится в состоянии Opened. В любых других состояниях они должны отбрасываться. Кратко формат пакетов Echo-Request и Echo-Reply показан ниже. Поля передаются слева направо.

о	8		15/16	24	31

Code		Identifier		Length

Magic-Number

Data ...

Code 9 для Echo-Request; 10 для Echo-Reply. Identifier При передаче, поле Identifier ДОЛЖНО быть изменено, когда меняется содержимое поля Data или когда был получен допустимый ответ на предыдущий запрос. При повторной передаче поле МОЖЕТ не изменяться. При получении Echo-Request, поле Identifier копируется в поле Identifier пакета Echo-Reply.

24



	Data Поле Data состоит из нуля или больше октетов и содержат дополнительные данные, зависящие от протокола. 6.4 Magic-Number Описание Эта конфигурационная опция предоставляет метод определения соединений с обратной петлей (looped-back links) и других аномалий канального уровня. Эта конфигурационная опция МОЖЕТ быть затребована некоторыми другими конфигурационными опциями, такими как Quality-Protocol. По умолчанию Magic-Number не согласовывается и вместо него используется ноль. Перед тем как эта конфигурационная опция будет затребована, реализация ДОЛЖНА выбрать этот Magic-Number. Рекомендуется выбирать Magic-Number случайным образом, для того, чтобы гарантировать с высокой степенью вероятности, что реализация получить уникальный номер. Хороший способ выбрать уникальное случайное число, начать с уникального источника. Предложенные источники уникальности включают серийные номера машин, другие сетевые аппаратные адреса, показания часов и т.п. Чрезвычайно хороший источник случайных номеров это точное измерение интервалов между физическими событиями, такими как получение пакетов в других присоединенных сетях, время отклика сервера или скорость нажатия клавиш человеком. При получении Configure-Request с конфигурационной опцией Magic-Number, полученный Magic-Number сравнивается с Magic-Number последнего посланного удаленной стороне пакета Configure-Request. Если два Configure-Request отличаются, то соединение не считается петлевым, и Magic-Number СЛЕДУЕТ подтвердить. Если два Magic-Number равны, то возможно соединение является петлевым, (но не точно), и полученный Configure-Request является одним из последних отправленных. Чтобы это определить, ДОЛЖЕН быть отправлен Configure-Nak с указанием другого значения Magic-Number. Новый Configure-Request НЕ СЛЕДУЕТ отправлять удаленной стороне, пока нормальный порядок работы не заставит сделать это (т.е. пока Configure-Nak не получен или пока не истечет таймер Restart). Получение Configure-Nak с Magic-Number, отличным от того, что был послан удаленной стороне с последним Configure-Nak демонстрирует, что соединение не является петлевым и показывает уникальный Magic-Number. Если Magic-Number совпадает с последним посланным в пакете Configure-Nak, то вероятность существования петли на соединении увеличивается и ДОЛЖЕН быть выбран новый Magic-Number. В любом случае, новый Configure-Request должен быть послан с новым Magic-Number. Если соединение действительно является петлевым, что последовательность (передать Configure-Request, получить Configure-Request, передать Configure-Nak, получить Configure-Nak) будет повторяться снова и снова. Если соединение не является петлевым, эта последовательность может произойти несколько раз, но очень маловероятно. Более вероятно, что Magic-Numbers, выбранные с обоих концов быстро разойдутся, прекратив последовательность. Следующая таблица показывает вероятность коллизий присвоения одинаковых Magic-Numbers с совершенно одинаковым распределением.

	30



	Число Вероятность коллизий 1 2.3 E-10 2 5.4 E-20 3 1.3 E-29 Для того, чтобы это случилось, требуется хороший источник уникальности или случайности. Если хороший источник уникальности не может быть найден, то рекомендуется не использовать эту конфигурационную опцию. Пакеты Configure-Request пакеты с этой опцией НЕ следует передавать, и любые Magic-Number посылаемые удаленной стороной СЛЕДУЕТ либо подтверждать, либо отбрасывать. В этом случае петлевые соединения не могут быть надежно определены реализацией, несмотря на это, они могут быть определены удаленной стороной. Если реализация передает Configure-Request с конфигурационной опцией Magic-Number, то она НЕ ДОЛЖНА отвечать пакетом Configure-Reject, если получит Configure-Request с конфигурационной опцией Magic-Number. То есть если реализация желает использовать Magic-Number, то она ДОЛЖНА позволить удаленной стороне делать то же. Если реализация получила Configure-Reject в ответ на Configure-Request с конфигурационной опцией Magic-Number, то это означает, что соединение не является петлевым и что удаленная сторона не будет использовать Magic-Number. В этом случае реализации СЛЕДУЕТ действовать, как если бы согласование было успешным (как если бы был получен Configure-Ack). Magic-Number так же может быть использована для определения петлевых соединений как в течении нормального функционирования так и в процессе согласования конфигурационных опций. Все пакеты LCP Echo-Request, Echo-Reply и Discard-Request имеют поле Magic-Number. Поле Magic-Number в этих пакетах СЛЕДУЕТ проверять при их получении. Все полученные поля Magic-Number ДОЛЖНЫ быть равны либо нулю, либо уникальному Magic-Number стороны, в зависимости от того, согласовали стороны Magic-Number или нет. Получение поля Magic-Number, равное согласованному локальному значению Magic-Number означает наличие петлевого соединения. Получение поля Magic-Number отличное от согласованного локального значения Magic-Number, согласованного значения Magic-Number удаленной стороны или нуля, если стороны его не согласовали, говорит о том, что соединение было расстроено для взаимодействия удаленной стороной. Процедуры для восстановления в этом случае не описываются и могут отличаться от реализации к реализации. Несколько пессимистическая процедура - это предположить, что произошло событие LCP Down. Следующее событие Open начнет процесс повторного установления соединения, которое не сможет быть закончено до тех пор, пока не будут устранены условия возникновения петли и Magic-Numbers не будут успешно согласованы. Более оптимистичная процедура (в случае петлевого соединения) это начать передавать пакеты LCP Echo-Request до тех пор, пока не будут получены правильные пакеты Echo-Reply, указывающие на устранение условий возникновения петли. Краткий формат Magic-Number показан ниже. Поля передаются слева направо.

	31



	Length 2 7 Соображения безопасности Проблемы безопасности кратко обсуждаются в разделах, касающихся фазы Authentication, события Close и конфигурационной опции Authentication-Protocol. Ссылки [1] Perkins, D., "Requirements for an Internet Standard Point-to- Point Protocol", RFC 1547, Carnegie Mellon University, December 1993. [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992 Признания Этот документ является продуктом Рабочей группы по протоколу точка-точка (Point-to-Point Protocol Working Group) Internet Engineering Task Force (IETF). Комментарии следует представлять на рассмотрение в лист рассылки ietf-ppp@merit.edu. Многое из текста этого документа взято из требований рабочей группы [1], RFC 1171 и RFC 1172 Дрю Перкинсом (Drew Perkins) из Университета Карнеги Меллон (Carnegie Mellon University) и Руссом Хобби (Russ Hobby) из Калифорнийского университета в Дэвисе. Вильям Симпсон (William Simpson) был преимущественно ответствен за введение последовательной терминологии и философии, и редизайн фазы согласования машин. Много людей потратили существенное время на разработку РРР. Полный список людей слишком велик. Следующие люди заслуживают особую благодарность: Рик Адамс (Rick Adams), Кен Аделман (Ken Adelman), Фред Бакер (Fred Baker), Майк Баллард (Mike Ballard), Краиг Фокс (Craig Fox), Карл Фокс (Karl Fox), Фил Гросс (Phill Gross), Кори Хамзех (Kory Hamzeh), Дэвид Кауфман (David Kaufman), Марк Льюис (Mark Lewis), Джон ЛоВерсо (John LoVerso), Билл Мелон (Bill Melohn), Майк Паттон (Mike Patton), Грэг Сац (Greg Satz), Джон Шривер (John Shriver), Вернон Шривер (Vernon Schryver), и Ашер Валдфогел (Asher Waldfogel). Специальная благодарность Morning Star Technologies за предоставление компьютерных ресурсов и сетевого доступа для написания этой спецификации. Адрес кафедры С рабочей группой можно контактировать через: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 fbaker@acc.com Адрес редактора Вопросы по этому документу могут быть направлены: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071

	34