Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсач.docx
Скачиваний:
30
Добавлен:
04.06.2015
Размер:
75.95 Кб
Скачать

§1.6 Протоколы контроля сети (ncPs)

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

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

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

Глава 2. Инкапсуляция ppp §2.1. Принцип инкапсуляции

Инкапсуляция 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.