Протоколы контроля сети (NCPs)
Каналы РРР имеют много проблем с используемым семейством сетевых протоколов. Например, назначение и управление адресов IP, которые являются проблемой даже в ЛВС, являются особенно трудными для коммутируемых каналов точка-точка (point-to-point). Эти проблемы решаются семейством протоколов контроля сети (NCPs - Network Control Protocols), каждый из которых отвечает за определенные функции, требуемые соответствующими протоколами сетевого уровня.
Каналы PPP достаточно легко конфигурируются. В соответствии c проектом, все общие конфигурации имеют стандартные значения по умолчанию. Приложение может модернизировать значения, установленные по умолчанию, о чем автоматически сообщается одноранговому объекту без вмешательства оператора. Наконец, оператор может явно задавать опции, которые позволяют каналу работать в окружающих средах, где иначе это было бы невозможно.
Эта самоконфигурация осуществляется через расширяемый дополнительный механизм согласования, в котором каждое окончание канала сообщает другому свои возможности и требования. Хотя для протокола LCP определен дополнительный механизм согласования, описанный в данной спецификации, тот же самый механизм используется другими протоколами контроля, в частности семейством NCPs.
ГЛАВА 2. ИНКАПСУЛЯЦИЯ PPP
Принцип инкапсуляции
Инкапсуляция PPP используется для прозрачной передачи дейтаграмм различных протоколов. Она требует указаний на начало и конец инкапсуляции.
|
|
|
В соответствии с RFC 1661 [1] протокольный блок данных PPP имеет следующий вид (где поле "Информация" - содержит данные, инкапсулируемые в РРР). Поля передаются слева направо.
Таблица 2.1.
Протокольный блок данных PPP
| Протокол (8/16 бит) | Информация | Дополнение |
Рассмотрим особенности использования данных полей подробнее.
§2.2. Поле "Протокол"
Поле "Протокол" (согласно RFC 1661) содержит один или два октета. Их значения идентифицируют вид дейтаграммы, вставленной в поле "Информация".
Наиболее значащие октеты поля передаются первыми.
Структура этого поля соответствует механизму расширения стандарта ISO 3309 для полей адреса. Все значения поля "Протокол" должны быть нечетными; наименее значащий бит наименее значащего октета должен равняться "1". Кроме того наименее значащий бит наиболее значащего октета должен равняется нулю.
Полученные кадры, которые не согласуются c этими правилами, должны расцениваться как кадры нераспознанного протокола.
Значения полей "Протокол" в диапазоне от 0*** до 3*** идентифицируют протокол сетевого уровня специальных пакетов, а значения от 8*** до b*** идентифицируют пакеты, принадлежащие соответствующим протоколам контроля сети (NCPs), если таковые имеются в наличии.
|
|
|
Значения полей "Протокол" в диапазоне от 4*** до 7*** используются для протоколов с низким объемом трафика, которые не соответствуют NCP. Значения полей "Протокол" в диапазоне от c*** до f*** идентифицируют пакеты протоколов уровня ЗПД (таких, как LCP).
Разработчики новых протоколов должны получить номер для разрабатываемого ими протокола в Отделе назначения номеров Internet (IANA - Internet Assigned Numbers Authority), по адресу IANA@isi.edu.
§2.3. Поле "Информация"
Поле "Информация" включает ноль или более октетов. Оно содержит дейтаграмму в соответствии с протоколом, указанным в поле "Протокол".
Максимальная длина поля "Информация", включая поле "Дополнение", но не включая поле "Протокол", называется максимальным размером блока (MRU - Maximum Receive Unit), который не должен превышать 1500 октетов. Приложения PPP путем согласования могут использовать другие значения MRU.
§2.4. Поле "Дополнение"
Поле "Информация" при передаче может дополняться произвольным числом октетов, вплоть до значения MRU. Каждый протокол должен иметь возможность отличать дополнительные октеты от реальной информации.
Дата добавления: 2020-01-07; просмотров: 102; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!