<<
>>

Протокол РРР

Протокол Point-to-Point Protocol (РРР) (протокол канала связи с непосред­ственным соединением) был официально опубликован в 1993 г. и стал стандар­том для связи по последовательным каналам, например таким, которые при­меняют для обмена информацией между домашними компьютерами и Internet по коммутируемым телефонным линиям.
РРР имеет значительные преимуще­ства перед SLIP: компьютеры на противоположных концах соединения могут договариваться о параметрах сеанса связи и сообщать друг другу свои IP- адреса, которые в отличие от SLIP, могут назначаться динамически. Кроме формирования стандартных IP-пакетов данных, протокол РРР при­зван решать и другие проблемы, в том числе: • присвоение и управление IP-адресами; • асинхронное и синхронное бит-ориентированное формирование пакета дан­ных; • мультиплексирование протокола сети; • конфигурация канала связи; • проверка качества канала связи; • обнаружение ошибок; • согласование адреса сетевого уровня; • согласование протокола сжатия информации. Протокол РРР решает эти задачи путем обеспечения расширяемого прото­кола управления каналом (LCP - Link Control Protocol) и семейства протоколов управления сетью (NCP - Network Control Protocols), которые позволяют со­гласовывать факультативные параметры конфигурации и различные возмож­ности.
РРР реализует метод передачи дейтаграмм через последовательные кана­лы связи с непосредственным соединением. Протокол РРР содержит три ос­новных компонента: протокол управления каналом передачи данных высокого уровня (HDLC ), используемый в качестве базиса для формирования дейтаграмм при прохож­дении через каналы с непосредственным соединением; расширяемый протокол LCP - для организации, выбора конфигурации и про­верки соединения канала передачи данных; семейство протоколов NCP - для организации и выбора конфигурации раз­личных протоколов сетевого уровня.
РРР обеспечивает одновременное пользование множеством протоколов сетевого уровня. Основные принципы работы. Чтобы организовать связь через канал связи с непосредственным соединением, инициирующий РРР сначала отправ­ляет пакеты LCP для выбора конфигурации и (факультативно) проверки канала передачи данных. После того, как канал установлен и пакетом LCP проведено необходимое согласование факультативных средств, инициирующий РРР от­правляет пакеты NCP, чтобы выбрать и определить конфигурацию одного или более протоколов сетевого уровня. Как только конфигурация каждого выбран­ного протокола определена, дейтаграммы из каждого протокола сетевого уров­ня можно отправлять через данный канал. Канал сохраняет свою конфигура­цию для связи до тех пор, пока явно выраженные пакеты LCP или NCP не закроют этот канал или пока не произойдет какое-нибудь внешнее событие (на­пример, истечет срок бездействия таймера или вмешается какой-нибудь пользо­ватель). Требования к интерфейсам физического уровня. РРР может работать через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA RS-423 и CCITT V.35). Единственным требованием, которое предъявляет РРР, является обеспечение дублированных схем (либо специально назначенных, либо переключаемых), которые могут работать как в синхронном, так и в асинхрон­ном последовательном по битам режиме, прозрачном для блоков данных ка­нального уровня РРР. Протокол не предъявляет каких-либо ограничений, каса­ющихся скорости передачи информации, кроме тех, которые определены конкретным примененным интерфейсом DTE/DCE. Канальный уровень РРР. РРР использует принципы, терминологию и струк­туру блока данных процедур HDLC (ISO 3309-1979), модифицированных стан­дартом ISO 3309-1984/PDAD1 (Приложение 1: Стартстопная передача). ISO 3309-1979 определяет структуру блока данных HLDC для применения в синх­ронных режимах передачи. ISO 3309-1984/PDAD1 определяет предложенные для стандарта ISO 3309-1979 модификации, которые позволяют его использо­вание в асинхронных режимах.
Формат блока данных РРР приведен на рис. 5.12. Длина поля Flag составляет 1 байт; она указывает на начало или конец бло­ка данных. Эта последовательность состоит из бинарной последовательности 01111110 — (7Е)а. Длина поля Address тоже равна 1 байт; оно содержит бинарную последова­тельность 11111111- (FF)*, представляющую собой стандартный широковеща­тельный адрес. РРР не присваивает индивидуальных адресов станциям. Поле Control составляет 1 байт; содержит информацию о предоставляемых услугах. Длина поля Protocol равна 2 байт; его значение идентифицирует протокол, заключенный в информационном поле блока данных. Значения поля Protocol и соответствующие им пакеты представлены в табл. 5.6.
Рнс. 5.12. Формат кадра РРР

Таблица 5.6. Типы пакетов поля Protocol

Поле Data содержит дейтаграмму для протокола, заданного в поле протоко­ла. Конец информационного поля определяется замыкающей последователь­ностью Flag, перед которой размещается два байта поля FCS. Максимальная длина информационного поля по умолчанию равна 1500 байт. В соответствии с априорным соглашением, разрешающие реализации РРР могут использовать другие значения максимальной длины информационного поля. Поле проверочной последовательности блока данных FCS (Frame Check Sequence) обычно составляет 16 бит (2 байт). В соответствии с априорным соглашением, разрешающие реализации РРР для усиления степени защиты от ошибок могут использовать 32-битовое (4-байтовое) поле FCS. Протокол РРР инициируется, используя оба протокола LCP и NCP. Для РРР-соединения определено пять фаз: • организация канала (Dead Phase). Эта фаза определяет физическую го­товность канала прежде, чем может быть произведен обмен каких-либо дей­таграмм сетевого уровня (например IP).

В случае успешной инициализации физического уровня канал переходит в следующую фазу;• определение качества канала связи и согласование его конфигурации (Establish Phase). Эта фаза инициализирует протокол LCP и определяет пара­метры канала. Здесь проверяется канал, чтобы определить, является ли каче­ство канала достаточным для вызова протоколов сетевого уровня. Эта фаза завершается после того, как пакет подтверждения конфигурации (Configure АСК) будет принят на обоих концах канала. После этого канал считается от­крытым и переходит в фазу аутентификации (необязательно); • аутентификация (Authenticate Phase). В этой фазе аутентифицируются обе точки, используя протоколы PAP (Password Authentication Protocol) или CHAP (Challenge Handshake Authentication Protocol). Канал не переходит в сле­дующую фазу Network Phase до успешной аутентификации. Если же аутенти­фикация неуспешна, то канал переходит в фазу прекращения действия канала Terminate Phase; • согласование конфигурации протоколов сетевого уровня (.Network Phase). После того как LCP завершит фазу определения качества канала свя­зи, конфигурация сетевых протоколов может быть по отдельности выбрана соответствующими NCP. Сетевые протоколы могут быть в любой момент выз­ваны и освобождены для последующего использования. Если LCP закрывает данный канал, он информирует об этом протоколы сетевого уровня, чтобы они приняли соответствующие меры; • прекращение действия канала (Terminate Phase). Эта фаза закрывает РРР-канал административным путем. Иногда это происходит и из-за какого- нибудь физического события, такого, как плохое качество линии, потеря носи­теля или истечение периода бездействия таймера. Протокол LCP использует Terminate Request пакет для закрытия канала и сообщает соответствующим NCP, что канал закрыт. Протокол управления канала связи LCP (Link Control Protocol). LCP обес­печивает метод организации, выбора конфигурации, поддержания и окончания работы канала с непосредственным соединением. Существует три класса пакетов LCP: для организации канала связи.
Используются для организации и выбора кон­фигурации канала. для завершения действия канала. Применяются для завершения действия канала связи. для поддержания работоспособности канала. Используются для поддержа­ния и отладки канала. К таким пакетам относятся, например, пакеты LQR (Link Quality Report) и Echo Request/Reply, обеспечивающие мониторинг качества стандартного синхронного канала LQM (Link Quality Monitoring). LCP пакет передается в поле Information РРР-кадра. Формат пакета связи протокола LCP представлен на рис. 5.13.
Рис. 5.13. Формат пакета LCP

Поле Code определяет тип LCP-сообщения, содержащегося в поле данных. Ниже приведены некоторые общие примеры LCP пакетов для организации ка­нала. 1. Configure Request (Code = 1): а) открытие соединения; б) обмен параметрами конфигурации; в) прием оговоренных параметров от другой стороны. 2. Configure Ack (Code = 2): а) ответ на Configure Request; б) указание на то, что значения параметров, полученных в Configure Request, корректны; в) сигнализирует, что канал открыт по прибытию пакета. 3. Configure Nak (Code = 3) показывает, что значения параметров неприем­лемы. 4. Configure Reject (Code = 4): а) указывает, что некоторые из параметров неприемлемы; б) шлет новый Configure Request пакет без неправильных параметров, найденных в отвергнутом пакете. Поле Identifier определяет запросы и ответы. Поле Length указывает раз­мер LCP-пакета. Поле Data содержит конфигурационные параметры для паке­тов типа Configure Request и Configure Ack, определяемые полями Type, Length и Value. Всего может быть задано восемь параметров конфигурации. Поле Туре описывает параметры конфигурации для согласования, поле Length описывает их длину, а поле Value определяет значение параметров конфигурации для со­гласования. В табл. 5.7 представлены параметры конфигурации LCP.

Таблица 5.7.
Параметры конфигурации LCP

Семейство протоколов управления сетью NCP(Network Control Protocols). После фазы LCP в РРР-канале следует фаза согласования пара­метров, специфичных для каждого из протоколов сетевого уровня в NCP. Например, протокол IP требует от обоих концов обмена и приема соответству­ющих IP-адресов. NCP определяет, каким образом данные различных прото­колов расположены внутри РРР-кадра, что описано отдельным соглашением RFC, определяющим как данный протокол инкапсулируется в РРР-кадр. Каж­дый NCP устанавливает, обслуживает и закрывает использование определен­ного протокола. На рис. 5.14 показан пример NCP кодов, которые могут нахо­диться в поле Protocol РРР-кадра. Аутентификация для РРР описана в RFC 1334. Она использует два протокола РАР и CHAP. Последний наиболее распространен в современных сетях. СНАР- аутентификация является частью фазы установления соединения LCP и повто­ряется через определенные интервалы времени, когда РРР-канал установлен. CHAP выполняется на каждой стороне канала и каждой стороне назначается одинаковый открытый ключ - secret, на базе которого вычисляется уникальное значение Hash Value, помещаемое в пакет (рис. 5.15). Аутентификация реали­зуется по алгоритму с открытым ключом. Мониторинг качества канала LQM (Link Quality Monitoring). Монито­ринг поддерживается только на стандартных синхронных каналах. Качество канала определяется процентом успешно переданных или полученных пакетов в пределах отчетного периода. Эти пакеты называются LQR (Link Quality Report). Процедура LQM использует LQR-пакеты, содержащие счетчики для определения входного и выходного качества канала для входных и выходных пакетов. Отчетный период описывается в конфигурации. После пяти отчетных периодов LQM вычисляет среднее значение процента переданных и принятых пакетов и сравнивает его с пороговым значением. Если средний процент мень­ше, чем пороговое значение, то соответствующий NCP закрывается. В допол-нение к посылке LQR пакетов маршрутизатор может быть сконфигурирован для периодической посылки по каналу пакетов Echo Request. Если маршрути­затор послал определенное их количество и не получил ни одного пакета Echo Reply, то все NCP закрываются. Интервал между пакетами Echo Request и максимальное число пакетов оставшихся без ответа являются необязатель­ными параметрами. 5.5.

<< | >>
Источник: В .А. Галкин, Ю .А. Григорьев. Телекоммуникации и сети. 2003

Еще по теме Протокол РРР:

  1. Глава 4. Киотский протокол в Украине
  2. § 6. Протокол судебного заседания
  3. Судебные протоколы вообще
  4. Пример обработки протокола.
  5. Базовый протокол устранения проблемы с BSFF
  6. В. Г. Олифер, Н. А. Олифер. 54 Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 3-е изд, 2006
  7. Определение пятое
  8. Основания
  9. Определение семнадцатое
  10. 3.1. Общие положения
  11. Основания
  12. Основания
  13. §60. ЗАКЛЮЧЕНИЕ ДОГОВОРА
  14. Статья 1250. Объявление нотариусом секретного завещания
  15. Определение четвертое
  16. Определение шестое
  17. Определение десятое
  18. 12.4. Следователь и допрашиваемый как источники вербально-невербальной информации
  19. Основания
  20. Определение седьмое