Спосіб мінімізації службової інформації при тунелюванні rtp-навантаження

Спосіб мінімізації службової інформації при тунелюванні RTP-навантаження, який включає зменшення кількості службової інформації, що передають разом із корисним голосовим наванта 3 бує оновлення контекстів RTP-сесій на обох кінцях каналу зв'язку. Такий спосіб є цілком виправданим при застосування для низько-швидкісних каналів зв'язку (наприклад, dial-up з'єднання), однак його застосування в сучасних швидкісних IP-мережах має достатньо суттєві недоліки: протокол не дозволяє використовувати частину незадіяних полів ІР-заголовку верхнього рівня для мінімізації відносного збільшення обсягу службової інформації; протокол не має механізмів поєднання корисної інформації від різних RTP-сесій в межах одного пакету. Необхідність в реалізації такого функціоналу особливо гостро постає при організації взаємоз'єднань між двома серверами IP-телефонії за умов одночасного передавання великої кількості RTPсесій. В цьому випадку заголовки IP/UDP/RTP з паралельних RTP-сесій також містять велику кількість схожих за значеннями полів, що дозволяє застосувати цю властивість для більш ефективного стиснення службової інформації ніж для випадку незалежної компресії RTP-сесій. Зважаючи на те, що при тунелюванні IPнавантаження утворюється віртуальний канал зв'язку побудований за принципом «точка-точка», принцип стиснення заголовків IP/UDP/RTP розглянутий в специфікації протоколу cRTP може бути використаний і в цьому випадку з врахуванням необхідних доповнень. В запропонованому способі на кожній зі сторін IP тунелю окрім звичайних засобів тунелювання, що передбачають включення до кожного пакету додаткового IP-заголовку, реалізовано компресор та декомпресор. Як компресори, так і декомпресори оперують спеціальними таблицями контекстів RTP-сесій. За допомогою інформації, яка зберігається в зазначених таблицях компресори (за аналогією з протоколом cRTP) можуть не передавати всю службову інформацію для кожного голосового кадру, а попередньо забезпечити передавання першого з пакетів в межах RTP-сесії декомпресору і в подальшому передавати лише унікальний ідентифікатор контексту та спеціальні інформаційні повідомлення у разі відхилення службової інформації в наступному пакеті тієї самої RTP-сесії від очікуваних значень. Такий підхід дозволяє зменшити розмір службової інформації, що передається із кожним голосовим кадром з 40 байт до 2-4 байт на кожен пакет [3]. Додаткове зменшення обсягу службової інформації досягається за рахунок агрегації пакетів з різних RTP-сесій, що надходять до компресора на протязі періоду часу меншого за середню різницю в часі між надходженням двох пакетів з однієї RTP-сесії. Така агрегація дозволяє збільшити швидкість передавання корисного навантаження за рахунок зменшення сукупного обсягу службового навантаження, що передається із кожним голосовим фреймом. Технічно задача вирішується в такий спосіб (Фіг. 1 та Фіг. 2): 1. Після надходження до компресору нового IP-пакету здійснюється перевірка на наявність в 57700 4 цьому пакеті голосових даних, що передаються в межах типової RTP-сесії (перевіряється тип протоколів у відповідних полях заголовків, розмір пакету тощо). 2. У разі, якщо до тунелю надійшов пакет із голосовою інформацією проводиться аналіз IPадрес відправника та одержувача, а також номерів портів протоколу UDP та за допомогою цієї інформації здійснюється пошук контексту RTP-сесії в таблиці контекстів. 3. Якщо контекст знайдено, компресором здійснюється перевірка на додержання очікуваних змін по відношенню до останнього збереженого стану контексту і у випадку, коли надійшов пакет, змінні поля службових заголовків якого набули очікуваних змін, здійснюється формування пакету із зменшеним обсягом заголовку, який обов'язково містить ідентифікатор контексту, порядковий номер пакету в межах сесії тощо. У разі, якщо контекст не було знайдено або до компресора надійшов пакет із неочікуваними змінами здійснюється створення нового контексту в таблиці або оновлення існуючого із подальшим пересиланням пакету із всіма службовими заголовками та додаванням ідентифікатора контексту. 4. Після формування пакету він зберігається до проміжного буфера. У разі, якщо до цього в буфері інших пакетів не було лічильник часу агрегації встановлюється в нульове значення. Додавання значень до лічильника здійснюється із надходженням до компресора штучних пакетів синхронізації. 5. Одержані пакети зберігаються до проміжного буфера та не надсилаються до іншої сторони тунелю до того часу, доки лічильник часу агрегації не перевищить заданого значення Тmax. Після цього всі збережені в проміжному буфері пакети (як повні так і зменшені) збираються до одного агрегованого пакету та пересилаються на інший бік тунелю до декомпресора. В свою чергу всі інші пакети (в яких не міститься голосова інформація) відразу пересилаються на інший бік тунелю. 6. Декомпресор після одержання чергового пакету, насамперед, здійснює деінкапсуляцію інформації одержаної з іншого боку тунелю. 7. Після виділення цієї інформації здійснюється перевірка типу пакету (агрегований або ні). У разі, якщо до декомпресора надійшов агрегований пакет - декомпресор організує цикл обробки всіх пакетів, що входять до його складу. Першим кроком такої обробки є перевірка на повноту пакету. У разі, якщо пакет містить повні заголовки протоколів IP/UDP та RTP здійснюється створення нового контексту або оновлення існуючого в таблиці контекстів RTP-сесій декомпресора. В свою чергу, якщо пакет містить лише ідентифікатор контексту та порядковий номер пакету, здійснюється пошук контексту в таблиці та або відновлення пакету з контексту із подальшим його передаванням до верхніх рівнів стеку або формування та надсилання до іншого боку тунелю повідомлення про пошкодження контексту. 8. Якщо до декомпресора надійшов не агрегований пакет, то в цьому випадку насамперед здійснюється перевірка на одержання повідомлення 5 про пошкодження контексту. Така перевірка необхідна для обробки повідомлень від декомпресора на іншому боці тунелю. У разі одержання такого повідомлення здійснюється знищення пошкодженого контексту з таблиць контекстів RTP-сесій компресора та декомпресора та вихід з процедури без передавання пакету далі. У всіх інших випадках пакет передається до верхніх рівнів стеку. Переваги запропонованого способу полягають у такому: в 1,5-3 рази зменшується загальний обсяг навантаження, що передається крізь канал зв'язку при тунелюванні, в залежності від кількості одночасних RTP-сесій; спосіб може бути використаний при організації взаємоз'єднань операторів IP-телефонії в сучасних ІР-мережах; звільнений ресурс пропускної здатності може бути використаний або для збільшення кількості одночасних телефонних з'єднань (без збільшення вимог до пропускної здатності каналу зв'язку), або для покращення якості зв'язку за рахунок дублювання IP-пакетів з метою мінімізації імовірності їх безповоротної втрати. Перелік фігур креслення: Фіг. 1 - Алгоритм роботи компресора. Фіг. 2 - Алгоритм роботи декомпресора. Умовні позначення (Фіг. 1): 1 отримання IP-пакету змаршутизованого до тунелю 2 перевірка чи отриманий пакет містить RTPзаголовок та голосові дані 3 перевірка чи не є отриманий пакет, пакетом синхронізації таймера 4 пошук контексту RTP-сесії (за даними заголовків IP/UDP/RTP) в таблиці контекстів 5 таблиця контекстів RTP-сесій 6 додавання таймера синхронізації Т = Т + dT 7 перевірка чи знайдено контекст RTP-сесії 8 перевірка чи відбулися очікувані зміни 9 створення нового контексту та його збереження в таблиці 10 формування пакету із зменшеним обсягом заголовку 11 додавання до повного пакету ідентифікатора контексту та порядкового номеру 12 збереження сформованого пакету до проміжного буферу 13 проміжний буфер 14 перевірка чи це перший пакет в буфері 15 встановлення таймера в початкове значен 57700 6 ня Т = 0 16 перевірка чи не перевищено час агрегації (Т > Тmах) 17 вихід з процедури без надсилання пакету 18 формування агрегованого пакету для відправки через тунель до декомпресора із використанням в якості поля даних змісту проміжного буферу 19 відправка пакету через тунель до декомпресора Умовні позначення (Фіг. 2): 1 отримання IP-пакету з іншого боку тунелю 2 деінкапсуляція (відкидання тунельного ІРзаголовку) 3 перевірка чи є отриманий пакет агрегованим 4 перевірка чи є отриманий пакет повідомленням про пошкодження контексту 5 цикл проходження пакетів вкладених в агрегований (І = 1 .. К) 6 передавання пакету до верхніх рівнів стеку 7 знищення контексту з таблиць компресора та декомпресора 8 перевірка чи пакет надійшов із повними заголовками 9 пошук контексту за ідентифікатором 10 створення нового контексту або модифікація існуючого 11 вихід з процедури без надсилання пакету 12 перевірка чи знайдено контекст 13 перевірка чи порядковий номер пакету відповідає очікуваному 14 формування повідомлення про пошкодження контексту 15 відновлення пакету з контексту 16 передавання пакету до іншого боку тунелю 17 передавання пакету до верхніх рівнів стеку Джерела інформації: 1. Casner S. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. [Електронний ресурс] / S. Casner, V. Jacobson. // RFC 2508. - Режим доступу: http://www.faqs.org/rfcs/rfc2508.html. 2. Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. [Електронний ресурс] / Т. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy // RFC 3545 Режим доступу: http://www.faqs.org/rfcs/rfc3545.html. 3. Young-Bea Ко. Location-Aided Routing (LAR) in mobile ad hoc networks / Young-Bea Ко, Nitin H. Vaidya // Wireless Networks. - 2000. - № 6. - С 307321. 7 Комп’ютерна верстка А. Крулевський 57700 8 Підписне Тираж 23 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601