Топалов

Лабораторна робота №2

Дослідження з'єднання тунелю за протоколом

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

Мета роботи. Дослідження процесу встановлення з'єднання за протоколом РРРoE

Ключові положення

Однією з причин малого числа каналів зв'язку 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Р для завдання конфігурації з'єднан-

121

ня, а також перевірки каналу передачі даних. Після того, як канал встановлений і пакетом 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 33091984/PDAD1 "Addendum 1: Start/stop Trasmission" (Додаток 1: Стартстопна пе-

редача"). ISO 3309-1979 визначає структуру блока даних HLDC для застосування в синхронних оточеннях. ISO 3309-1984/PDAD1 визначає запропоновані для стандарту ISO 3309-1979 модифікацій, які дозволяють його використання в асинхронних оточеннях. Процедури управління РРР використовують визначення і кодування керівників полів, стандартизованих ISO 4335-1979 і ISO 43351979/Addendum 1-1979.

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

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

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

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

122

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

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

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

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

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

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

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

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

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

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

івибору конфігурації каналу.

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

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

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

LCP.

123

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

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

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

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

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

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

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

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

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

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

Протокол (8/16 біт)

Інформація

Доповнення

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

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

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

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

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

124

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

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

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

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

Значення (у 16-надцятковому вигляді)	Найменування протоколу
0001	Протокол доповнення
0003..001f	Резерв
0003..001f	Резерв
007d	Резерв
00cf	Резерв
00ff	Резерв
8001..801f	Не використовується
807d	Не використовується
80cf	Не використовується
80ff	Не використовується
C021	Протокол LCP
C023	Протокол автентифікації пароля
C025	Повідомлення про якість зв'язку
C223	Відгук протоколу автентифікації в ре-
	жимі підтвердження

Розробники нових протоколів повинні отримати номер для протоколу, що розробляється ними, у відділі призначення номерів Internet (IANA - Internet

Assigned Numbers Authority), за адресою [e-mail].

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

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

MRU.

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

125

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

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

Довжина поля у	1	1	2/1	Змінна	2 чи 4
байтах: 1
Прапор	Адреса	Управління	Протокол	Дані	FCS

Розглянемо призначення вказаних полів [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, щоб вибрати і конфігурувати один або більше за протоколи мережного рівня. Якщо кожен з вибраних протоколів мережного рівня конфігурований, то по цьому каналу з кожного протоколу мережного рівня можна посилати дейтаграми.

126

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

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

		Включення	Встановлення		Відкрити		Аутентифі-
Вимкнено
			зв’язку				кація
	Неможливість				Не визнання		Визнання
	Вимкнено				автентичності		автентичності
			Завершення				Протокол ме-
			зв’язку		Закрито		режного рівня

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

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

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

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

Примітка:

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

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

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

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

127

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

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

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

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

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

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

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

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

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

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

Примітка:

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

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

128

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

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

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

Події:

Up = включення нижнього рівня

Down = виключення нижнього рівня

Open = адміністративне відкриття

Close= адміністративне закриття

TO+ = таймаут з лічильником > 0

TO - = таймаут з минулим лічильником

RCR+ = прийнятий запит конфігурації

(задовільний)

RCR - = прийнятий запит конфігурації

(незадовільний)

RCA = прийняте підтвердження конфігу-

рації

RCN = прийняте непідтверджен-

ня/скидання конфігурації

RTR = прийнятий запит роз'єднання

RTA = прийняте підтвердження роз'єд-

нання

RUC = прийнятий нерозпізнаний код

RXJ+ = прийняте скидання коду (що до-

зволяється) або скидання протоколу

RXJ - = прийнято скидання коду (аварій-

ний) або скидання протоколу

RXR = прийнятий запит ехо-сигналу або

відповідь ехо-сигналу або запит скидання

Дії:

tlu = цей рівень включається

tld = цей рівень вимикається

Tls = цей рівень починається

Tlf = цей рівень завершується

irc = лічильник перезапуску ініціалізувався

zrc = лічильник перезапуску обнуляється

scr = посилається запит конфігурації

sca = посилається підтвердження конфігура-

ції

scn = посилається непідтвердження/скидання

конфігурації

str = посилається запит роз'єднання

sta = посилається підтвердження роз'єднання

scj = посилається скидання коду

ser = посилається відповідь ехо-сигналу

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

129

слід відокремитися після отримання підтвердження роз'єднання або після того, як закінчиться лічильник перезапуску. Приймачу запиту на роз'єднання слід чекати, поки одноранговий об'єкт не відокремиться; він не повинен відокремлюватися до тих пір, поки після підтвердження роз'єднання не пройде, принаймні, один період перезапуску. 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) посилаються завжди, неначе ніякі опції конфігурації не були встановлені. Зок-

130