Структура кадра протокола ррр

Флаги. Двоичный код 01111110, обозначает начало и конец кадра.

Адрес. Имеет постоянное значение, равное 11111111.

Поле управления. Принимает значение, равное 00000011.

Протокол. Код, определяющий тип передаваемых данных.

Информация. Раздел, содержащий передаваемые данные.

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

Кадр PPP может содержать данные трех типов: IP‑датаграмму, поступившую (инкапсулированную) от протокола сетевого уровня, данные протокола управления соединением LCP, данные протокола управления сетью NCP.

Флаг	Адрес	Поле управления	Протокол	Информация
1	2	3	4	5
				Код	Идентификатор	Длина	Данные

Структура пакета протокола управления соединением LCP

Пакеты конфигурации соединений LCP. Предназначены для инициализации и установления соединения по протоколу РРР. Существуют четыре разновидности пакетов: «конфигурация - запрос» (Configure - Request), «конфигурация‑подтверждение» (Configure‑Ack), «конфигурация - неподтверждено» (Configure - Nak) и «конфигурация - отказ» (Configure - Reject).Для открытия соединения РРР требуется послать пакет «конфигурация - запрос». Поле данных пакета «конфигурация‑запрос» содержит список желательных вариантов настройки соединения. Компьютер (протокол РРР), получивший пакет «конфигурация‑запрос», обязан ответить на него. Если список желательных вариантов настройки соединения подходит РРР , в ответ посылается пакет «конфи-гурация‑подтверждение». Поле данных ответного пакет также содержит список вариантов конфигурации‑точную копию принятого.Если компьютер не способен выполнить какое‑либо условие желательной настройки соединения, он должен ответить пакетом «конфигурация‑неподтверждено». Поле данных этого пакета содержит список неподдерживаемых вариантов настройки. Протокол LCP также разрешает помещать в поле данных пакета «конфигурация‑неподтверждено» список дополнительных вариантов настройки соединения. Компьютер, получивший пакет «конфигурация‑неподтверждено», должен ответить на запрос любых дополнительных вариантов настройки.

Протокол РРР продолжает обмениваться пакетами до тех пор, пока оба участника соединения не придут к единому мнению по поводу конфигурации соединения. Модуль РРР, обнаруживший неизвестный ему вариант настройки в пакете‑запросе, обязан ответить пакетом «конфигурация‑отказ». Поле данных пакета «конфигурация - отказ» содержит список только неизвестных вариантов. Разница между вариантами, помещенными в поле данных пакетов «конфигурация‑отказ» и «конфигурация‑неподтверждено», состоит в том, что варианты «отказники» не подлежат дальнейшему обсуждению. Другими словами, РРР может изменить свое мнение о ранее неподтвержденном варианте конфигурации в процессе связи. В то же время варианты, перечисленные в пакете «конфигурация - отказ», больше никогда не будут запрашиваться.

Пакеты окончания сеанса связи РРР. Имеют две разновидности «окончание‑запрос» и «окончание - подтверждено». Обе разновидности пакетов полностью игнорируют поле данных. Протокол РРР требует, чтобы компьютер, получивший пакет «окончание‑запрос», всегда отвечал передачей пакета «окончание - подтверждено».

Пакеты управления соединением LCP. Используются для управления и отладки во время сеанса связи. Определено пять разновидностей пакетов: «код - отказ», «протокол - отказ» , “эхо‑запрос” , «эхо‑ответ» и «игнорировать‑запрос».

Пакет «код‑отказ» передается модулем РРР, принявший пакет с неизвестным полем «код». Поле данных этого пакета содержит копию поля данных принятого пакета с неизвестным полем «код». Однако эта копия включает только данные из поля «информация». Пакет «протокол‑отказ» передается в ответ на неопознанное значение поле «протокол» пакета РРР. Пакет «протокол‑отказ» содержит двухбайтовое поле, идентифицирующее неопознанный протокол, а также его «неопознанные данные» (Rejected - Information). Чтобы протестировать состояние канала связи, РРР шлет пакеты «эхо - запрос» и «эхо‑ответ». Модуль РРР, получивший пакет «эхо‑запрос», должен ответить пакетом «эхо‑ответ».

Пакет «игнорировать - запрос» предназначен для тестирования канала в одном направлении: от локального до удаленного компьютера.

Протокол управления сетью NCP. В процессе управления сетью РРР устанавливает параметры сетевого уровня. По окончании процесса РРР полностью готов к передаче данных вышележащим уровням и может начинать передачу данных. РРР может обслуживать несколько различных сетевых протоколов одновременно. Используя NCP, PPP может « на ходу» открыть новый или завершить обмен по старому сетевому протоколу. Например, РРР ведет обмен пакетами IP. В любой момент времени, не прекращая обмена пакетами IP, можно начать обмен по протоколу DECnet, пользуясь тем же последовательным соединением. Когда обмен пакетами DECnet станет не нужным, можно его завершить, не прекращая соединения по протоколу IP.

Таким образом, РРР при помощи NCP открывает, настаивает и завершает сетевые соединения для нескольких сетевых протоколов.

Вопрос №18.Протокол сетевого уровня IP.

Реализация IP‑протокола. IP‑протокол реализует датаграммный способ передачи данных. Он формирует (инкапсулирует) IP‑датаграмму, которая состоит из IP‑заголовка и данных. Размер IP‑заголовка всегда кратен 32‑битному слову, даже если для этого он должен дополниться до нужной величины. Он содержит всю необходимую для доставки инкапсулированных данных по сети информацию и равен 20 байтам. На рис. 49 приведен формат IP‑датаграммы. Она включает в себя следующие разделы.

Номер версии (VERS). Протокол Internet все время развивается. Первые четыре бита в IP‑заголовке (поле «номер версии») обозначают версию протокола Internet, который создал данную датаграмму. Когда формат данных протокола Internet меняется, номер его версии в датаграмме увеличивается, позволяя другим модулям IP отбрасывать датаграммы, обработать которые они не в состоянии из‑за устаревшего формата данных. Модуль IP, принявший IP‑датаграмму версии, которую он не может обработать, может сообщить об этом источнику. В настоящее время применяется версия IP‑протокола V.4.

0 15 16 31

Версия (VERS) 4 бита	Длина заголовка (HLEN) 4 бита	Тип службы (TOS) 8 битов		Общая длина пакета в байтах 16 битов
Идентификатор фрагмента 16 битов				Флаги 3 бита	Смещение фрагмента 13 битов
Время существования (TTL) 8 битов		Протокол 8 битов		Контрольная сумма заголовка 16 битов
IP- адрес источника 32 бита
IP- адрес получателя 32 бита
Опции (если есть)			Заполнение (при необход)
Данные