Протокол PPP

Протокол PPP (протокол "точка-точка", PPP) — набір стандартних протоколів, що забезпечують взаємодію програмного забезпечення віддаленого (дистанційного) доступу від різних постачальників. За допомогою підключення з підтримкою РРР можна виробляти підключення до віддалених мереж через будь-який сервер РРР, що підтримує цей промисловий стандарт. РРР також дозволяє комп'ютеру, на якому функціонує служба віддаленого доступу Windows 2000 Server, приймати запити і забезпечувати доступ до мережі клієнтам з програмним забезпеченням віддаленого доступу третіх фірм, відповідним стандартам РРР. Стандарти РРР також відкривають додаткові можливості, недоступні при старіших стандартах, наприклад Slip. РРР підтримує декілька методів аутентифікації, стискування і (шифрування даних).- Більшість реалізацій РРР дозволяють повністю автоматизувати послідовність входу в систему.

Загальний опис протоколу PPP

Компоненти PPP. РРР забезпечує метод передачі (дейтаграм) через послідовні канали зв'язку з безпосереднім з'єднанням типу "точка-точка" (point-to-point). Він включає три основні компоненти:

1. Метод інкапсуляції (метод формування дейтаграмм для передачі по послідовних каналах). РРР як базис для формування дейтаграмм при проходженні через канали з безпосереднім з'єднанням використовує кадри, подібні до кадрів процедури HDLC (High-level Data Link Control - управління каналом передачі даних високого рівня).

2.Розширюваний протокол контролю каналу (LCP) (Link Control Protocol). LCP призначений для організації, вибору конфігурації і перевірки з'єднання каналу передачі даних.

3.Сімейство протоколів контролю мережі NCP ((Network Control Protocols)). Служить для організації і вибору конфігурації різних протоколів мережевого рівня.

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

Основні принципи роботи

Для того, щоб організувати зв'язок через канал з безпосереднім з'єднанням, РРР, що ініціює, на початку відправляє пакети LCP для завдання конфігурації з'єднання, а також перевірки каналу передачі даних. Після того, як канал встановлений і пакетом LCP виконано необхідне узгодження факультативних засобів, РРР, що ініціює, відправляє пакети NCP, щоб вибрати і визначити конфігурацію одного або більш протоколів мережевого рівня. Як тільки конфігурація кожного вибраного протоколу визначена, дейтаграмми з кожного протоколу мережевого рівня можуть бути відправлені через даний канал. Канал зберігає свою конфігурацію до тих пір, поки пакети LCP або NCP явно не закриють його або доки не станеться яка-небудь зовнішня подія (наприклад, витече термін бездіяльності таймера або втрутиться який-небудь користувач).

Вимоги, визначувані фізичним рівнем

РРР може працювати через будь-який інтерфейс (DTE)/(DCE) (наприклад, EIA RS-232-c, EIA RS-422, EIA RS-423 і МСЕ-Т V.35). Єдиною абсолютною вимогою, яка пред'являє РРР, є вимога забезпечення дубльованих схем (або спеціально призначених, або перемиканих), які можуть працювати як в синхронному, так і в асинхронному послідовному режимі, прозорому для блоків даних канального рівня РРР. Протокол РРР не пред'являє яких-небудь обмежень, що стосуються швидкості передачі інформації, окрім тих, які визначаються використовуваним інтерфейсом DTE/DCE.

Канальний рівень PPP

РРР використовує принципи, термінологію і структуру блоку даних процедур HDLC (ISO 3309-1979) Міжнародної організації по стандартизації (ISO - International Organization for Standardization), модифікованих стандартом ISO 3309-1984/PDAD1 "Addendum 1:start/stop Trasmission". ISO 3309-1979 визначає структуру блоку даних HLDC для вживання в синхронних оточеннях. ISO 3309-1984/PDAD1 визначає запропоновані для стандарту ISO 3309-1979 модифікацій, які дозволяють його використання в асинхронних оточеннях. Процедури управління РРР використовують визначення і кодування керівників полів, стандартизованих ISO 4335-1979 і ISO 4335-1979/addendum 1-1979. Протокол PPP розроблений для каналів зв'язки, які транспортують пакети між двома одноранговими об'єктами. Ці канали забезпечують повнодуплексне одночасне двонаправлене функціонування і передають пакети у відповідному порядку. Передбачається, що PPP забезпечить загальне рішення для нескладного зв'язку широкої різноманітності хостов, мостів і маршрутизаторів.

Інкапсуляція

Інкапсуляція PPP забезпечує мультиплексування різних протоколів мережевого рівня одночасно в одному і тому ж каналі (ланці передачі даних - ЗПД). Метод інкапсуляції PPP розроблений для збереження сумісності з найчастіше використовуваними апаратними засобами підтримки.

Для проведення інкапсуляції при використанні за умовчанням кадрів, подібних до кадрів HDLC, необхідно лише 8 додаткових октетів. У системах, де потрібна підвищена пропускна спроможність, для інкапсуляція і формування кадрів виділяються лише 2 або 4 октети. Для забезпечення роботи високошвидкісних застосувань метод інкапсуляції за умовчанням використовує прості поля, лише одне з яких повинне досліджуватися при демультиплексуванні. За умовчанням заголовок і інформаційні поля вирівнюються до 32-бітових кордонів шляхом додавання хвостовика.

Протокол контролю каналу LCP

Протокол PPP для достатньої універсальності і застосовності до широкого різноманіття систем включає протокол контролю каналу LCP ((Link Control Protocol)). LCP використовується, щоб автоматично погоджувати опції формату інкапсуляції, змінювати межі розмірів пакетів, виявляти зациклення ланки і інші помилкові ситуації, пов'язані з відмінностями конфігурацій, і розривати зв'язок. Його інші додаткові засоби обслуговування - це аутентифікація ідентичності однорангового об'єкту на каналі і визначення, коли зв'язок функціонує належним чином, а коли - ні.

Класи пакетів LCP

Пакети для організації каналу зв'язку. Використовуються для організації і вибору конфігурації каналу. Пакети для завершення дії каналу. Використовуються для завершення дії каналу зв'язку. Пакети для підтримки працездатності каналу. Використовуються для підтримки і відладки каналу. Ці пакети використовуються для досягнення працездатності кожній з фаз LCP. Протоколи контролю мережі ((NCP)).

Конфігурація

Канали PPP досить легко конфігурується. Відповідно до проекту, всі загальні конфігурації мають стандартні значення по замовчуванню. Додаток може модернізувати значення, встановлені по замовчуванню, про що автоматично повідомляється одноранговому об'єкту без втручання оператора. Нарешті, оператор може явно задавати опції, які дозволяють каналу працювати в довкіллі, де інакше це було б неможливо.

Ця самоконфігурация здійснюється через розширюваний додатковий механізм узгодження, в якому кожне закінчення каналу повідомляє іншому свої можливості і вимоги. Хоча для протоколу LCP визначений додатковий механізм узгодження, описаний в даній специфікації, той же самий механізм використовується іншими протоколами контролю, зокрема сімейством (NCP).

Функціонування ланки PPP

Короткий огляд

Щоб встановити з'єднання по каналу типу "точка-точка", кожне закінчення каналу PPP повинне спочатку послати пакети LCP, щоб конфігурувати і протестувати канал даних. Після того, як зв'язок встановлений, одноранговий об'єкт може бути підданий аутентифікації. Потім PPP повинен послати пакети NCP, щоб вибрати і конфігурувати один або більш за протоколи мережевого рівня. Якщо кожен з вибраних протоколів мережевого рівня конфігурований, то по даному каналу з кожного протоколу мережевого рівня можна посилати дейтаграмми. Канал залишатиметься конфігурованим для зв'язку до тих пір, поки пакети LCP або NCP явно не закриють його або доки не станеться деяка зовнішня подія (завершення роботи неактивного таймера або втручання адміністратора мережі.

Діаграма стадій PPP

В процесі конфігурації, підтримки і завершення з'єднання "точка-точка", ланка передачі даних PPP проходить декілька різних стадій, які визначені в наступній спрощеній діаграмі стадій (на даній діаграмі відбиті не всі можливі переходи).

Діаграма стадій PPP по RFC 1661

Стадія "Вимкнено"

Зв'язок обов'язково починається і закінчується в стадії "Вимкнено". Коли зовнішня подія вказує, що фізичний рівень до використання готовий, PPP переходить до стадії "Встановлення зв'язку". У перебігу цієї стадії автомат LCP (розглядається нижчим) знаходиться в станах "Початкове" або "Старт". Перехід до стадії "Встановлення зв'язку" виконується по сигналу "Включення" автомату LCP. Примітка: Зазвичай, зв'язок повертається в цю стадію автоматично після роз'єднання модему. В разі інтенсивної роботи, ця стадія може бути надзвичайне короткою - лише для того, щоб виявити присутність пристрою.

Стадія "Встановлення зв'язку"

Щоб встановити зв'язок, використовується протокол (LCP) шляхом обміну пакетами вибору конфігурації. При завершенні обміну LCP входить в стан "Відкрито" (коли пакет "Запит конфігурації", описаний нижче, був посланий і отриманий). Всі опції конфігурації, якщо вони не змінені при узгодженні конфігурації, мають значення за умовчанням. Поважно відмітити, що з використанням LCP конфігуруються лише ті опції конфігурації, які є незалежними від специфічних протоколів мережевого рівня. Конфігурація індивідуальних протоколів мережевого рівня виконується відповідно до окремих протоколів контролю мережі ((NCP)) протягом стадії "Протокол мережевого рівня". Будь-які пакети, не відповідні протоколу LCP, отримані протягом цієї стадії, мають бути скинуті без повідомлення. Здобуття запиту конфігурації LCP викликає перехід із стадій "Протокол мережевого рівня" або "Аутентифікація" до стадії "Встановлення зв'язку".

Стадія "Аутентифікація"

На деяких каналах може виникнути необхідність підтвердження одноранговим об'єктом своєї достовірності перед дозволом обміну пакетами протоколу мережевого рівня. За умовчанням, встановлення достовірності не обов'язкове. Якщо додаток вимагає, щоб достовірність однорангового об'єкту підтверджувалася деяким певним протоколом аутентифікації, тоді воно повинне запрошувати використання цього протоколу аутентифікації протягом стадії "Встановлення зв'язку". Встановлення достовірності повинне проводитися якнайскоріше після встановлення зв'язку. Проте, одночасно може відбуватися визначення якості зв'язку. В цьому випадку додаток не повинен дозволяти обмін пакетами визначення якості зв'язку, щоб не затримувати встановлення достовірності на невизначений час. Перехід від стадії "Аутентифікація" до стадії "Протокол мережевого рівня" не повинен наставати до завершення аутентифікації. Якщо встановлення достовірності не виконане, то повинен статися перехід до стадії "Завершення зв'язку". Протягом даної стадії можуть передаватися лише пакети протоколу контролю зв'язку LCP, протоколу аутентифікації і контролю якості зв'язку. Всі інші пакети, отримані протягом цієї стадії, мають бути скинуті без повідомлення. Відмітимо, що додаток не повинен завершувати аутентифікацію по тайм-ауту або за відсутності відповіді. Встановлення достовірності повинне передбачати деякий метод повторної передачі і переходити до стадії "Завершення зв'язку" лише після того, як число спроб аутентифікації перевищить заданий поріг. Додаток, який не визнав достовірність однорангового об'єкту, ініціює стадію "Завершення зв'язку".

Стадія "Протокол мережевого рівня"

Коли PPP завершує попередні стадії, кожен протокол мережевого рівня (такий як IP, IPX або AppleTalk) має бути індивідуально конфігурований згідно з відповідним протоколом контролю мережі (NCP). Кожен NCP може бути відкритий і закритий у будь-який час. Після того, як NCP досяг стану "Відкрито", PPP передаватиме відповідні пакети протоколу мережевого рівня. Будь-які пакети протоколу мережевого рівня, отримані, коли NCP не знаходиться в стані "Відкрито", мають бути скинуті без повідомлення.

Стадія "Завершення зв'язку"

PPP може розірвати зв'язок у будь-який час. Це може статися через втрату носія, невизнання достовірності при аутентифікації, незадовільну якість зв'язку, виділення таймера незайнятого періоду або адміністративне закриття зв'язку. LCP закриває зв'язок шляхом обміну пакетами роз'єднання. Коли зв'язок закривається, PPP інформує протоколи мережевого рівня, щоб вони виконали відповідні дії. Після обміну пакетами роз'єднання додатку для ініціалізації завершення зв'язку слід сигналізувати фізичному рівня про роз'єднання, особливо в разі невизнанні достовірності при аутентифікації. Відправникові запиту роз'єднання слід відокремитися після здобуття підтвердження роз'єднання або після того, як витече лічильник перезапуску. Приймачу запиту на роз'єднання слід чекати, поки одноранговий об'єкт не відокремиться; він не повинен відокремлюватися до тих пір, поки після підтвердження роз'єднання не пройдет принаймні один період перезапуску. PPP слід перейти до стадії "Вимкнено". Будь-який пакет не LCP, отриманий протягом цієї стадії, має бути скинутий без повідомлення. Закриття каналу зв'язку за допомогою LCP є достатнім. Посилати потік пакетів роз'єднання в кожному NCP немає необхідності. Більш того, той факт, що один NCP закрився, не є достатньою причиною для роз'єднання каналу PPP, навіть якщо цей NCP був єдиним в той момент в стані "Відкрито".

Примітки

1. Протокол PPP (Point-to-Point Protocol) [ 12 червня 2016 у Wayback Machine.](рос.)

Див. також

• PPP

Посилання

• The Point-to-Point Protocol (PPP) [ 9 січня 2014 у Wayback Machine.]