Спосіб використання системи динамічної конфігурації вузлів для систем адресації із змінним розміром мережної адреси

Реферат: Спосіб використання системи динамічної конфігурації вузлів для систем адресації із змінним розміром мережної адреси, який включає передачу службової інформації під час обміну конфігураційними даними, причому передаються службові пакети зі зміненою структурою, чим забезпечується можливість функціонування системи в умовах змінного розміру мережної адреси та необхідна і достатня працездатність мережевих сервісів. UA 80849 U (54) СПОСІБ ВИКОРИСТАННЯ СИСТЕМИ ДИНАМІЧНОЇ КОНФІГУРАЦІЇ ВУЗЛІВ ДЛЯ СИСТЕМ АДРЕСАЦІЇ ІЗ ЗМІННИМ РОЗМІРОМ МЕРЕЖНОЇ АДРЕСИ UA 80849 U UA 80849 U 5 10 15 20 25 30 35 40 45 50 55 60 Корисна модель належить до техніки зв'язку, зокрема до процедури передавання інформації в телекомунікаційних мережах. Найближчим аналогом пропонованого способу є Dynamic Host Configuration Protocol (DHCP) - протокол динамічної конфігурації вузлів, який використовує клієнт-серверну архітектуру та призначений для отримання клієнтом службової інформації щодо конфігураційних параметрів в ТСР/ІР-мережі (найчастіше використовується для отримання IP-адреси вузла, інформації щодо маски підмережі, адреси основного шлюзу та деякої іншої службової інформації) [1]. Для автоматичної конфігурації комп'ютер-клієнт на етапі конфігурації мережевого пристрою звертається до сервера DHCP і отримує від нього потрібні параметри. Передача даних здійснюється шляхом обміну стандартними повідомленнями DHCP за допомогою протоколу UDP, при цьому сервер приймає повідомлення від клієнтів на порт 67 і відправляє повідомлення клієнтам на порт 68. Протокол DHCP передбачає три способи розподілу ІР-адрес: ручний, автоматичний та динамічний [1]. В Ethernet мережі DHCP сервер приймає рішення про надання клієнту конкретного набору конфігураційних параметрів на основі апаратної адреси (МАСадреси) клієнта. Такий спосіб обміну службовою DHCP інформацією в TCP/IP мережі є цілком виправданим за виключенням деяких особливостей. Структура повідомлень протоколу DHCP є невиправдано надлишковою, що пов'язано з використанням єдиного формату пакетів DHCP. Тобто, пакетзапит містить в собі поля, які призначені для використання в пакеті-відповіді, та які не несуть в собі на даному етапі жодної корисної інформації. Аналогічним чином до складу пакету-відповіді входять поля, які призначені для використання в пакеті-запиті, що є інформаційне зайвим. Таким чином, DHCP-пакет є необґрунтовано надлишковим, що призводить до неефективного використання мережного ресурсу. Крім того, система DHCP орієнтована на використання мережних адрес фіксованого розміру (IPv4 та/або IPv6, МАС), у той час як в деяких сучасних мережах передбачено використання адрес змінного розміру [2]. Отже, серед суттєвих недоліків використання вказаного вище способу необхідно відмітити такі: сучасний механізм DHCP не передбачає можливості роботи з мережними адресами вузлів змінного розміру; протокол DHCP використовує надлишкову структуру пакету на всіх етапах інформаційного обміну між клієнтом та сервером, що призводить до неефективного використання пропускної спроможності мережі. В запропонованому способі передбачається виділити сім типів службових повідомлень DHCP з метою забезпечення працездатності механізму DHCP в мережах зі змінним розміром адрес та зменшення надлишковості інформації, що передається. Першим полем вказаних повідомлень є однобайтний ідентифікатор типу повідомлення. Послідовні значення даного ідентифікатору від одного до семи включно визначають наступні типи повідомлень відповідно: Discover, Offer, Request, Ack, Nak, Decline, Release (назви повідомлень утворено від відповідних пакетів протоколу DHCP) (Фіг. 1). Використання перелічених типів повідомлень у відповідності до типового алгоритму взаємодії клієнта DHCP з сервером (Фіг. 2) є достатнім для забезпечення виконання протоколом DHCP своїх основних функцій. Технічно задача вирішується в такий спосіб: 1. При активації мережного інтерфейсу клієнт відсилає широкомовний запит (пакет Discover (Фіг. 3)) по локальній підмережі з метою виявлення доступних серверів. Зважаючи на те, що сервер може знаходитись в іншій підмережі, необхідно передбачити можливість роботи на маршрутизаторі (ЕХ-комутаторі) так званого агента транспортування (процес, який прослуховує відповідні порти і при виявленні пакету виконує його пересилку в іншу підмережу аналогічно до правил, визначених в [3]), здатного передати запит серверам, які розміщені поза межами даної підмережі. 2. Після отримання сервером (або серверами) пакету Discover формується пакет Offer (Фіг. 4), який широкомовно відсилається сервером (або серверами) у відповідь на отриманий запит клієнта. Якщо запит був прийнятий від агента транспортування, то в такому випадку в адресі призначення виставляється адреса агента. Пакет Offer використовується як пропозиція мережної адреси. В даному повідомленні передаються такі параметри, як мережева адреса вузла, маска підмережі, адреса основного шлюзу, адреса DNS-серверу. При цьому пропонована адреса на деякий визначений час t0 видаляється з пулу доступних адрес та заноситься в тимчасовий буфер. Якщо протягом часу t0 сервер не отримує від клієнта повідомлення типу Request (Фіг. 5), то зазначена адреса звільняється і стає доступною для інших клієнтів. Якщо на даний момент немає жодної вільної адреси, сервер ігнорує отриманий запит. 3. Клієнт отримує одне або декілька повідомлень Offer від одного або декількох серверів та обирає сервер, на пропозицію якого він згоден (зазвичай, вибір відбувається на основі першості 1 UA 80849 U 5 10 15 20 25 30 35 40 45 50 55 60 за часом - від якого сервера раніше надійшла пропозиція, той сервер і обирається). Далі клієнт відсилає широкомовний пакет Request (Фіг. 5), в якому міститься інформація про вибраний сервер. Як альтернатива вибору сервера на основі першості за часом можливим є впровадження вибору сервера на основі довжини мережної адреси, яка пропонується. Так, може бути вибраний сервер, який пропонує адресу найменшого, найбільшого або наперед заданого розміру. Певні критерії вибору (наприклад, за часом або за мінімальним розміром адреси) можуть використовуватись клієнтом за замовченням, а певні повинні бути задані адміністратором мережі. При цьому, як значення адрес, які пропонуються серверами клієнтам, так і критерії вибору клієнтом необхідного сервера, визначаються мережним адміністратором в залежності від прийнятої політики адміністрування мережі. 4. Сервери отримують широкомовне повідомлення Request від клієнта. Ті сервери, адреси яких не вказані в повідомленні, розцінюють отримане повідомлення, як відмову клієнта від їх пропозиції і звільняють запропоновані адреси для подальшого використання іншим клієнтам. Сервер, адреса якого вказана в повідомленні Request, виконує запис конфігураційного набору клієнта в постійну пам'ять, виконуючи при цьому асоціацію значення поля "id" з зазначеним конфігураційним набором, і широкомовно передає повідомлення "Ack" (Фіг. 6), в якому вказує термін дії даної адреси в секундах. У випадку, коли вибраний сервер не має можливості надати пропонований раніше конфігураційний набір мережних параметрів клієнту (наприклад, при зміні якогось з мережних параметрів), він відповідає повідомленням "Nak" (Фіг. 5). 5. Клієнт отримує повідомлення "Ack", фіксує тривалість оренди адреси і в залежності від власної програмної реалізації він може або відразу застосувати відповідні мережні конфігурації, або спочатку перевірити відсутність пропонованої адреси в мережі і лише потім застосовувати мережні конфігурації. На даному етапі мережна конфігурація клієнта завершується. Якщо клієнт виявляє, що пропонована адреса вже використовується, то він відсилає серверу повідомлення типу "Decline" (Фіг. 7) і повторно починає процес отримання адреси шляхом широкомовної відправки повідомлення "Discover". Якщо клієнт отримує повідомлення "Nak", то він також починає процедуру отримання адреси спочатку. 6. При отриманні повідомлення типу "Decline" сервер повинен відшукати запис з вказаним в повідомленні "id", помітити пов'язану з ним адресу як недоступну і повідомити адміністратора про можливу проблему. 7. Клієнт може завчасно відмовитись від адреси, що використовується, шляхом відправки серверу повідомлення типу "Release" (Фіг. 7). 8. При отриманні повідомлення типу "Release" сервер повинен звільнити відповідну адресу для можливого її використання іншими клієнтами. 9. При закінченні половини визначеного сервером строку оренди адреси, клієнт повинен знову надіслати серверу повідомлення типу Request з метою продовження строку оренди. При цьому сервер, отримавши таке повідомлення, виконає пошук відповідного "id" у тимчасовому буфері і не знайде його, після чого виконає аналогічний пошук в постійній пам'яті, знайде необхідний запис із зазначеним "id", на основі чого зробить висновок про необхідність продовження клієнту строку оренди адреси, і відправить клієнту новий пакет "Ack" (або "Nak"). Переваги запропонованого способу полягають у наступному: можливість використання функціоналу системи динамічної конфігурації вузлів для систем адресації із змінним розміром мережної адреси; зменшення інформаційної надлишковості протоколу DHCP, що дозволяє більш ефективно використовувати пропускну спроможність мережі; розширення функціоналу механізму DHCP шляхом реалізації альтернативного способу вибору клієнтом необхідного сервера на основі довжини адреси, що пропонується; широкі можливості подальшого розвитку протоколу завдяки розміру ідентифікатора типу повідомлення (256 можливих типів). Перелік фігур креслення: Фіг. 1 - Перелік типів повідомлень пропонованої системи. Фіг. 2 - Типовий алгоритм взаємодії клієнта системи з сервером. Фіг. 3 - Формат повідомлення типу Discover. Фіг. 4 - Формат повідомлення типу Offer. Фіг. 5 - Формат повідомлень типу Request та Nak. Фіг. 6 - Формат повідомлення типу Ack. Фіг. 7 - Формат повідомлень типу Decline та Release. Умовні позначення (Фіг. 2): 1 старт ініціалізації, відправлення пакету Discover; 2 визначення вільних адрес, відправлення пакету Offer; 2 UA 80849 U 5 10 15 20 25 30 35 40 45 50 55 60 3 очікування та збір відгуків, прийом пакетів Offer; 4 очікування пакету Request; 5 вибір прийнятного за деякими параметрами серверу (вибрано сервер 2), відправлення пакету Request; 6 звільнення зарезервованої адреси; 7 створення необхідного запису в БД, відправлення пакету Ack; 8 прийом пакету Ack від вибраного серверу; 9 завершення ініціалізації; 10 завершення роботи вузла, відправка пакету Release; 11 видалення необхідного запису з БД, звільнення зарезервованої адреси. Умовні позначення (Фіг. 3): ор тип пакету, що передається; steps встановлюється рівним нулю і збільшується на 1 при можливому проходженні крізь агента транспортування; id ідентифікатор вузла, може відповідати імені вузла або, при відсутності назви у вузла, бути призначений генератором випадкових чисел, використовується протягом всієї взаємодії клієнта з сервером, а також зберігається клієнтом на постійній основі; lgaddr використовується агентами транспортування для визначення довжини поля "gaddr", при відсутності агентів транспортування ("steps"=0) поле відсутнє; в даному полі використовуються лише молодші 4 біти, старші 4 біти зарезервовані на майбутнє та повинні бути встановлені в 0; gaddr адреса агента транспортування, через якого пройшов пакет, при відсутності агентів транспортування ("steps»=0) поле відсутнє. Умовні позначення (Фіг. 4): ор тип пакету, що передається steps встановлюється рівним нулю і збільшується на 1 при можливому проходженні крізь агента транспортування; id ідентифікатор вузла, може відповідати імені вузла або, при відсутності назви у вузла, бути призначений генератором випадкових чисел, використовується протягом всієї взаємодії клієнта з сервером, а також зберігається клієнтом на постійній основі; lgaddr використовується агентами транспортування для визначення довжини поля "gaddr", при відсутності агентів транспортування ("steps»=0) поле відсутнє; в даному полі використовуються лише молодші 4 біти, старші 4 біти зарезервовані на майбутнє та повинні бути встановлені в 0; gaddr адреса агента транспортування, через якого пройшов пакет, при відсутності агентів транспортування ("steps"=0) поле відсутнє; laddr довжина мережної адреси, яка пропонується клієнту; addr пропонована клієнту мережна адреса; sm довжина маски (кількість двійкових одиниць маски) підмережі, в якій знаходиться клієнт; raddr адреса основного шлюзу; ldaddr довжина адреси DNS-серверу, у випадку відсутності відомостей про DNS-сервер поле дорівнює нулю; daddr адреса DNS-серверу, у випадку його відсутності ("ldaddr"=0) поле не включається до складу пакету; Умовні позначення (Фіг. 5): ор тип пакету, що передається; steps встановлюється рівним нулю і збільшується на 1 при можливому проходженні крізь агента транспортування; id ідентифікатор вузла, може відповідати імені вузла або, при відсутності назви у вузла, бути призначений генератором випадкових чисел, використовується протягом всієї взаємодії клієнта з сервером, а також зберігається клієнтом на постійній основі; lgaddr використовується агентами транспортування для визначення довжини поля "gaddr", при відсутності агентів транспортування ("steps"=0) поле відсутнє; в даному полі використовуються лише молодші 4 біти, старші 4 біти зарезервовані на майбутнє та повинні бути встановлені в 0; gaddr адреса агента транспортування, через якого пройшов пакет, при відсутності агентів транспортування ("steps»=0) поле відсутнє; lsaddr довжина мережної адреси вибраного сервера пропонованої системи; saddr адреса вибраного сервера пропонованої системи. Умовні позначення (Фіг. 6): ор тип пакету, що передається; 3 UA 80849 U 5 10 15 20 25 steps встановлюється рівним нулю і збільшується на 1 при можливому проходженні крізь агента транспортування id ідентифікатор вузла, може відповідати імені вузла або, при відсутності назви у вузла, бути призначений генератором випадкових чисел, використовується протягом всієї взаємодії клієнта з сервером, а також зберігається клієнтом на постійній основі; lgaddr використовується агентами транспортування для визначення довжини поля "gaddr", при відсутності агентів транспортування ("steps»=0) поле відсутнє; в даному полі використовуються лише молодші 4 біти, старші 4 біти зарезервовані на майбутнє та повинні бути встановлені в 0; gaddr адреса агента транспортування, через якого пройшов пакет, при відсутності агентів транспортування ("steps»=0) поле відсутнє; lsaddr довжина мережної адреси вибраного сервера пропонованої системи; saddr адреса вибраного сервера пропонованої системи; sees термін дії орендованої адреси в секундах. Умовні позначення (Фіг. 7): ор тип пакету, що передається; id ідентифікатор вузла, може відповідати імені вузла або, при відсутності назви у вузла, бути призначений генератором випадкових чисел, використовується протягом всієї взаємодії клієнта з сервером, а також зберігається клієнтом на постійній основі. Джерела інформації: 1. Droms R. Dynamic Host Configuration Protocol / R. Droms // Network Working Group. - 1997, RFC 2131. - 45 p. 2. Каптур В.А. Базові принципи практичної реалізації систем адресації із змінним розміром мережної адреси в Ethernet мережах / В.А. Каптур, К.Д. Гуляєв, П.С. Кравченко // Радіоелектронні і комп'ютерні системи. - 2012. - №1 (53). - С 51-54 3. Croft Bill. Bootstrap Protocol (BOOTTP)/ Bill Croft, John Gilmore // Network Working Group. 1985, RFC 951. - 12 p. ФОРМУЛА КОРИСНОЇ МОДЕЛІ 30 Спосіб використання системи динамічної конфігурації вузлів для систем адресації із змінним розміром мережної адреси, який включає передачу службової інформації під час обміну конфігураційними даними, який відрізняється тим, що передаються службові пакети зі зміненою структурою, чим забезпечується можливість функціонування системи в умовах змінного розміру мережної адреси та необхідна і достатня працездатність мережевих сервісів. 4 UA 80849 U 5 UA 80849 U 6 UA 80849 U Комп’ютерна верстка А. Крулевський Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 7