РРРoE з боку клієнта на базі операційної системи Windows

Однією з причин малого числа каналів зв'язку TCP/IP з безпосереднім з'єднанням була відсутність стандартного протоколу для передачі дейтаграм через послідовні лінії зв'язку. Для вирішення цієї проблеми і був розроблений протокол PPP (Point to Point Protocol - протокол каналу зв'язку з безпосереднім з'єднанням). Окрім розв’язання задачі формування стандартних пакетів даних IP для каналів з безпосереднім з'єднанням, РРР також повинен був вирішити інші проблеми, у тому числі привласнення та управління адресами IP, асинхронне (старт-стопне) і синхронне (біт-орієнтоване) формування пакета даних, конфігурацію каналу зв'язку, перевірку його якості, виявлення помилок, узгодження способу стискування інформації і так далі.

У РРР ці питання вирішуються шляхом використання протоколу управління каналом LCP (Link Control Protocol) і сімейства протоколів управління мережею NCP (Network Control Protocols), які дозволяють погоджувати параметри конфігурації і різні можливості. Сьогодні PPP, окрім IP, забезпечує підтримку також і інших протоколів, у тому числі IPX і DECnet.

Компоненти PPP

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

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

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

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

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

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

Для того, щоб організувати зв'язок через канал з безпосереднім з'єднанням, РРР на початку відправляє пакети LCР для завдання конфігурації з'єднання, а також перевірки каналу передачі даних. Після того, як канал встановлений і пакетом LCР виконано необхідне узгодження факультативних засобів, РРР відправляє пакети 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 Standards Organization), модифікованих стандартом ISO 3309-1984/PDAD1 "Addendum 1: Start/stop Trasmission" (Додаток 1: Стартстопна передача"). ISO 3309-1979 визначає структуру блока даних HLDC для застосування в синхронних оточеннях. ISO 3309-1984/PDAD1 визначає запропоновані для стандарту ISO 3309-1979 модифікацій, які дозволяють його використання в асинхронних оточеннях. Процедури управління РРР використовують визначення і кодування керівників полів, стандартизованих ISO 4335-1979 і ISO 4335-1979/Addendum 1-1979.

Протокол PPP розроблений для каналів зв'язку, які транспортують пакети між двома одноранговими об'єктами. Ці канали забезпечують повнодуплексне одночасне двонаправлене функціонування і передають пакети у відповідному порядку. Передбачається, що PPP забезпечить загальне рішення для нескладного зв'язку широкої різноманітності хостыв, мостів і маршрутизаторів [2].

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

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

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

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

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

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

Процес LCD проходить через чотири чітко розділени фази:

- Організація каналу і узгодження його конфігурації. Перш, ніж може бути здійснений обмін якими-небудь дейтаграмами мережного рівня (наприклад, IP), LCP спочатку повинен відкрити зв'язок і погоджувати параметри конфігурації. Ця фаза завершується після того, як буде відправлений і прийнятий пакет підтвердження конфігурації.

- Визначення якості каналу зв'язку. LCP забезпечує необов'язкову фазу визначення якості каналу, яка йде за фазою організації каналу і узгодження його конфігурації. У цій фазі перевіряється канал з метою з'ясування, чи є якість каналу достатньою для виклику протоколів мережного рівня. Ця фаза є повністю факультативною. LСP може затримати передачу інформації протоколів мережного рівня до завершення цієї фази.

- Узгодження конфігурації протоколів мережного рівня. Після того, як LСP завершить фазу визначення якості каналу зв'язку, відповідними NCP може бути вибрана конфігурація мережних протоколів, і вони можуть бути у будь-який момент викликані і звільнені для подальшого використання. Якщо LCP закриває цей канал, він інформує про це протоколи мережного рівня, щоб вони могли вжити відповідні заходи.

- Припинення дії каналу. LCP може у будь-який момент закрити канал. Це робиться за запитом користувача, але може статися також із-за якої-небудь фізичної події, такої, як втрата носія або закінчення періоду бездіяльності таймера.

Існує три класи пакетів LCP:

- Пакети для організації каналу зв'язку. Використовуються для організації і вибору конфігурації каналу.

- Пакети для завершення дії каналу. Використовуються для завершення дії каналу зв'язку.

- Пакети для підтримки працездатності каналу. Використовуються для підтримки і відладки каналу.

Ці пакети використовуються для досягнення працездатності кожної з фаз LCP.

Протоколи контролю мережі (NCPs)

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

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

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

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

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

3.1. Принцип інкапсуляції

Інкапсуляція PPP використовується для прозорої передачі дейтаграм різних протоколів. Вона вимагає вказівок на початок і кінець інкапсуляції.

Відповідно до RFC 1661 [1] протокольний блок даних PPP має наступний вигляд (де поле "Інформація" - містить дані, що інкапсулюються в РРР). Поля передаються зліва направо.

Табл. 1 Структура пакета РРР

Розглянемо особливості використання даних полів детальніше.

Поле "Протокол" (згідно RFC 1661) містить один або два октети. Їх значення ідентифікують вид дейтаграми, вставленої в поле "Інформація".

Найбільш значущі октети поля передаються першими.

Структура цього поля відповідає механізму розширення стандарту ISO 3309 для полів адреси. Усі значення поля "Протокол" мають бути непарними; найменш значущий біт найменш значущого октету повинен дорівнювати "1". Крім того, найменш значущий біт найбільш значущого октету повинен дорівнювати нулю.

Отримані кадри, які не узгоджуються з цими правилами, повинні розцінюватися як кадри нерозпізнаного протоколу.

Значення полів "Протокол" в діапазоні від 0*** до 3*** ідентифікують протокол мережного рівня спеціальних пакетів, а значення від 8*** до b*** ідентифікують пакети, що належать відповідним протоколам контролю мережі (NCPs), якщо такі є в наявності.

Значення полів "Протокол" в діапазоні від 4*** до 7*** використовуються для протоколів з низьким об'ємом трафіка, які не відповідають NCP. Значення полів "Протокол" в діапазоні від c*** до f*** ідентифікують пакети протоколів рівня ЛПД (таких, як LCP).

Значення поля "Протокол" визначаються в останньому виданні "Assigned Numbers RFC" [3]. Нині ця специфікація визначає наступні значення:

Табл. 2 Значення поля "Протокол"

Розробники нових протоколів повинні отримати номер для протоколу, що розробляється ними, у відділі призначення номерів Internet (IANA - Internet Assigned Numbers Authority), за адресою IANA@isi.edu.

Поле "Інформація" включає нуль або більше за октети. Воно містить дейтаграму відповідно до протоколу, вказаного в полі "Протокол".

Максимальна довжина поля "Інформація", включаючи поле "Доповнення", але не включаючи поле "Протокол", називається максимальним розміром блоку (MRU - Maximum Receive Unit), який не повинен перевищувати 1500 октетів. Додатки PPP шляхом узгодження можуть використовувати інші значення MRU.

Поле "Інформація" при передачі може доповнюватися довільним числом октетів, аж до значення MRU. Кожен протокол повинен мати можливість відрізняти додаткові октети від реальної інформації.

3.2. Формат кадру РРР при інкапсуляції

Табл. 3 Приклад формату кадру РРР при інкапсуляції

Розглянемо призначення вказаних полів [1].

Довжина послідовності "Прапор" дорівнює одному байту; вона вказує на початок або кінець блока даних. Ця послідовність має вигляд: 01111110.

Довжина поля "Адреса" дорівнює 1 байту; поле містить двійкову послідовність 11111111, що є стандартною широкомовною адресою. РРР не привласнює індивідуальних адрес станціям.

Поле "Управління" складає 1 байт і містить двійкову послідовність 00000011, яка вимагає від користувача передачі інформації непослідовним кадром. Передбачені послуги без встановлення з'єднання каналу зв'язку, аналогічні послугам LLC Type 1.

Довжина поля "Протокол" дорівнює 2 байтам (чи 1 байту); його значення ідентифікує протокол, що знаходиться в інформаційному полі блока даних. Більшість сучасних значень поля "Протокол" визначені в останньому випуску Assigned Numbers Request for Comments (RFC).

Довжина поля "Дані" - від нуля і більше; воно містить дейтаграму для протоколу, заданого в Поле протоколу (включає розглянуті вище поля "Інформація" і "Доповнення"). Кінець інформаційного поля визначається локалізацією замикаючої послідовності "прапор" і наданням двох байтів полю FCS. Максимальна довжина інформаційного поля за замовчуванням дорівнює 1500 байтам. Відповідно до апріорної угоди, реалізації РРР можуть використовувати інші значення максимальної довжини інформаційного поля.

Поле FCS

Поле перевірочної послідовності блока даних (FCS - frame check sequence) складає 16 біт (два байти). Відповідно до апріорної угоди реалізації РРР можуть використовувати 32-х бітове (чотирьохбайтове) поле FCS, щоб поліпшити процес виявлення помилок.

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

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

Потім PPP повинен послати пакети NCP, щоб вибрати і конфігурувати один або більше за протоколи мережного рівня. Якщо кожен з вибраних протоколів мережного рівня конфігурований, то по цьому каналу з кожного протоколу мережного рівня можна посилати дейтаграми.

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

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

Рісунок 1 - Діаграма стадій PPP

Основні характеристики цих стадій детальніше розглянуті нижче.

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

Перебуваючи у цієї стадії автомат LCP (розглядається нижче) знаходиться в станах "Початкове" або "Старт". Перехід до стадії "Встановлення зв'язку" виконується за сигналом "Включення" автомату LCP.

Примітка:

В цю стадію повертається автомат LCP автоматично після роз'єднання модему. У разі інтенсивної роботи, ця стадія може бути надзвичайно короткою - тільки для того, щоб виявити присутність пристрою.

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

Важливо помітити, що з використанням LCP конфігуруються тільки ті опції конфігурації, які є незалежними від специфічних протоколів мережного рівня. Конфігурація індивідуальних протоколів мережного рівня виконується у відповідності з окремими протоколами контролю мережі (NCPs) впродовж стадії "Протокол мережного рівня".

Будь-які пакети, які не відповідають протоколу LCP, отримані впродовж цієї стадії, мають бути скинуті без повідомлення.

Отримання запиту конфігурації LCP викликає перехід із стадій "Протокол мережного рівня" або "Автентифікація" до стадії "Встановлення зв'язку".

На деяких каналах може виникнути необхідність підтвердження одноранговим об'єктом своєї достовірності перед дозволом обміну пакетами протоколу мережного рівня.

За замовчуванням, встановлення достовірності не обов'язкове. Якщо додаток вимагає, щоб достовірність однорангового об'єкта підтверджувалася деяким певним протоколом автентифікації, тоді воно повинне просити використання цього протоколу автентифікації впродовж стадії "Встановлення зв'язку".

Встановлення достовірності повинне проводитися якнайшвидше після встановлення зв'язку. Проте, одночасно може відбуватися визначення якості зв'язку. В цьому випадку додаток не повинен дозволяти обмін пакетами визначення якості зв'язку, щоб не затримувати встановлення достовірності на невизначений час.

Перехід від стадії "Автентифікація" до стадії "Протокол мережного рівня" не повинен наставати до завершення автентифікації. Якщо встановлення достовірності не виконане, то повинен статися перехід до стадії "Завершення зв'язку".

Впродовж цієї стадії можуть передаватися тільки пакети протоколу контролю зв'язку LCP, протоколу автентифікації і контролю якості зв'язку. Усі інші пакети, отримані впродовж цієї стадії, мають бути скинуті без повідомлення.

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

Додаток, який не визнав достовірність однорангового об'єкта, ініціює стадію "Завершення зв'язку".

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

Після того, як NCP досяг стану "Відкрито", PPP передаватиме відповідні пакети протоколу мережного рівня. Будь-які пакети протоколу мережного рівня, отримані, коли NCP не знаходиться в змозі "Відкрито", мають бути скинуті без повідомлення.

Примітка:

Коли LCP знаходиться в змозі "Відкрито", будь-який пакет протоколу, який не підтримується додатком, має бути вказаний в пакеті скидання протоколу (Protocol - Reject), описаному нижче. Тільки пакети підтримуваних протоколів скидаються без повідомлення.

Впродовж цієї стадії, трафік каналу складається з будь-якої можливої комбінації пакетів LCP, NCP і протоколу мережного рівня.

PPP може розірвати зв'язок у будь-який час. Це може статися із-за втрати носія, невизнання достовірності при автентифікації, незадовільної якості зв'язку, закінчення таймера незайнятого періоду або адміністративного закриття зв'язку.

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

Табл. 4 Пакети та дії автомату при РРР з’єданні

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

Будь-який пакет не LCP, отриманий впродовж цієї стадії, має бути скинутий без повідомлення.

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

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

Деякі типи пакетів : "Непідтвердження конфігурації" (Configure Naks) і "Скидання конфігурації" (Configure Rejects) або "Скидання коду" (Code Rejects) і "Скидання протоколу" (Protocol Rejects) або "Запит ехо-сигналу" (Echo Requests), "Відповідь ехо-сигналу" (Echo Replies) і "Запит скидання" (Discard Requests) - не диференціюються в описі автомата. Як буде показано нижче, ці пакети виконують різні функції, але вони завжди викликають одні і ті ж переходи.

3.5. Формати пакетів LCP

Є три класи пакетів LCP :

1) пакети конфігурації з’єднення, використовувані для встановлення і конфігурації каналу зв'язку ("Запит конфігурації", "Підтвердження конфігурації", "Непідтвердження конфігурації" і "Скидання конфігурації");

2) пакети роз'єднання з’єднення, використовувані для розриву зв'язку ("Запит роз'єднання", "Підтвердження роз'єднання");

3) пакети обслуговування з’єднення, використовувані для управління і відладки ланки зв'язку ("Скидання коду", "Скидання протоколу", "Запит ехо-сигналу", "Відповідь ехо-сигналу" і "Запит скидання").

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

Незалежно від того, які опції конфігурації дозволяються, усі пакети конфігурації ланки LCP, роз'єднання зв'язку і скидання коду (кодування від 1 до 7) посилаються завжди, неначе ніякі опції конфігурації не були встановлені. Зокрема, кожна опція конфігурації має значення за замовчуванням. Це гарантує постійну розпізнаваність пакетів LCP.

У інформаційному полі PPP інкапсулюється тільки один пакет LCP, де поле протоколу PPP показує тип c021 (протокол контролю ланки LCP).

Табл. 5 Загальний формат пакетів протоколу LCP

Поля передаються зліва направо. Поле "Код" - один октет, задає вид пакету LCP. Коли пакет отриманий з невизначеним полем "Код", передається пакет "Скидання коду".

Значення поля "Код" протоколу LCP визначаються в найбільш пізньому виданні "Assigned Numbers" RFC [3]. Нині цей документ визначає наступні величини:

1 – Запит конфігурації.

2 – Підтвердження конфігурації.

3 – Непідтвердження конфігурації.

4 – Скидання конфігурації.

5 – Запит роз'єднання.

6 – Підтвердження роз'єднання.

7 – Скидання коду.

8 – Скидання протоколу.

9 – Запит ехо-сигналу.

10 – Відповідь ехо-сигналу.

11 – Запит скидання.

Поле "Ідентифікатор" містить один октет і забезпечує відповідність запитів відповідям. Коли пакет отриманий з недійсним полем "Ідентифікатор", він скидається без дії на автомат.

Поле "Довжина" (два октети) вказує довжину пакетів LCP, включаючи поля "Код", "Ідентифікатор", "Довжина" і "Дані". Довжина не повинна перевищувати величину MRU для ланки передачі даних.

Октети поза діапазоном поля "Довжина" розглядаються як доповнення і ігноруються при прийомі. Коли пакет отриманий з недійсним значенням поля "Довжина", пакет скидається без дії на автомат.

Поле "Дані" містить нуль або більше за октети, як показано в полі "Довжина". Формат поля "Дані" визначається полем "Код".

3.6. Опції конфігурації протоколу LCP

Опції конфігурації протоколу LCP дозволяють модифікувати величини, встановлені за замовчуванням, для зв'язку "точка-точка". Якщо опції конфігурації не включені в пакет "Запит конфігурації", то для цієї опції конфігурації використовується значення, прийняте за замовчуванням.

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

Кінець списку опцій конфігурації визначається полем "Довжина" пакетів LCP.

Якщо не визначено інакше, то усі опції конфігурації застосовуються в напівдуплексному режимі, в приймальному напрямі зв'язку з точки зору відправника запиту конфігурації.

Опції вказують додаткові можливості або вимоги додатка, який вимагає опції. Додатку, який не сприймає яку-небудь опцію, слід взаємодіяти з тим, яке підтримує усі опції.

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

Табл. 6 Узагальнений формат опцій конфігурації протоколу LCP

Поля передаються зліва направо. Поле "Тип" містить один октет і вказує тип опцій конфігурації. Нині значення поля "Тип" протоколу LCP визначені в останньому виданні "Assigned Numbers" RFC [3].

Табл. 7 Значення поля "Тип" протоколу LCP

Поле "Довжина" містить один октет і вказує довжину опції конфігурації, включаючи поля "Тип", "Довжина" і "Дані". Якщо опція конфігурації, що погоджується, отримана при запиті конфігурації, але з недійсною або нерозпізнаною довжиною, то слід передати непідтвердження конфігурації, яке включає бажані опції конфігурації з відповідною довжиною і даними.

Поле "Дані" містить нуль або більше за октети і включає інформацію, що відноситься до опції конфігурації. Формат і довжина поля "Дані" визначаються полями "Довжина" і "Тип". Коли поле "Дані" визначено завдовжки так, що воно тягнеться до кінця інформаційного поля і далі, увесь пакет скидається без дії на автомат.

Максимальний розмір блока, що приймається

Цю опцію конфігурації можна посилати, щоб повідомити одноранговий об'єкт, що додаток може отримати пакети великих розмірів, або просити, щоб одноранговий об'єкт посилав менші пакети. Максимальний розмір блоку (MRU - Maximum Receive Unit), що приймається, за замовчуванням складає 1500 октетів. Якщо потрібно пакети менших розмірів, на прийомі має бути здатність отримувати повне 1500-октетне інформаційне поле.

Ця опція використовується для вказівки можливості додатка. Одноранговому об'єкту максимізувати свої можливості не вимагається. Наприклад, коли вказано, що MRU складає 2048 октетів, одноранговому об'єкту не вимагається посилати пакет з 2048 октетуми. Одноранговий об'єкт не вимагає непідтвердження конфігурації, щоб вказати, що він посилатиме тільки пакети з меншими розмірами, оскільки додаток завжди вимагатиме забезпечення принаймні 1500-октетних розмірів.

Табл. 8 Формат опції конфігурації MRU

Поля передаються зліва направо. Поле "Тип" має значення, рівне 1. Поле "Довжина" набуває значення, рівного 4. Поле "MRU" містить два октети і визначає максимальне число октетів в інформаційному полі і полі заповнення. Сюди не включаються заголовок кадру, поле протоколу, контрольна сума (FCS), біти або байти прозорості.

3.7. Протокол автентифікації

Для деяких каналів може знадобитися, щоб одноранговий об'єкт підтвердив свою достовірність перед дозволом обмінюватися пакетами протоколу мережного рівня. Ця опція конфігурації забезпечує спосіб узгодження типу протоколу встановлення достовірності. За замовчуванням, встановлення достовірності не потрібно.

Додаток не повинен включати декілька опцій конфігурації протоколу автентифікації (AP - Authentication Protocol) в пакетах "Запит конфігурації". Замість цього, йому слід спробувати спочатку задати найбільш бажаний протокол. Якщо опції цього протоколу не підтверджуються, тоді додатку слід спробувати погоджувати наступний найбільш бажаний протокол в наступному запиті конфігурації.

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

Немає ніяких вимог того, щоб автентифікація була повнодуплексною або щоб один і той же протокол використовувався в обох напрямах. Допускається використання різних протоколів у різних напрямах.

Табл. 9 Формат опції конфігурації протоколу автентифікації

Поля передаються зліва направо. Поле "Тип" набуває значення, рівного 3. Поле "Довжина" не менше 4 октетів. Поле "Протокол автентифікації" включає два октети і вказує бажаний протокол автентифікації. Величини цього поля - завжди ті ж самі, що і в Поле протоколу PPP для того ж самого протоколу автентифікації.

Нині значення поля "Протокол автентифікації" визначено в останньому виданні "Assigned Numbers" RFC [3].

Табл. 10 значення поля "Протокол автентифікації"

Поле "Дані" містить нуль або більше за октети і включає додаткові дані, як визначено відповідним протоколом.

3.8. Протокол якості

На деяких лініях зв'язку вимагається визначати, коли і як часто канал втрачає дані. Цей процес називається контролем якості каналу зв'язку. Існує опція конфігурації, яка забезпечує узгодження типу «Протоколу якості» (QP – Quality – Protocol) каналу зв'язку. За замовчуванням контроль якості зв'язку не здійснюється.

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

Немає ніяких вимог того, щоб контроль якості бути в повнодуплексним або щоб один і той же протокол використовувався в обох напрямах. Допускається використання різних протоколів у різних напрямах.

Табл. 11 Формат опції конфігурації “Протоколу якості”

Поля передаються зліва направо.

Поле "Тип" має значення, рівне 4.

Поле "Довжина" не менше 4 октетів.

Поле "Протокол якості" містить два октети і вказує бажаний протокол, контролюючий якість зв'язку. Значення цього поля - завжди ті ж, що і в Поле протоколу PPP для того ж самого протоколу контролю.

Нині значення поля "Протокол якості" визначені в останньому виданні "Assigned Numbers" RFC [3].

Табл. 12 Значення поля "Протокол якості"

Поле "Дані" включає нуль або більше за октети і містить додаткові дані, як визначено відповідним спеціальним протоколом.

3.9. Magic-номер

Ця опція конфігурації забезпечує метод виявлення зациклених ланок і інших аномалій рівня ЛПД. Вона може вимагатися деяким іншим опціям конфігурації, таким як опції конфігурації «Протоколу якості». За замовчуванням magic-номер не узгоджується, і там, де він міг би використовуватися, вставляється нуль.

Перш, ніж ця опція конфігурації знадобиться, додаток повинен вибрати свій magic-номер. Рекомендується, щоб magic-номер був вибраний випадковим чином, щоб забезпечити з дуже високою вірогідністю його унікальність.

Унікальні випадкові числа можуть виходити з серійних номерів машин, інших адрес апаратних засобів мережі, часу дня і так далі. Особливо хороші такі випадкові значення, як точні виміри часу між фізичними подіями типу прийому пакетів на інших пов'язаних мережах, часу відповіді сервера або швидкості введення символів користувача-людини. Бажано, щоб одночасно використовувалося стільки джерел, скільки можливо.

Коли запит конфігурації з опцією конфігурації magic-номери отриманий, даний magic-номер порівнюється з magic-номером останнього запиту конфігурації, посланого одноранговому об'єкту.

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

Прийом непідтвердження конфігурації з magic-номером, відмінним від того, що був в останньому непідтвердженні конфігурації, посланому одноранговому об'єкту, доводить, що зв'язок не є зацикленим, і вказує унікальний magic-номер. Якщо magic-номер дорівнює присланому в останньому непідтвердженні конфігурації, вірогідність зациклення зв'язку збільшена, і має бути вибраний новий magic-номер. У будь-якому випадку, новий запит конфігурації не можна посилати з новим magic-номером.

Якщо ланка дійсно зациклена, ця послідовність (передача запиту конфігурації, отримання запиту конфігурації, передача непідтвердження конфігурації, отримання непідтвердження конфігурації) повторюватиметься багато разів. Якщо зв'язок не зациклений, ця послідовність може відбуватися кілька разів, але вірогідність цього надзвичайно мала. Ймовірніше, що magic-номери, вибрані у будь-якому одноранговому об'єкті, швидко розрізнятимуться, завершуючи цей ланцюжок. Наступна таблиця показує вірогідність повторень при припущенні, що обидва закінчення каналу зв'язку вибирають magic-номери з абсолютно однаковим розподілом:

Табл. 13 Вірогідність повторень пакетів

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

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

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

Поле magic-номера цих пакетів слід розглядати при прийомі. Усі отримані поля magic-номери мають дорівнювати нулю або унікальному magic-номеру однорангового об'єкту залежно від того, погоджував або ні одноранговий об'єкт magic-номер.

Прийом поля magic-номера, рівного погодженому місцевому magic-номеру, вказує на зациклення ланки. Прийом magic-номера, відмінного від погодженого місцевого magic-номера, погодженого magic-номера однорангового об'єкту або нуля, якщо одноранговий об'єкт не погодив його, вказує на те, що зв'язок був конфігурований для комунікацій з іншим одноранговим об'єктом.

Процедури для відновлення від будь-якої події - не визначені і можуть змінюватися від додатка до додатка. Має бути прийнята подія LCP "Виключення", наступна подія – "Відкриття" - почне процес повторного встановлення зв'язку, який не може завершитися, доки не буде усунено зациклення і погоджений magic-номер. Інший шлях у разі зациклення ланки – повинні почати передаватися пакети LCP "Запит ехо-сигналу", доки відповідна відповідь ехо-сигналу не буде отримана, вказуючи на припинення зациклення.

3.10. Стискування поля протоколу

Ця опція конфігурації забезпечує метод узгодження стискування полів протоколу PPP (PFC – Protocol – Field – Compression). За замовчуванням усі застосування повинні передати пакети з двохоктетними полями протоколу PPP.

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

Поле протоколу використовує механізм розширення, що відповідає механізму розширення ISO 3309 для полів адреси; найменш значущий біт (LSB – Least Significant Bit) кожного октету використовується для вказівки на розширення поля протоколу. Двійковий "0" в якості LSB вказує, що поле протоколу триватиме в наступному октеті. Присутність двійкової одиниці в якості LSB свідчить про те, що цей октет поля протоколу – останній.

Помітимо, що до поля може бути приєднане будь-яке число нульових октетів, і двійкове значення буде тим же самим (наприклад, ось два двійкові представлення числа 3: 00000011 і 00000000 00000011).

При використанні вузькосмугових каналів бажано економити пропускну спроможність, посилаючи якомога менше надмірних даних. Опції конфігурації стискування поля протоколу є компромісом між вимогами простоти додатка і ефективністю використання пропускної спроможності. При успішному узгодженні для стискування поля протоколу до одного октету може використовуватися механізм розширення ISO 3309. Велику частину пакетів можна стискувати, оскільки протоколи даних призначаються зі значенням поля протоколу, меншим, ніж 256.

Стискуті поля протоколу не повинні передаватися, якщо ця опція конфігурації не була погоджена. Після узгодження, додаток повинен приймати пакети PPP з одиноктетними або двохоктетними полями протоколу, і не повинно робити відмінності між ними.

Поле протоколу ніколи не стискується при посилці будь-якого пакета LCP. Це правило гарантує однозначне розпізнавання пакетів LCP. Коли поле протоколу стиснуте, поле FCS рівня ЛПД розраховується не за початковим, а за стиснутим кадром.

Табл. 14 Формат опції конфігурації стискування полів протоколу PPP

Поля передаються зліва направо. Поле "Тип" - 7 октет. Поле "Довжина" - 2 октету.

3.11 Стискування полів адреси і контролю

Ця опція конфігурації забезпечує метод узгодження стискування полів адреси і контролю (ACFC - Address and Control Field Compression) ЛПД. За замовчуванням усі застосування повинні передавати кадри з полями адреси і контролю відповідно до правил створенням кадрів ЛПД.

Оскільки ці поля мають постійні значення для каналів точка-точка (point - to - point), їх легко стискувати. Ця опція конфігурації посилається для інформування однорангового об'єкту про те, що додаток може отримати стиснуті поля адреси і контролю. Якщо отриманий стислий кадр, а стискування полів адреси і контролю не було погоджене, то додаток може скинути кадр без повідомлення.

Поля адреси і контролю не мають бути стиснуті при посилці будь-якого пакета LCP. Це правило гарантує однозначне розпізнавання пакетів LCP. Коли поля адреси і контролю стислі, поле FCS рівня ЛПД розраховується не по початковому, а по стислому кадру.

Табл. 15 Формат опції конфігурації стискування полів адреси і контролю

Поля передаються зліва направо. Поле "Тип" - 8 октет. Полі "Довжина" - 2 октета.