Протоколы Internet
         

Сжатие данных с использованием преобразования Барроуза-Вилера


2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

Семенов Ю.А. (ГНЦ ИТЭФ)

Майкл Барроуз и Давид Вилер (Burrows-Wheeler) в 1994 году предложили свой алгоритм преобразования (BWT). Этот алгоритм работает с блоками данных и обеспечивает эффективное сжатие без потери информации. В результате преобразования блок данных имеет ту же длину, но другой порядок расположения символов. Алгоритм тем эффективнее, чем больший блок данных преобразуется (например, 256-512 Кбайт). Пояснение работы алгоритма будет выполнено на ограниченном объеме исходных данных (строка S длиной N, например, SEMENOV). Строка S рассматривается как последовательность, состоящая из N строк.

Сначала осуществляется циклический сдвиг строки S и формируется N-1 новая строка. На практике строки не размножаются, а создается массив указателей на циклический буфер, где лежит исходная строка S.

 

Строка

S E M E N O V S0 E M E N O V S S1 M E N O V S E S2 E N O V S E M


S3 N O V S E M E S4 O V S E M E N S5 V S E M E N O S6

Далее выполняется лексикографическое упорядочение (сортировка) этих строк (указателей). Для упорядочения можно использовать С-функции типа strcmp() или memcmp() (учитывая особенности структуры буфера, это должны быть их функциональные аналоги).

F

          

L

Строка
E M E N O V S S1
E N O V S E M S3
M E N O V S E S2
N O V S E M E S4
O V S E M E N S5
S E M E N O V S0
V S E M E N O S6

Первая колонка помечена буквой F, а последняя – L. Колонка F (EEMNOSV) содержит все символы исходной строки S, записанные в упорядоченной последовательности. Строка L представляет собой последовательность префиксных символов для строки S.

Результатом работы алгоритма BWT является строка L и первичный индекс, который представляет собой номер элемента строки L, где хранится первый символ исходной строки S. В приведенном примере индекс равен 1.

Смотри

http://web2.airmail/markn/articles/bwt/bwt.htm



Таблица цветов, их имен и кодов


10.26 Таблица цветов, их имен и кодов

Семенов Ю.А. (ГНЦ ИТЭФ)

Надеюсь, эта таблица окажется полезной для WEB-дизайнеров. Пожалуйста, не пытайтесь печатать эти страницы, ничего хорошего не получится! Цвета отображены с использованием атрибута bgcolor. Ю.А.С.

Образец Код Название CSS Название Образец Код Название CSS Название           #F0F8FF aliceblue блекло-голубой           #A52A2A brown коричневый          #FAEBD7 antiquewhite античный белый          #DEB887 burlywood старого дерева      #00FFFF aqua синий      #5F9EA0 cadetblue блеклый серо-голубой           #7FFF00 chartreuse фисташковый           #FF7F50 coral коралловый           #F5F5DC azure лазурь           #D2691E chocolate шоколадный           #F5F5DC beige бежевый           #6495ED cornflowerblue васильковый           #FFE4C4 bisque бисквитный           #000000 black черный           #FFF8DC cornsilk темно-зеленый           #DC143C crimson малиновый        #FFEBCD blanchedalmond светло-кремовый        #00FFFF cyan циан        #0000FF blue голубой        #00008B darkblue темно-голубой        #8A2BE2 blueviolet светло-фиолетовый        #008B8B darkcyan темный циан        #B8860B darkgoldenrot темный красно-золотой     #A9A9A darkgray темно-серый        #006400 darkgreen темно-зеленый        #BDB76B darkkhaki темный хаки       
#8B008B darkmagenta темный фуксин        #556B2F darkolivegreen темно-оливковый        #FF8C00 darkorange темно-оранжевый     #9932CC darkorchid темно-орхидейный     #8B0000 darkred темно-красный     #E9967A darksalmon темно-оранжево-розовый     #8FBC8F darkseagreen темный морской волны     #483D8B darkslateblue темный сине-серый     #2F4F4F darkslategray темный сине-серый     #00CED1 darkturqueise темно-бирюзовый     #9400D3 darkviolet темно-фиолетовый     #FF1493 deeppink темно-розовый     #00BFFF deepskyblue темный небесно-голубой     #696969 dimgray тускло-серый     #1E90FF dodgerblue тускло-васильковый     #B22222 firebrick огнеупорного кирпича     #FFFAF0 floralwhite цветочно-белый     #228B22 forestgreen лесной зеленый     #FF00FF fuchsia фуксии     #F8F8FF ghostwhite туманно-белый     #DCDCDC gainsboro гейнсборо     #FFD700 gold золотой     #DAA520 goldenrod красного золота     #808080 gray серый     #008000 green зеленый     #ADFF2F greenyellow желто-зеленый     #F0FFF0 honeydew свежего меда     #FF69B4 hotpink ярко-розовый     #CD5C5C indianred ярко-красный     #4B0082 indigo индиго     #FFFFF0 ivory слоновой кости     #F0E68C khaki хаки     #E6E6FA lavender бледно-лиловый     #FFF0F5 lavenderblush бледный розово-лиловый     #7CFC00 lawngreen зеленой лужайки     #FFFACD lemonchiffon лимонный     #ADD8E6 lightblue светло-голубой     #F08080 lightcoral светло-кораловый     #E0FFFF lightcyan светло-циановый    
#FAFAD2 lightgoldenrodyellow светлый золотисто-желтый     #90EE90 lightgreen светло-зеленый     #D3D3D3 lightgrey светло-серый     #FFB6C1 lightpink светло-розовый     #FFA07A lightsalmon светлый оранжево-розовый     #20B2AA lightseagreen светлый морской волны     #87CEFA lightskyblue светлый небесно-голубой     #778899 lightslategray светлый сине-серый     #B0C4DE lightsteelblue светло-стальной     #FFFFE0 lightyellow светло-желтый     #00FF00 lime цвета извести     #32CD32 limegreen зеленовато-известковый     #FAF0E6 linen льняной     #FF00FF фуксин blanchedalmond     #800000 maroon оранжево-розовый     #66CDAA mediumaquamarine умеренно-аквамариновый     #0000CD mediumblue умеренно-голубой     #3CB371 mediumseagreen умеренный морской волны     #7B68EE mediumslateblue умеренный серо-голубой     #BA55D3 mediumorchid умеренно-орхидейный     #9370DB mediumpurple умеренно-пурпурный     #00FA9A mediumspringgreen умеренный сине-серый     #48D1CC mediumturquose умеренно-бирюзовый     #0C71585 mediumvioletred умеренный красно-фиолетовый     #191970 midnightblue полуночный синий     #0F5FFFA mintcream мятно-кремовый     #FFE4E1 mistyrose туманно-розовый     #FFE4B5 moccasin болотный     #FFDEAD navajowhite грязно-серый     #000080 navy морской     #FDF5E6 oldlace старого коньяка     #808000 olive оливковый     #6B8E23 olivedrab     #FFA500 orange оранжевый     #FF4500 orangered оранжево-красный     #DA70D6 orchid орхидейный     #EEE8AA palegoldenrod бледно-золотисный    
#98FB98 palegreen бледно-зеленый     #AFEEEE paleturquoise бледно-бирюзовый     #DB7093 palevioletred бледный красно-фиолетовый     #FFEFD5 papayawhip дынный     #FFDAB9 peachpuff персиковый     #CD853F peru коричневый     #FFC0CB pink розовый     #DDA0DD plum сливовый     #B0E0E6 powderblue туманно-голубой     #800080 purple пурпурный     #FF0000 red красный     #BC8F8F rosybrown розово-коричневый     #4169E1 royalblue королевский голубой     #8B4513 saddlebrown старой кожи     #FA8072 salmon оранжево-розовый     #F4A460 sandybrown рыже-коричневый     #2E8B57 seagreen морской зеленый     #FFF5EE seashell морской пены     #A0522D sienna охра     #C0C0C0 silver серебристый         #87CEEB skyblue небесно-голубой         #6A5ACD slateblue серо-голубой         #708090 slategray сине-серый         #FFFAFA snow снежный         #00FF7F springgreen весенне-зеленый         #4682B4 steelblue сине-стальной         #D2B48C tan желто-коричневый         #008080 teal чайный         #D8BFD8 thistle чертополоха         #FF6347 tomato томатный         #40E0D0 turquoise бирюзовый         #EE82EE violet фиолетовый         #F5DEB3 wheat пшеничный         #FFFFFF white белый         #F5F5F5 whitesmoke белый дымчатый         #FFFF00 yellow желтый        #9ACD32 yellowgreen желто-зеленый         #7FFFD4 aquamarine аквамарин

Таблица операций и субопераций NCP


10.4 Таблица операций и субопераций NCP

Семенов Ю.А. (ГНЦ ИТЭФ)

Код операции

Код субоперации

Описание

23 1 50 Get Current Account Status 23 1 51 Submit Account Change 23 1 52 Submit Account Hold 23 1 53 Submit Account Note

Обслуживание файловой системы Apple

35 01 AFP Create Directory 35 02 AFP Create File 35 03 AFP Delete 35 04 AFP Get Entry ID from Name 35 05 AFP Get File Information 35 06 AFP Get Entry ID from NetWare Handle 35 07 AFP Rename 35 08 AFP Get Open File Fork 35 09 AFP Set File Information 35 10 AFP Scan File Information 35 11 AFP 2.0 Alloc Temporary Directory Handle 35 12 AFP Get Entry ID from Name Path 35 13 AFP 2.0 Create Directory 35 14 AFP 2.0 Create file 35 16 AFP 2.0 Set File Information 35 17 AFP 2.0Scan file Information 35 18 AFP Get DOS Name from Entry ID 35 19 AFP Get Macintosh Info on Deleted File

Аудиторские услуги

88 01 Query Volume Audit Status 88 02 Add Audit Property 88 03 Add Audit Access 88 04 Change Audit Password 88 05 Check Auditor Access 88 06 Delete Audit Property 88 07 Disable Volume Auditing 88 08 Enable Volume Auditing 88 09 Is User Audited 88 10 Read Audit Bit Map 88 11 Read Audit Config Header 88 12 Read Auditing File 88 13 Remove Auditor Access 88 14 Reset Audit File 88 15 Reset History File 88 16 Write Audit Bit Map 88 17 Write Audit Config Header

Работа с базой данных Bindery и операции доступа

23 50 Create Bindery Object 23 51 Delete Bindery Object 23 52 Rename Object 23 53 Get Bindery Object ID 23 54 Get Bindery Object in Set 23 55 Scan Bindery Object 23 56 Change Bindery Object Security 23 57 Create Property 23 58 Delete Property 23 59 Change Bindery Security 23 60 Scan Property 23 61 Read Property Value 23 62 Write Property Value 23 63 Verify Bindery Object Password 23 64 Change Bindery Object Password 23 65 Add Bindery Object to Set 23 66 Delete Bindery Object from Set 23 67 Is Bindery Object in Set? 23 68 Close Bindery 23 69 Open Bindery 23 70 Get Bindery Access Level 23 71 Scan Bindery Object Trustee Paths 23 72 Get Bindery Object Access Level 23 73 Is Calling Station a Manager? 23 74 Keyed Verify Password 23 75 Keyed Change Password 23 76 List Relations of an Object Обслуживание каналов 19 - Get Station Number 23 20 Login Object 23 23 Get Login Key 23 24 Keyed Object Login 23 26 Get Internet Address 23 27 Get Object Connection List 23 28 Get Station’s Logged Information 23 29 Change Connection State 23 30 Watchdog Interval 23 31 Get Connection List from Object 24 - End of Job 25 - Logout 33 - Negotiate Buffer Size 88 01 Clear Connection Number List 97 - Get Big Packet NCP Max Packet Size Работа с расширенными атрибутами 86 01 Close Extended Attribute Handle 86 02 Write Extended Attribute 86 03 Read Extended Attribute 86 04 Enumerate Extended Attribute 86 05 Duplicate Extended Attribute Работа с каталогами и файлами 18 - Get Volume Info with Number 22 00 Set Directory Handle 22 01 Get Directory Path 22 02 Scan Directory Information 22 04 Modify Maximum Rights Mask 22 05 Get Volume Number 22 06 Get Volume Name 22 10 Create Directory 22 11 Delete Directory 22 12 Scan Directory for Trustee 22 13 Add Trustee to Directory 22 14 Delete Trustee from Directory 22 15 Rename Directory 22 18 Allocate Permanent Directory Handle 22 19 Allocate Temporary Directory Handle
22 20 Deallocate Directory Handle 22 21 Get Volume Info with Handle 22 22 Allocate Special Temporary Directory Handle 22 23 Map Directory Number to Path 22 25 Set Directory Information 22 26 Get Path Name of a Volume-Directory Number Pair 22 29 Get Effective Directory Rights 22 30 Scan a Directory 22 31 Get Directory Entry 22 32 Scan Volume’s User Disk Restrictions 22 33 Add User Disk Space Restriction 22 34 Remove User Disk Space Restrictions 22 35 Get Directory Disk Space Restriction 22 36 Set Directory Disk Space Restrictions 22 37 Set Directory Entry Information 22 38 Scan File or Directory for Extended Trustee 22 39 Add Extended Trustee to Directory or File 22 40 Scan Directory Disk Space 22 41 Get Object Disk Usage and Restrictions 22 42 Get Effective Rights for Directory Entry 22 43 Remove Extended Trustee to Directory or File 22 44 Get Volume and Purge Information 22 45 Get Directory Information 22 46 Rename or Move 22 48 Get Name Space Directory Entry 22 49 Open Data Stream 22 50 Get Object Effective Rights for Directory Entry 22 51 Get Extended Volume Information 23 15 Scan File Information 23 16 Set File Information 23 26 Purge All Erased Files 61 - Commit File 62 - File Search Initialize 63 - File Search Continue 64 - Search for a File 66 - Close File 67 - Create File 68 - Erase File 69 - Rename File 70 - Set File Attributes 71 - Get Current Size of File 72 - Read from a File 73 - Write to a File 74 - Copy from One File to Another 75 - Set File Time Date Stamp 78 - Allow Task to Access File 79 - Set File Extended Attributes 84 - Open/Create File 85 - Get Sparse File Data Block Bit Map 87 01 Open/Create File or Subdirectory
87 03 Search for a File or Subdirectory 87 04 Rename or Move a File or Subdirectory 87 05 Scan File or Directory for Trustee 87 08 Delete a File or Subdirectory 87 09 Set Short Directory Handle 87 10 Add Trustee Set to File or Subdirectory 87 11 Delete Trustee Set from File or Subdirectory 87 12 Allocate Short Directory Handle 87 17 Recover Salvageable File 87 18 Purge Salvageable File 87 19 Get Name Space Information 87 20 Search for a File or Subdirectory Set 87 21 Get Path String from Short Directory Handle 87 22 Generate Directory Base and Volume Number 87 23 Query Name Space Information Format 87 24 Get Name Space Loaded List from Volume Number 87 25 Set Name Space Information 87 26 Get Huge Name Space Information 87 27 Set Huge Name Space Information 87 28 Get Full Path String 90 00 Parse Tree 90 150 File Migration Request Среда файл-сервера 15 - Locate a Resource 16 - Deallocate a Resource 20 - Get File Server Data and Time 23 05 Get File Server Login Status 23 12 Verify Serialization 23 14 Get Disk Utilization 23 17 Get File Server Information 23 18 Get Network Serial Number 23 23 Get File Server LAN I/O Statistics 23 200 Check Console Privileges 23 201 Get File Server Description String 23 202 Set File Server Date and Time 23 203 Disable File Server Login 23 204 Enable File Server Login 23 207 Disable Transaction Tracking 23 208 Enable Transaction Tracking 23 211 Down File Server 23 212 Get File System Statistics 23 213 Get Transaction Tracking Statistics 23 214 Read Disk Cache Statistics 23 215 Get Drive Mapping Table 23 216 Read Physical Disk Statistics 23 217 Get Disk Channel Statistics 23 221 Get Physical Record Locks by Connection and File
23 227 Get LAN Driver 23 229 Get Connection Usage Statistics 23 230 Get Object’s Remaining Disk Space 23 232 Get File Server Misc Information 23 233 Get Volume Information 23 234 Get Connection’s Task Information 23 235 Get Connection’s Open Files 23 236 Get Connections Using a File 23 237 Get Physical Record Locks by Connection and File 23 238 Get Physical Record Locks by File 23 239 Get Logical Records by Connection 23 240 Get Logical Record Information 23 241 Get Connection’s Semaphores 23 242 Get Semaphore Information 23 245 Get File Server Extended Misc Information 23 246 Get Volume Extended Miscellaneous Information 23 252 Release a Resource 23 253 Send Console Broadcast 23 254 Clear Connection Number Работа с сообщениями 21 01 Get Broadcast Message 21 02 Disable Broadcasts 21 03 Enable Broadcasts 21 04 Send Personal Message 21 05 Get Personal Message 21 06 Open Message Pipe 21 07 Close Message Pipe 21 08 Check Pipe Status 21 09 Broadcast to Console 21 10 Send Broadcast Message 23 13 Log Network Message Работа с принтером и очередями 17 00 Write to Spool File 17 01 Close Spool File 17 02 Set Spool File Flags 17 03 Spool a Disk File 17 04 Scan Spool File Queue 17 05 Delete Spool File 17 06 Get Printer Status 17 09 Create Spool File 17 10 Get Printer’s Queue 23 137 Get Queue Jobs from Form List Работа с очередями 23 100 Create Queue 23 101 Destroy Queue 23 110 Change Queue Job Position 23 111 Attach Queue Server to Queue 23 112 Detach Queue Server from Queue 23 116 Change to Client’s Rights 23 117 Restore Queue Server Rights 23 119 Set Queue Server Current Status 23 121 Create Queue Job and File 23 122 Read Queue Job Entry
23 123 Change Queue Job Entry 23 124 Service Queue Job 23 125 Read Queue Current Status 23 126 Set Queue Current Status 23 127 Close a File and Start Queue Job 23 128 Remove Job from Queue 23 129 Get Queue Job List 23 130 Change Jobiority 23 131 Finish Servicing Queue Job 23 132 Abort Servicing Queue Job 23 134 Read Queue Server Current Status 23 135 Get Queue Job File Size Синхронизация 01 - File Set Lock 02 - File Release Lock 05 - Release File 06 - Release File Set 07 - Clear File 08 - Clear File Set 11 - Clear Logical Record 12 - Release Logical Record 13 - Release Logical Record Set 14 - Clear Logical Record Set 28 - Release Physical Record 29 - Release Physical Record Set 30 - Clear Physical Record 31 - Clear Physical Record Set 105 - Log File 106 - Lock File Set 107 - Log Logical Record 108 - Lock Logical Record Set 109 - Log Physical Record 110 - Lock Physical Record Set 111 00 Open/Create Semaphore 111 01 Close Semaphore 111 02 Wait on Semaphore 111 03 Signal Semaphore 111 04 Examine Semaphore Отслеживание транзакций 34 00 TTS Is Available 34 01 TTS Begin Transaction 34 02 TTS End Transaction 34 03 TTS Abort Transaction 34 04 TTS Transaction Status 34 05 TTS Get Application Thresholds 34 06 TTS Set Application Thresholds 34 07 TTS Get Workstation Thresholds 34 08 TTS Set Workstation Thresholds 34 09 TTS Get Transaction Bits 34 10 TTS Set Transaction Bits Служба каталогов NetWare 104 01 Ping for NDS NCP 104 02 Send NDS Fragmented Request/Reply 104 03 Close NDS Fragment 104 04 Return Bindery Context 104 05 Monitor NDS Connection Работа со статистикой 123 01 Get Cache Information
123 02 Get File Server Information 123 03 NetWare File Systems Information 123 04 User Information 123 05 Packet Burst Information 123 06 IPX/SPX Information 123 07 Garbage Collection Information 123 08 CPU Information 123 09 Volume switch Information 123 10 Get NLM Loaded List 123 11 NLM Information 123 12 Get Directory Cache Information 123 13 Get Operating System Version Information 123 14 Get Active Connection List by Type 123 15 Get NLM Resource Tag List 123 20 Active LAN Board List 123 21 LAN Configuration Information 123 22 LAN Common Counters Information 123 23 LAN Custom Counters Information 123 25 LSL Information 123 26 LSL Logical Board Information 123 30 Get Media Manager Object Information 123 31 Get Media Manager Objects List 123 32 Get Media Manager Children’s List 123 33 Get Volume Segment List 123 40 Active Protocol Stacks 123 41 Get Protocol Stack Configuration Information 123 42 Get Protocol Stack Statistics Information 123 43 Get Protocol Stack Custom Information 123 44 Get Protocol Stack Numbers by Media Number 123 45 Get Protocol Stack Numbers by LAN Board Number 123 46 Get Media Name by Media Number 123 47 Get Loaded Media Number List 123 50 Get General Router and SAP Information 123 51 Get Network Router Information 123 52 Get Network Routers Information 123 53 Get Known Networks Information 123 54 Get Server Information 123 55 Get Server Sources Information 123 56 Get Known Servers Information 123 60 Get Server Set Commands Information 123 61 Get Server Set Categories

Таблица операций службы каталогов Netware


10.5 Таблица операций службы каталогов Netware

Семенов Ю.А. (ГНЦ ИТЭФ)

Код операции Описание 0x01 Resolve Name 0x02 Read Entry Information 0x03 Read 0x04 Compare 0x05 List 0x06 Search Entries 0x07 Add Entry 0x08 Remove Entry 0x09 Modify Entry 0x0A Modify Relative Distinguished Name 0x0B Define Attribute 0x0C Read Attribute Definition 0x0D Remove Attribute Definition 0x0E Define Class 0x0F Read Class Definition 0x10 Modify Class Definition 0x11 Remove Class Definition 0x12 List Containable Classes 0x13 Get Effective Rights 0x14 Add Partition 0x15 Remove Partition 0x16 List Partitions 0x17 Split Partition 0x18 Join Partition 0x19 Add Replica (копия секции каталога) 0x1A Remove Replica 0x1B Open Stream 0x1D Create Subordinate Reference 0x1E Link Replica 0x1F Change Replica Type 0x20 Start Update Schema 0x21 End Update Schema 0x22 Update Schema 0x23 Start Update Replica 0x24 End Update Replica 0x25 Update Replica 0x26 Synchronize Partition 0x27 Synchronize Schema 0x29 Get Replica Root ID 0x2A Begin Move Entry 0x2B Finish Move Entry 0x2C Release Move Entry 0x2D Backup Entry 0x2E Restore Entry 0x32 Close Iteration 0x35 Get Server Address 0x36 Set Keys 0x3B Begin Authentication 0x3C Finish Authentication 0x3F Repair Timestamps 0x40 Create Back Link 0x41 Delete External Reference 0x42 Rename External Reference 0x43 Create Entry Directory 0x44 Remove Entry Directory 0x45 Designate New Master 0x46 Change Tree Name 0x47 Partition Entry Count 0x48 Check Login Restrictions 0x49 Start Join 0x4A Low Level Split 0x4B Low Level Join 0x4C Abort Low Level Join 0x4D Get All Servers

Таблица типов кадров управления доступом для сети Token Ring


10.6 Таблица типов кадров управления доступом для сети Token Ring

Семенов Ю.А. (ГНЦ ИТЭФ)

Код команды

Наименование

Класс адресата

Класс отправителя

0x0 Отклик (является реакцией на команды управления доступом) Источник запроса Рабочая станция 0x2 Аварийный сигнал (используется станциями для восстановления работоспособности после устойчивой ошибки) Рабочая станция кольца Рабочая станция кольца 0x3 Запрос маркера (используется для выбора активного монитора) Рабочая станция Рабочая станция 0x4 Очистка кольца (посылается активным монитором для повторного запуска маркерного доступа) Рабочая станция Рабочая станция 0x5 Активное мониторирование (используется активным монитором для опроса кольца) Рабочая станция Рабочая станция 0x6 Резервное мониторировние (используется дополнительным монитором для опроса кольца) Рабочая станция Рабочая станция 0x7 Проверка дублирования адреса (посылается станцией самой себе после подключения к кольцу) Рабочая станция Рабочая станция 0x8 Проверка среды ответвителя (проверяется целостность адаптера станции и ответвителя) Рабочая станция Рабочая станция 0x9 Пересылка вперед (служит для проверки наличия пути между станциями) Рабочая станция Сервер конфигурации 0xB Удаление станции из кольца (если станция получает кадр с таким кодом и своим адресом получателя, она должна отключиться от сети) Рабочая станция Сервер конфигурации 0xC Изменение параметров (используется сервером конфигурации для информирования станций об изменении параметров адаптера) Рабочая станция Сервер конфигурации 0xD Инициализация станции (используется сервером параметров для пересылки данных в адаптер станции при ее инициализации) Рабочая станция Сервер параметров кольца 0xE Запрос адреса станции (посылается серверу конфигурации в ответ на запрос) Рабочая станция Сервер конфигурации 0xF Запрос состояния станции (Посылается сервером конфигурации для получения данных о состоянии станции) Рабочая станция Сервер конфигурации 0x10 Запрос подключения станции (используется станцией в ответ на запрос сервера конфигурации о подключении) Рабочая станция Сервер конфигурации 0x20 Запрос инициализации (используется для получения данных от сервера параметров) Сервер параметров кольца Рабочая станция 0x22 Запрос об адресе станции (посылается сервером конфигурации стации с целью определения ее адреса) Сервер конфигурации Рабочая станция 0x23 Запрос о состоянии станции (запрос о состоянии станции, посылаемый сервером конфигурации) Сервер конфигурации Рабочая станция 0x24 Запрос о подключении станции (используется сервером конфигурации для получения данных об адаптере станции) Сервер конфигурации Рабочая станция 0x25 Сообщение нового активного монитора (используется новым активным монитором для информирования о себе сервера конфигурации) Сервер конфигурации Рабочая станция 0x26 Сообщение об изменении адреса предшественника (используется станцией для сообщения серверу конфигурации об изменении ближайшего активного предшественника) Сервер конфигурации Рабочая станция 0x27 Сообщение о незавершенном опросе кольца (используется активным монитором для передачи монитору ошибок сообщений о нарушении порядка опроса) Монитор ошибок Рабочая станция 0x28 Сообщение об ошибке монитора (используется станцией для оповещения монитора ошибок о сбоях) Монитор ошибок Рабочая станция 0x29 Сообщение об ошибке (используется станциями для передачи серверу ошибок содержимого счетчиков нестабильных ошибок) Монитор ошибок Рабочая станция 0x2A Отклик на передачу вперед (используется станцией для передачи серверу конфигурации результата передачи вперед) Сервер конфигурации Рабочая станция

Технические средства сетевой безопасности


6.1 Технические средства сетевой безопасности

Семенов Ю.А. (ГНЦ ИТЭФ)

Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли и спросить не с кого. Начинать надо с того, что в вашей власти, а это прежде всего правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (Uninterruptable Power Supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При снижении напряжения сети переменного тока ниже определенного уровня UPS (около 208v) отключает потребителя от сети и осуществляет питание ЭВМ от ~220v, получаемого от аккумулятора самого UPS. Учитывая нестабильность напряжения сети в России, можно считать полезным применение активных стабилизаторов на входе UPS.

При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использование специального интерфейса и соответствующего программного обеспечения, работающего согласно протокола SNMP(см. рис. 6.1.1).

Рис. 6.1.1. Схема подключения UPS.

При исчезновении первичного напряжения ~220V спустя некоторое время UPS выдает сигнал shutdown вычислительной машине. Современный UPS может мониторировать не только напряжение питание, но температуру окружающей среды, своевременно осуществляя спасение жизненно важных файлов до наступления чрезмерного перегрева системы. При этом значение напряжения питания и температуры можно считывать с использованием протокола SNMP. Некоторые продвинутые системы автономного питания допускают подключение агентов SNMP непосредственно к локальной сети, что открывает дополнительные возможности дистанционного управления и мониторинга.


Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах или трубах, что сделает подключение к ним более затруднительным. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоение хакером “чужого” MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня.

Активные разработки в последнее время ведутся в области систем идентификации, базирующихся на распознавания отпечатков пальцев, ладони, подписи или голоса. Для этих целей используются новейшие достижения в области быстрых Фурье-преобразований, нейронных сетей и пр. В качестве вводных устройств используются оптические сканеры, а также резистивные экраны. Для ввода подписи служат специальные планшеты , а также изощренные методы сравнения и установления идентичности.

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



Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа Exabyte емкостью 2.5-10Гбайт еще достаточно широко используются, высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи на них оставляет желать лучшего). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более .

В последнее время широкое распространение получают панели касания, способные распознавать людей по отпечатку пальца или ладони (см. http://elce.quarta.msk.ru/UCC/t_scrb_e.htm). Сходные устройства используются для непосредственного ввода подписи клиента (устройство типа планшет, иногда совмещаемое с дисплеем) и сверки ее с имеющимся образцом.




Типы субвекторов кадров управления доступом


10.7 Типы субвекторов кадров управления доступом

Семенов Ю.А. (ГНЦ ИТЭФ)

Тип

Наименование

Значение

0x01 Аварийный сигнал 0001 - установлен режим восстановления

0002 - в кольце потерян сигнал

0003 - борьба за монитор завершилась неудачей, нет кадров запроса маркера 0x02 Ближайший активный предшественник Адрес станции - активного предшественника (нуль, если предшественник не выявлен) 0x03 Номер локального кольца Номер локального кольца передающего адаптера 0x04 Задание номера физического отвода Задает номер физического отвода для адаптера 0x05 Значение таймера для сообщения о неустойчивой ошибке Время в мсек для таймера неустойчивой ошибки адаптера 0x06 Классы допустимых функций Классы отправителей, которым разрешена передача 0x07 Приоритет разрешенного доступа Максимальный приоритет маркера, при котором адаптеру разрешена передача (0-3) 0x08 Разрешенная среда 0 - несанкционированный режим сети

1 - санкционированный режим 0x09 Коррелятор Используется для связи кадров друг с другом 0x0A Последний адрес при опросе кольца Адрес станции, передавшей последний кадр наличия активного или резервного монитора перед нарушением режима опроса кольца 0x0B Номер физического отвода Номер физического отвода адаптера (назначается администратором) 0x20 Код отклика Код, используемый в кадре управления доступом:

0x001 - положительный отклик

0x8003 - команда не поддерживается

0x7007 - потерян необходимый субвектор

0x800A - операция заблокирована 0x21 Модификатор адреса Посланный модификатор адреса адаптера не поддерживается 0x22 Идентификатор устройства Идентифицирует параметры адаптера (код модели, имя фирмы производителя и пр.) 0x23 Характеристика программного обеспечения Версия драйвера адаптера 0x26 Перенос данных Заполнитель данных в кадрах управления доступом при проверке сетевой среды 0x27 Передача кадра Кадр Token Ring, который быть должен передан адаптером получателю. Используется сервером конфигурации для тестирования маршрутов

Транспортный протокол реального времени RTCP


4.4.9.3 Транспортный протокол реального времени RTCP

Семенов Ю.А. (ГНЦ ИТЭФ)

Управляющий протокол RTCP (RTP control protocol; см. RFC-1889 “RTP: A Transport Protocol for Real-Time Applications” H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и используется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции:

1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [1,2], но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.

2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.

3. Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно скорость передачи должна контролироваться для того, чтобы RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов.


Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname.

Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено.

Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:

Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.

SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye.

Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.

SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала.

Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.

Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 4.4.9.3.1. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.



Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).



Рис. 4.4.9.3.1. Пример составного пакета RTCP (#: SSRC/CSRC)

Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, при аудио конференциях информационный поток всегда ограничен (сколько бы не было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако, трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.

Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP).

Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола – переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.

Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:

o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.



o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.

o Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников [3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.

o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.

Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.

Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.

Участник может пометить другой узел как пассивный, или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута.

Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин.



Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, специфического для конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не посылать более никакой дополнительной информации. name может быть присвоен более высокий приоритет чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как Email может отображаться только при запросе. При каждой RTCP рассылке, должны посылаться RR- и SDES-пакеты. Последний содержит элемент Cname. Для небольших сессий, работающих с минимальными периодами рассылки, это будет делаться в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент name, и каждый восьмой раз (2 минуты) это будет элемент Email.

Когда несколько приложений работают одновременно, например, в случае мультимедиа конференции, допускается, чтобы дополнительная информация пересылалась только в рамках одной RTP-сессии. Остальные сессии будут использовать только элемент cname.

RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственным различием между формами отчета отправителя (SR) и получателя (rr), помимо кода типа пакета, является то, что отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отправляется пакет RR.



Как SR так и RR-формы включают в себя нуль или более блоков отчетов о приеме, один для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.

Пакет отчета отправителя состоит из трех секций (см. рис. 4.4.9.3.2), за которыми может следовать четвертая, которая определяется, если необходимо, профайлом. Первая секция – заголовок, имеет 8 октетов. Эта секция содержит следующие поля:

Версия (v): 2 бита

Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.

Заполнитель (p): 1 бит

Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.



Рис. 4.4.9.3.2. Формат RTCP пакета сообщения отправителя

Число отчетов о приеме (RC): 5 бит

Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль.

Тип пакета(pt): 8 бит

Содержит константу 200 для пакетов RTCP SR.

Длина: 16 бит

Длина rtcp-пакета в 32-битных словах минус один, включая заголовок и заполнитель.

ssrc: 32 бит

Идентификатор источника синхронизации для отправителя sr-пакета.

Вторая секция информации из 20 октетов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения:

Временная метка NTP: 64 бита

Указывает абсолютное время, когда данный доклад был послан, оно может быть использовано в комбинации с временными метками, присланными в докладах о приеме другими получателями, для измерения RTT до этих получателей.



Временная метка rtp: 32 бита

Соответствует тому же времени, что и временная метка ntp, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может быть использовано получателями, независящими от среды для оценки номинальной задающей частоты RTP. Заметьте, что в большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах.

Число пакетов отправителя: 32 бита

Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор.

Число октетов отправителя: 32 бита

Полное число октетов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Это поле может быть использовано для оценки среднего потока данных.

Третья секция состоит из нуля или более блоков отчета о приеме в зависимости от числа источников, пакеты от которых приняты с момента последнего отчета. Каждый блок отчета о приеме несет в себе статистику получения RTP-пакетов, поступающих от одного из источников синхронизации. Получатель не сохраняет статистику, когда источник изменяет свой ssrc-идентификатор.

ssrc_n (идентификатор источника): 32 бита

ssrc-идентификатор источника, к которому относится информация, содержащаяся в блоке отчета о получении.

Доля потерянных (пакетов): 8 бит

Часть информационных RTP-пакетов от источника ssrc_n потерянная с момента посылки предыдущего SR или RR-пакетов, представленная в виде числа с фиксированной запятой, помещенной слева. Это эквивалентно целому, полученному после умножения данного числа на 256. Эта доля получается в результате деления числа потерянных пакетов на ожидаемое число пакетов. Если потери из-за дубликатов оказались отрицательны, доля потерянных пакетов объявляется равной нулю. Заметим, что от источника, все пакеты которого были потеряны при транспортировке отчета о приеме послано не будет.



Суммарное число потерянных пакетов: 24 бита

Полное число информационных RTP-пакетов от источника SSRC_n, которые были потеряны с момента начала передачи. Это число определяется как разность между ожидаемым и полученным числами пакетов, где число полученных включает в себя и дубликаты. Таким образом, пакеты, пришедшие с опозданием, не считаются потерянными, а число потерянных пакетов может оказаться отрицательным, если получены дубликаты пакетов. Число ожидаемых пакетов определяется как разность между номером последнего полученного пакета и номером первого пакета.

Наибольший номер из числа полученных пакетов

: 32 бита

Младшие 16 бит содержит наибольший порядковый номер полученного от источника SSRC_n информационного RTP-пакета. Старшие 16 бит несут в себе число циклов нумерации (переполнения счетчика номеров пакетов). Заметим, что различные получатели в рамках одной и той же сессии генерируют разные коды циклов нумерации (расширений), если они начали свою работу в разное время.

Разброс времени доставки: 32 бита

Оценка статистической вариации периода прихода RTP-пакетов, измеряемого с помощью временных меток и характеризуемого целым числом. Разброс периода прихода пакетов j определяется как усредненное отклонение разности D расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов.

Если si равно временной метке i-го пакета RTP, а ri – время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как

di,j =(rj-ri)-(sj-si)=(rj-sj)-(ri-si)

Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле

j=j+(|di-1,i|-j)/16

Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Это алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4].



Последняя временная метка (LSR) (last SR): 32 бита

Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль.

Задержка с момента последнего SR (DLSR- delay of last sr): 32 бита

Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от ssrc_n пока не получено, в поле DLSR заносится нуль.

Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить циклическую задержку маршрута RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A - LSR- DLSR). Это проиллюстрировано на рис. 4.4.9.3.3.

Это может быть использовано в качестве меры расстояния до кластера получателей, хотя некоторые связи имеют весьма асимметричный характер задержек.

rr: rtcp-пакет отчета о приеме (RFC-1889)

[10 nov 1995 11:33:25.125] [10 nov 1995 11:33:36.5]

n sr(n) a=b710:8000 (46864.500 s)

---------------------------------------------------------------->

v ^

ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)

ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)

(3024992016.125 s) v ^

r v ^ rr(n)

---------------------------------------------------------------->

||

(5.250 s)

a 0xb710:8000 (46864.500 s)

dlsr -0x0005:4000 ( 5.250 s)

lsr -0xb705:2000 (46853.125 s)

-------------------------------

delay 0x 6:2000 ( 6.125 s)

Рис. 4.4.9.3.3. Пример вычисления rtt



Рис. 4.4.9.3.4. Формат пакета отчета о приеме (RR)

Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.



Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0).

Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек:

меньше октетов в пакете (нет rtcp-заголовка или поля SSRC);

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

Если необходима дополнительная информация, она должна быть включена в первую очередь в расширение для отчета отправителя, но не будет присутствовать в отчетах о приеме. Если должна быть подключена информация о получателях, эти данные могут структуризоваться в виде массива блоков дополнительно к существующему массиву блоков-отчетов, т.е., число блоков будет задано полем RC.

Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена.

На основе информации отправителя независимый монитор может вычислить усредненное значение потока данных, не получая этих данных. Если можно предположить независимость вероятности потери пакета от его размера, тогда число полученных пакетов, умноженное на средний размер поля данных, может дать оценку для пропускной способности получателя.

Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на рис. 4.4.9.3.5 информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.





Рис. 4.4.9.3.5. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

SDES: RTCP-пакет описания источника



Рис. 4.4.9.3.6. Формат пакета SDES

Пакет SDES состоит из заголовка и нескольких фрагментов, каждый из которых содержит элементы описания источника, соответствующего данному фрагменту (число фрагментов может быть равно нулю).

Поля версия (v), заполнитель (p) и длина имеют то же назначения что и в случае SR-пакетов.

Тип пакета (pt): 8 бит

Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES.

Число источников (SC): 5 бит

Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно.

Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов.

Текст кодируется согласно требованиям UTF-2, описанным в стандарте 10646 [5,6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", “X/open preliminary specification”, документ номер P316 и “Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1.

Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны.



Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31.

Из числа SDES-элементов только cname является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, с тем чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA.

cname: Канонический идентификатор конечной системы (рис. 4.4.9.3.7).



Рис. 4.4.9.3.7. Формат Cname

Идентификатор cname имеет следующие свойства:

Так как характеризуемый случайным числом идентификатор ssrc может измениться, если обнаруживается конфликт или если программа перезапускается, элемент cname должен обеспечить связь между идентификатором SSRC и источником, которая должна оставаться неизменной.

Подобно идентификатору SSRC, идентификатор cname должен быть уникальным для каждого из участников RTP-сессии.

Чтобы обеспечить связь между мультимедийными средствами, используемыми одним и тем же участником в наборе взаимосвязанных RTP-сессий, cname должно быть зафиксировано для данного участника.

Для того чтобы обеспечить независимый мониторинг, Cname должно быть удобным средством идентификации источника как для программы, так и для человека.

Следовательно, cname должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию следует использовать описанный ниже формат, если другой синтаксис или семантика не задана. Элемент cname должен иметь формат "user@host", или "host", если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов, "host" является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9]; или стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена. Например, стандартное ASCII-представление IP-адреса (версия 4) в "точечно-цифровом" виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно получить. Примерами могут служить "dwarf@sleepy.beauty.com" или "dwarf@192.166.148.9" для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить “sleepy.beauty.com" или "192.166.148.9".



Имя пользователя должно иметь форму, которая может быть использована в запросах "Finger" или "Talk", т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника.

Этот синтаксис не обеспечит уникальность имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника, или на профайл, для которого приложение должно будет специфицировать синтаксис идентификаторов cname.

Если каждое приложение создает свои cname независимо, в результате можно получить дублирующие имена. Если необходимо осуществить связь между сессиями, работающими в разных средах, должны быть использованы специальные средства, которые с одной стороны обеспечат уникальность имен, а с другой припишут идентичные имена источникам, размещенным в одной ЭВМ, но работающих с разными средами.

Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10]) может привести к появлению имен дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [11].) Для того чтобы разрешать такие конфликты приложение должно иметь средства для выработки и присвоения уникальных имен cname.

Name: Имя пользователя (рис. 4.4.9.3.8).



Рис. 4.4.9.3.8. Формат элемента Name

Это настоящее имя, используемое для описания источника, напр., "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо cname. Такой приоритет может быть установлен профайлом. Значение name предполагается неизменным, по крайней мере в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.



Email: Адрес электронной почты (рис. 4.4.9.3.9).



Рис. 4.4.9.3.9. Формат элемента Email

Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822 [12], например, "yuri.semenov@itep.ru". Значение элемента Email предполагается неизменным в пределах сессии.

phone: Телефонный номер



Рис. 4.4.9.3.10. Формат элемента phone

Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, , "+7 095 129 9442" для номера в России.

LOC: Географический адрес пользователя



Рис. 4.4.9.3.11. Формат элемента LOC

Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 322, itep bl 180". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.

TOOL: Имя приложения или программного средства



Рис. 4.4.9.3.12. Формат элемента TOOL

Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, напр., "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.

Note: Уведомление/статус



Рис. 4.4.9.3.13. Формат элемента Note

Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент note предназначен для сообщений, характеризующих текущее состояние источника, напр., "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.

Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме cname), такие как Name, может быть уменьшена с тем, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент note передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако, получатели должны рассматривать элемент Note потерявшим актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.



PRIV: Элемент частного расширения SDES



Рис. 4.4.9.3.14. Формат элемента расширения PRIV

Этот элемент используется, для того чтобы определить экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента, и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным и никакой другой элемент priv не может иметь такое же. Разработчик приложения может выбрать имя приложения плюс, если необходимо, дополнение.

Заметьте, что префикс занимает некоторое место, из числа 255 октетов элемента, по этой причине желательно, чтобы он был короче.

Префиксы SDESpriv не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи.

Bye: Пакет завершения сессии RTCP



Рис. 4.4.9.3.15. Формат пакета Bye

Пакет Bye указывает на то, что один или более источников покинули сессию.

Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов

Тип пакета (PT): 8 бит

Содержит код 203, который указывает на то, что это RTCP пакет Bye.

Число источников (SC): 5 бит

Число фрагментов SSRC/CSRC, содержащихся в данном bye-пакете. Значение нуль допустимо, но бесполезно.

Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.



app: RTCP-пакет, определенный приложением



Рис. 4.4.9.3.16. Формат пакета, задаваемого приложением

Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета.

Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов.

Субтип: 5 бит

Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения.

Тип пакета (PT): 8 бит

Содержит код 204, который указывает на то, что это RTCP пакет APP.

Имя: 4 октета

Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.

Поле информация, зависящая от приложения имеет переменную длину.

Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.

Обработка RTCP в трансляторах

Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя.



Транслятор, который не модифицирует информационные пакеты, например такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации, так чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.

Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.

Блоки отчетов о приеме SR/RR: Транслятор переадресует доклады о приеме, полученные из одной области сети в другие. Заметим, что эти сообщения движутся в направлении противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет, и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.

Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, для того чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору.

SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии. Но они могут, например, решить отфильтровывать некоторую информацию, если этого требуют ограничения пропускной способности. Транслятор, который генерирует свои собственные RR-пакеты, должен посылать SDES CNAME-информацию о самом себе в область сети, куда он шлет эти RR-пакеты.



BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации.

APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.

Обработка RTCP в смесителях

Так как смеситель генерирует, свой собственный информационный поток, он не пропускает через себя SR или RR-пакеты и вынужден формировать новые пакеты для отправки в обоих направлениях.

Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток.

Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.

SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут отфильтровывать любую SDES-информацию помимо CNAME в случае ограничения полосы пропускания. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. (Идентификатор в списке CSRC, сгенерированный смесителем может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой.) Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.

Так как смесители не переадресуют SR или RR пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR или RR пакет, посылаемый смесителем.

Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обоих сетевых областей оказываются независимыми.



BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.

APP. Обработка APP-пакетов смесителями зависит от вида приложения.

Таблица 4.4.9.3.1. Типы пакетов RTCP



Сокращенное название

Имя

Значение
SR sender report – сообщение отправителя 200
RR receiver report – сообщение получателя 201
SDES source description – описание источника 202
BYE goodbye - завершение 203
APP application-defined – определен приложением 204
Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных равному 1 (так как статические типы поля данных обычно лежат в младшей половине).

Другие константы определены IANA. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет.

Таблица 4.4.9.3.2. Типы SDES



Сокращенное название

Имя

Значение
END Конец списка SDES 0
CNAME Каноническое имя 1
NAME Имя пользователя 2
EMAIL Электронный адрес пользователя 3
PHONE Телефонный номер пользователя 4
OC geographic user location 5
TOOL Имя приложения или программного средства 6
NOTE notice about the source 7
PRIV Частные расширения 8
Типы пакетов RTCP. Могут быть определены и зарегистрированы IANA новые, специфические для определенных классов приложений типы пакетов RTCP.

Период отчетов RTCP. Профайл должен специфицировать, какие значения констант будут использоваться для вычисления периода посылки RTCP докладов. Это доля полосы пропускания выделенная для RTCP, минимальный период посылки отчетов.



Расширения SR/RR. Секция расширения может быть определена для RTCP SR и RR пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.

Проверка корректности заголовка RTCP

Пакеты RTCP подвергаются следующим проверкам.

RTP поле версии должно быть равно 2.

Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.

Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP пакета, так как заполнитель может присутствовать только в последнем.

Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

Фрагмент приведенной ниже программы выполняет все рассмотренные проверки (текст взят из ссылки, приведенной в начале раздела). Тип пакета для последующих пакетов не проверяется, так как не известный тип пакета должен игнорироваться.

u_int32 len; /* Длина составного RTCP пакета в словах */

rtcp_t *r; /* заголовок RTCP */

rtcp_t *end; /* Конец составного RTCP пакета */

if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {

/* что-то не в порядке с форматом пакета */

}

end = (rtcp_t *)((u_int32 *)r + len);

do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);

while (r < end && r->common.version == 2);

if (r != end) {

/* что-то не в порядке с форматом пакета */

}

Генерирование пакетов SDES RTCP

Эта функция формирует фрагмент SDES, состоящий из элементов argc, взятых из массивов type, в буфере b.

char *rtp_write_sdes(char *b, u_int32 src, int argc,

rtcp_sdes_type_t type[], char *value[],

int length[])

{

rtcp_sdes_t *s = (rtcp_sdes_t *)b;

rtcp_sdes_item_t *rsp;

int i;

int len;

int pad;

/* SSRC header */

s->src = src;

rsp = &s->item[0];

/* SDES items */

for (i = 0; i < argc; i++) {

rsp->type = type[i];

len = length[i];

if (len > RTP_MAX_SDES) {

/* неверная длина, возможно нужны другие действия */

len = RTP_MAX_SDES;

}

rsp->length = len;

memcpy(rsp->data, value[i], len);



rsp = (rtcp_sdes_item_t *)&rsp->data[len];

}

/* завершить конечным маркером и заполнителем на очередной 4-октетной границе */

len = ((char *) rsp) - b;

pad = 4 - (len & 0x3);

b = (char *) rsp;

while (pad--) *b++ = RTCP_SDES_END;

return b;

}

Разбор пакетов RTCP SDES

Эта функция осуществляет разбор пакета SDES, вызывая функции find_member() для поиска указателя на информацию для члена сессии с идентификатором SSRC и member_sdes() для запоминания новой информации SDES для этого участника. Этой функции необходим указатель на заголовок пакета RTCP.

void rtp_read_sdes(rtcp_t *r)

{

int count = r->common.count;

rtcp_sdes_t *sd = &r->r.sdes;

rtcp_sdes_item_t *rsp, *rspn;

rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)

((u_int32 *)r + r->common.length + 1);

source *s;

while (--count >= 0) {

rsp = &sd->item[0];

if (rsp >= end) break;

s = find_member(sd->src);

for (; rsp->type; rsp = rspn ) {

rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);

if (rspn >= end) {

rsp = rspn;

break;

}

member_sdes(s, rsp->type, rsp->data, rsp->length);

}

sd = (rtcp_sdes_t *)

((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);

}

if (count >= 0) {

/* некорректный формат пакета */

}

}

Вычисление периода рассылки RTCP

Следующая функция в качестве результата выдает время между посылками RTCP-пакетов, измеренное в секундах. Она должна вызываться после посылки одного составного RTCP-пакета для вычисления времени до посылки следующего пакета. Эта функция должна также вызываться для вычисления времени посылки первого RTCP-пакета при запуске. Это исключает любые кластеры RTCP-пакетов, если приложение запущено в нескольких узлах одновременно, например, в результате объявления об открытии сессии.

Параметры имеют следующий смысл:

rtcp_bw: Предельная полоса RTCP, т.е., полная пропускная способность, которая будет использоваться для RTCP-пакетов всеми участниками сессии, выраженная в октетах в секунду. Она должна быть порядка 5% от "полосы сессии", этот параметр задается при конфигурировании приложения.



senders: Число активных отправителей на момент посылки последнего отчета, известно из конструкции отчетов получателя.

members: Оценка числа членов сессии, включая нас самих. Инкрементируется, когда мы обнаруживаем новых членов сессии при получении RTP или RTCP-пакетов, и декрементируется, когда какой-либо участник покидает сессию (послав RTCP BYE) или он объявлен таковым по тайм-ауту (рекомендуемое время 30 минут). При первом вызове этот параметр должен иметь значение 1.

we_sent: Флаг, который равен true, если мы послали данные за время последних двух интервалов RTCP. Если флаг равен true, составной только что посланный пакет RTCP содержит SR пакет.

packet_size: Размер составного только что посланного пакета RTCP, в октетах, включая сетевую инкапсуляцию (напр., 28 октетов для UDP поверх IP).

avg_rtcp_size: Указатель оценщика размера составных пакетов RTCP; инициализируется и актуализуется для только что посланного пакета этой функцией, актуализуется также идентичной строкой программы приема пакетов RTCP для каждого пакета RTCP, полученного от другого участника сессии.

initial: Флаг, который равен true для первого вызова при инициализации с целью вычисления момента посылки первого отчета.

#include

double rtcp_interval(int members,

int senders,

double rtcp_bw,

int we_sent,

int packet_size,

int *avg_rtcp_size,

int initial)

{

/*

* Минимальное время между пакетами RTCP от данного узла (в секундах). Это время

* предотвращает группирование отчетов, когда в сессии участвует малое число

* участников. Это препятствует чрезмерному уменьшению интервалов межу отчетами.

*/

double const RTCP_MIN_TIME = 5.;

/*

* Доля полосы RTCP, которая должна быть поделена между активными участниками.

* (Эта доля была выбрана так, чтобы в типовой сессии с одним или двумя

* активными отправителями, вычисленный период посылки отчетов был примерно

* равен минимальному интервалу между отчетами. Доля получателя должна равняться

* 1 – доля отправителя.

*/

double const RTCP_SENDER_BW_FRACTION = 0.25;



double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);

/*

* Коэффициент преобразования (сглаживающая константа) для полосового

* фильтра, который используется при оценке среднего размера RTCP пакетов.

*/

double const RTCP_SIZE_GAIN = (1./16.);

double t; /* интервал */

double rtcp_min_time = RTCP_MIN_TIME;

int n; /* число участников, используемое при вычислении */

/*

* Самый первый вызов приложения использует вдвое меньшую

* минимальную задержку для ускорения оповещения, в то же время оставляя

* некоторое время до отчета для рэндомизации и получения информации

* о других источниках. Таким образом, установление корректного периода

* отчетов произойдет быстрее. Средний размер RTCP пакета

* устанавливается в начальный момент равным 128 октетам

* (предполагается, что все остальные генерируют SR вместо RR:

* 20 IP + 8 UDP + 52 SR + 48 SDES CNAME октетов).

*/

if (initial) {

rtcp_min_time /= 2;

*avg_rtcp_size = 128;

}

/*

* Если имелись активные отправители, надо им дать

* по крайней мере минимальную долю полосы RTCP.

* В противном случае все участники будут делить полосу RTCP поровну

*/

n = members;

if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {

if (we_sent) {

rtcp_bw *= RTCP_SENDER_BW_FRACTION;

n = senders;

} else {

rtcp_bw *= RTCP_RCVR_BW_FRACTION;

n -= senders;

}

}

/*

* Актуализация оценки среднего размера пакета отчета с учетом

* только что посланного пакета.

*/

*avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;

/*

* Эффективное число узлов, умножаем на средний размер пакета отчета

* и получаем полное число посланных октетов, если каждый из узлов

* посылает отчет. Деля это число на эффективную полосу,

* получаем средний временной интервал посылки пакетов-отчетов.

*/

t = (*avg_rtcp_size) * n / rtcp_bw;

if (t < rtcp_min_time) t = rtcp_min_time;

/*

* Для того чтобы избежать всплесков трафика из-за непреднамеренной

* синхронизации с другими узлами мы выбираем следующий интервал



* отчета равным случайному числу с равномерным распределением в

* диапазоне 0.5*t - 1.5*t.

*/

return t * (drand48() + 0.5);

}

Библиография

[1] I. Busse, B. Deffner, and H. Schulzrinne, " Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996.
[2] S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [24]
[3] J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987
[4] International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993
[5] The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987
[7] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987
[8] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989
[9] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994
[10] Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994
[11] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982
[12] W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968

Удаленный доступ (Telnet)


4.5.3 Удаленный доступ (Telnet)

Семенов Ю.А. (ГНЦ ИТЭФ)

TELNET позволяет пользователю установить TCP-соединение с сервером и затем передавать коды нажатия клавиш так, как если бы работа проводилась на консоли сервера. TELNET (RFC-854, в некоторых реализациях tn) служит для выполнения удаленного доступа к вычислительным ресурсам и базам данных (например, к базам ядерных данных в Вене, Брукхейвене или STN-international в Карлсруэ). Для входа в базу данных или ЭВМ обычно нужна аутентификация (ввод имени-идентификатора пользователя и его слова-пропуска). В некоторых реализациях допускается использование параметров, которые подключают необходимые эмуляторы терминалов.

TELNET предлагает три услуги: Определяет сетевой виртуальный терминал (NVT - network virtual terminal), который обеспечивает стандартный интерфейс к удаленной системе.

Включает механизм, который позволяет клиенту и серверу согласовать опции обмена

Обеспечивает симметрию соединения, допуская любой программе (например FTP) выступать в качестве клиента

Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в кодах ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т. д.). На прикладном уровне над TELNET находится либо программа поддержки реального терминала, либо прикладной процесс в обслуживающей машине, к которому осуществляется доступ с терминала. Формат NTV достаточно прост. Для данных используются 7-битовые ASCII коды. 8-битовые же октеты зарезервированы для командных последовательностей.

Telnet взаимодействует с другой ЭВМ через протокол TELNET. Если команда TELNET вводится без аргументов ЭВМ переходит в командный режим, напечатав приглашение telnet>. В этом режиме она воспринимает и исполняет команды, описанные ниже.

При вводе TELNET с аргументами программа осуществит связь вашей ЭВМ с удаленным компьютером, имя или адрес которого вы ввели в качестве одного из аргументов.


После того как TELNET связь установлена, начинаются переговоры об используемых опциях (см. табл. 4.5.3.1). Каждая из договаривающихся сторон может послать другой один из четырех запросов will, do, wont и dont (см табл. 4.5.3.4).

Далее TELNET переходит в режим ввода. В этом режиме любой введенный текст пересылается удаленной ЭВМ. Ввод может производиться посимвольно или построчно. При посимвольном режиме каждый введенный символ пересылается немедленно, при построчном режиме отклик на каждое нажатие клавиши производится локально, а пересылка выполняется лишь при нажатии клавиши <Enter>. Некоторые опции требуют дополнительных данных, такая информация ожет быть получена с помощью субопций (RFC-1091). При этом клиент посылает трехбайтовую последовательность IAC WILL 24, где 24 - код-идентификатор терминала. Получатель может откликнуться последовательностью IAC DO 24, если все в порядке. Сервер в свою очередь посылает последовательность IAC SB 24 1 IAC SE, запрашивая тип терминала клиента. Здесь код 24 означает, что это субопция для опции типа терминала (см. табл. 4.5.3.1), а следующая 1 является командой "пришлите код вашего терминала". Клиент в свою очередь может откликнуться, послав последовательность - IAC SB 24 0 I B M P C IAC SE. Здесь байт 0 имеет значение "мой терминал имеет тип". Список кодов терминалов содержится в RFC-1700.

Таблица 4.5.3.1. Коды опций в Telnet

Код опции в Telnet Описание Номер RFC 0 Двоичный обмен 856 1 Эхо 857 2 Повторное соединение NIC 15391 3 Подавление буферизации ввода 858 4 Диалог о размере сообщения NIC 15393 5 Статус 859 6 Временная метка 860 7 Удаленный доступ и отклик 726 8 Длина выходной строки nic 20196 9 Размер выходной страницы nic 20197 10 Режим вывода символов 652 11 Вывод горизонтальной табуляции 653 12 Установка положения табуляции при выводе 654 13 Режим вывода команды смены страницы 655 14

Вывод вертикальной табуляции 656 15 Определяет положение вертикальной табуляции 657 16 Режим вывода символа 658 17 Расширенный набор кодов ASCII 698 18 Возврат (logout) 727 19 Байт-макро 735 20 Терминал ввода данных 732 21 Supdup 736 22 Supdup вывод 747 23 Место отправления 779 24 Тип терминала 930 25 Конец записи 885 26 Tacacs- идентификация пользователя 927 27 Пометка вывода 933 28 Код положения терминала 946 29 Режим 3270 1041 30 X.3 PAD 1053 31 Размер окна 1073 Когда связь с удаленной ЭВМ уже осуществлена, переход в командный режим может быть выполнен с помощью нажатия '^]' (escape).

В этом режиме доступны команды:



open имя_ЭВМ [ порт ]

 open открывает связь с ЭВМ, имя которой указано в обращении. Если номер порта явно не указан, telnet пытается использовать для связи с сервером номер порта по умолчанию. Вместо имени ЭВМ-сервера может использоваться ее IP-адрес.


display [ аргумент ... ]

 Отображает все, или часть, набора параметров telnet (см. описание команды send).


close

 Закрывает сессию telnet и возвращает систему в командный режим.


quit

 Закрывает любую сессию telnet.


mode type

 Управляет режимом ввода ("построчный" или "посимвольный"). Удаленной машине посылается запрос на переход в соответствующий режим. Если она готова (способна) работать в запрошенном режиме, будет произведено соответствующее переключение.


status

 Отображает текущий статус telnet. В перечень информации входит имя удаленной ЭВМ и действующий режим обмена.


? [ команда ]

 Выдает справочную информацию о команде, название которой приведено в качестве аргумента


send arguments

 Посылает удаленной ЭВМ один или несколько символьных аргументов. В качестве аргументов могут использоваться: escape, synch, brk, ip, ao, ayt, ecel, ga и др. Смотри таблицу 4.5.3.3.


escape

 Посылает escape символ (например, `^]').


SYNCH

 Посылает synch-последовательность. Эта последовательность позволяет аннулировать все, что было до этого напечатано, но еще не считано. Эта последовательность посылается как срочная (важная) TCP-информация (может не сработать, если удаленной системой является 4.2 BSD). Если она не сработала, на терминал будет послан символ "r".


brk

 Посылает Break-последовательность при нажатии клавиши Break (Pause). (Исчерпывающую информацию об аргументах можно найти в описании используемого программного обеспечения или с помощью команд Help или Man)


set argument value

 Присваивает любому числу переменных telnet новые значения. Специальное значение "off" выключает функцию, соответствующую данной переменной
<


/p> Значения переменных можно узнать с помощью команды display. Такими переменными могут быть: echo, escape, interrupt, quit, flushoutput, erase, kill, eof, echo. Последняя переменная (в исходном состоянии `^E') в построчном режиме осуществляет переключение между локальным эхо на ввод символа (режим по умолчанию) и подавлением эхо, например при вводе пароля. Переменные процедуры telnet представлены в таблице 4.5.3.2.

Практически стандарт TELNET описан во многих RFC документах, которые определяют различные варианты реализации этой команды. Список опций команды telnet приведен в таблице 4.5.3.1 (не все эти возможности доступны в конкретных программных продуктах).

Таблица 4.5.3.2. Переменные telnet



Название переменной

Назначение


Echo

 Определяет, будет ли отображаться на экране то, что вы вводите с клавиатуры. При значении off ввод не отображается, например, при вводе пароля.


Escape

 Задает символ, который используется в качестве escape. Появление этого символа во входном потоке заставляет его и последующие символы интерпретироваться в ЭВМ, где функционирует процесс telnet, как команда


Interrupt

 Специфицирует символ прерывания процесса. Ввод его приводит к остановке процесса пользователя, работающего на удаленной ЭВМ.


Quit

 Специфицирует символ, который используется пользователем на его клавиатуре для выполнения команд brake или attention.


Flushoutput

 Определяет символ, который служит для прерывания процедуры вывода на удаленной ЭВМ.


EOF

 Специфицирует символ, который используется для обозначения конца файла на удаленной машине.
Таблица 4.5.3.3. Последовательности символов, используемые совместно с командой send



Последовательность символов

Назначение


?

 Отображает справочную информацию о команде send


escape

 Посылает символ escape (без прерывания посылки символов для Telnet)


ip

 Посылает протокольную последовательность telnet. Удаленная машина должна прервать процесс, запущенный для вас.


ec

 Посылает протокольную EC-последовательность telnet. Удаленная ЭВМ должна стереть последний напечатанный вами символ


el

 Посылает протокольную EL-последовательность TELNET. Удаленная ЭВМ должна стереть последнюю напечатанную вами строку.


ao

 Посылает протокольную AO-последовательность TELNET. Удаленная ЭВМ должна направить весь вывод на ваш терминал.


brk

 Посылает протокольную BRK-последовательность TELNET. Удаленная ЭВМ должна обеспечить отклик.


ayt

 Посылает протокольную AYT-последовательность TELNET (Are You There). Удаленная ЭВМ должна обеспечить отклик.
<


/p> В таблице 4.5.3.4 представлены наименования и коды команд Telnet, которые используются как клиентом, так и сервером в сочетании с префиксным байтом 0xff (IAC - "интерпретировать как команду"). Если нужно послать код данных, равный 255, посылается два байта с кодами 255.

Таблица 4.5.3.4. Коды команд TELNET

Имя субкоманды TELNET Код Описание
EOF 236 Признак конца файла
SUSP 237 Отложить исполнение текущего процесса
ABORT 238 Абортировать процесс
EOR 239 Конец записи
NOP 241 Никаких действий
DM(Метка данных) 242 Блок данных процедуры SYNCH
BRK (Остановка) 243 brk-символ (break);
IP(Прерывание процесса) 244 IP-функция
io (Прерывание вывода) 245 AO-функция
AYT (Вы здесь?) 246 ayt-функция
EC (Стереть символ) 247 EC-функция
EL (Стереть строку) 248 EL-функция
GA (Продолжайте) 249 GA-функция
SB 250 Начало субопции
SE 240 Завершение согласования параметров (конец субопции)
Will ("будет") 251 Начало исполнения (опционно)
Won't (не будет) 252 Отказ исполнения или продолжения выполнения (опционно)
Do("исполнить") 253 Индицирует запрос, который другая система исполняет (опционно)
Don't ("Нет") 254 Требует, чтобы другая система остановила исполнение (опционно)
IAC 255 Интерпретируется как начало командной последовательности
Операция прерывание процесса (IP) позволяет прервать, удалить или завершить процесс пользователя (например, выйти из бесконечного цикла).

Процедура прерывание вывода (AO) позволяет процессу пользователя продолжаться, но вывод на его рабочую станцию прерывается, при этом очищается буфер от уже записанной, но не отображенной информации.

Запрос "Вы здесь?" (AYT) удобен, когда необходимо выяснить выполняется ли пользовательская задача или нет.

Операция стереть символ (EC) позволяет пользователю удалить символ из потока данных, применяется для редактирования текста на экране.



Операция стереть строку (EL) позволяет пользователю при редактировании удалить целую строку.

Команда "go ahead" (GA, "продолжайте") устанавливает полудуплексный режим передачи данных. Каких-либо воздействий на удаленную ЭВМ обычно не производит. В таблице 4.5.3.5 приведен список комбинаций клавиш, нажатие которых вызывает определенный результат.

Таблица 4.5.3.5. Управляющие комбинации клавиш



Комбинация клавиш

Достигаемый результат


Ctrl+E

 Echo


Ctrl+]

 Escape


Ctrl+?

 Erase


Ctrl+O

 flushoutput


Ctrl+C

 Interrupt (прерывание исполнения программы)


Ctrl+U

 Kill


Ctrl+\

 Quit


Ctrl+D

 EOF
Блок данных процедуры TELNET содержит три байта и называется командой. Формат этого блока показан на рис. 4.5.3.1.



Рис. 4.5.3.1. Формат блока данных Telnet

Первый байт в соответствии с таблицей содержит 8 единиц, далее следует байт команды (табл. 4.5.3.4). Третий октет служит для размещения кода опции, он может и отсутствовать.

Рассмотрим несколько примеров этих команд. Допустим, вы хотите, чтобы обмен данными производился в виде 8-битовых посылок. Для реализации вашего пожелания достаточно выдать команду:

IAC WILL TRANSMIT-BINARY,

которая в цифровых кодах выглядит как - (255 251 0).

Для прекращения этого (двоичного) режима передачи нужно выдать команду:

IAC DON'T TRANSMIT-BINARY (255 254 0).

Субкоманды Telnet позволяют управлять откликом при работе с клавиатурой. Обычно отклик-эхо присылается удаленной ЭВМ, реже формируется локально. Для включения отклика можно выдать команду: IAC WILL ECHO (255 251 1) (часто это реализовано по умолчанию). Далее можете поупражняться самостоятельно и проверить какие команды и их опции доступны в используемом вами программном продукте.

При работе с Telnet рекомендуется сначала ознакомиться с конкретными возможностями команды с помощью описания (или F10/?). Это позволит вам, например, спасать результаты поиска в файле с указанным вами именем и т.д. Например, для PCTCP такая команда выдаст на экран:



Telnet with VT220 and 3270 emulation, escape character is alt-F10 or F10

Copyright (c) 1989-1992 by FTP Software, Inc. All rights reserved.

? display this help message a sends Telnet AYT request
^h debugging command help b send Telnet Interrupt Process
o write receive data to output file z send Telnet Abort output
i read keystrokes from an input file t send Telnet Break
c close connection gracefully ! escape to command interpret
q/Q quit current/all telnet connections I show local internet address
F toggle build-in FTP-server on/off U turn status line on
W toggle FTP server write-protect mode u turn status line off
0-9 switch to connection # s Enable pop-up TSR with hot-key
p Select code page remapping S Toggle screen-saver key-passing
-------------------------- VT220 emulator commands ------------------------------

R Enter key send CR l local echo mode
N Enter key send newline (CRLF) r remote echo mode
E send characters as typed w turn end-of-line wrap on
E send line when ENTER is typed d turn end-of-line wrap off
B set emulator mode (VT52|100|220)
D    
---------------------------- 3270 emulator commands ----------------------------

y set Yale Null Processing off Y set Yale Null Processing on
[Press SPACE to return to session, or enter another command (? for Help]

Многие telnet-клиенты позволяют также указывать явно номер порта, через который должна быть установлена связь. По умолчанию это порт 23. Обычный пользователь не интересуется, через какой порт он работает. Но иногда желательно реализовывать telnet через разные порты системы, обеспечивающие различные услуги, это бывает полезно и с отладочными целями. Используя команду:

telnet XXXXXX.domain

можно осуществить связь через порт с заданным номером с узлом XXXXXX.domain. Многие библиотеки используют метод портов для обеспечения доступа к своим ресурсам внешних Inernet-пользователей. Ссылки на RFC-документы по протоколу TELNET смотрите в приложении. Помимо telnet существуют и другие стандартные процедуры, выполняющие схожие задачи.

SUN Microsistems разработала и широко использует программный модуль RPC (Remote Procedure Call, RFC-1057), он используется для удаленного вызова программ почти во всех системах, базирующихся на UNIX. RPC может использоваться как на TCP, так и UDP транспортных уровнях.

Для удаленного исполнения программ может служить команда REXECD, которая активно используется на IBM-системах в рамках ОС AIX и DOS. Уязвимость протокола Telnet для хакеров привела к тому, что в последнее время эта утилита часто заменяется SSH

(Secure Shell) или другими программами, обеспечивающими безопасный удаленный доступ.


Управляющая база данных MIB


4.4.13.1 Управляющая база данных MIB

Семенов Ю.А. (ГНЦ ИТЭФ)

Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks).

MIB определяет, например, что IP программное обеспечение должно хранить число всех октетов, которые приняты любым из сетевых интерфейсов, управляющие программы могут только читать эту информацию.

Согласно нормативам MIB управляющая информация делится на восемь категорий (см. также рис. 4.4.13.1.1):

MIB-категория включает в себя информацию о

MIB-категория Описание Код system Операционная система ЭВМ или маршрутизатора. 1 Interfaces Сетевой интерфейс. 2 addr.trans Преобразование адреса (напр., с помощью arp). 3 IP Программная поддержка протоколов Интернет. 4 ICMP Программное обеспечение icmp-протокола. 5 TCP Программное обеспечение TCP-протокола. 6 UDP Программное обеспечение UDP-протокола. 7 EGP Программное обеспечение EGP-протокола. 8 SNMP Программное обеспечение SNMP-протокола. 11

Таблица 4.4.13.1.1. Системные переменные MIB

Системная переменная Описание Код
Sysdescr Текстовое описание объекта; 1
Sysobjectid Идентификатор производителя в рамках дерева 1.3.6.1.4.1 2
Sysuptime Время с момента последней загрузки системы (timeticks); 3
Syscontact Имя системного менеджера и способы связи с ним; 4
Sysname Полное имя домена; 5
Syslocation Физическое местоположение системы; 6
Sysservice Величина, которая характеризует услуги, предоставляемые узлом (сумма номеров уровней модели OSI); 7
<
/p> Таблица 4.4.13.1.2. Переменные IFtable (интерфейсы)

Переменная описания интерфейсов (iftable) Тип данных Описание ifEntry
IFindex integer Список интерфейсов от 1 до ifnumber. 1
IfDescr displaystring Текстовое описание интерфейса. 2
IfType integer Тип интерфейса, например, 6 - ethernet; 9 - 802.5 маркерное кольцо; 23 - PPP; 28 - SLIP.> 3
IfNumber integer Число сетевых интерфейсов.  
IfMTU integer mtu для конкретного интерфейса; 4
IfSpeed gauge Скорость в бит/с. 5
IfPhysaddress physaddress Физический адрес или строка нулевой длины для интерфейсов без физического адреса (напр. последовательный). 6
IfAdminStatus [1...3] Требуемое состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется. 7
IfOperStatus [1...3] Текущее состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется. 8
IfLastchange timeticks Sysuptime, когда интерфейс оказался в данном состоянии. 9
IfInOctets counter Полное число полученных байтов. 10
IfInUcastpkts counter Число пакетов, доставленных на верхний системный уровень (unicast). 11
IfInNUcastpkts counter Число пакетов, доставленных на верхний системный уровень (unicast). 12
IfInDiscads counter Число полученных но отвергнутых пакетов. 13
IfInErrors counter Число пакетов, полученных с ошибкой; 14
IfInUnknownProtos counter Число пакетов, полученных с ошибочным кодом протокола; 15
IfOutOctets counter Число отправленных байтов; 16
IfOutUcastPkts counter Число unicast- пакетов, полученных с верхнего системного уровня; 17
IfOutNucastPkts counter Число мультикастинг- и широковещательных пакетов, полученных с верхнего системного уровня; 18
IfOutDiscads counter Количество отвергнутых пакетов из числа отправленных; 19
IfOutErrors counter Число отправленных пакетов, содержащих ошибки; 20
IfOutQlen gauge Число пакетов в очереди на отправку; 21
Ниже представлена таблица цифро-точечного представления переменных, характеризующих состояние интерфейса. Эта таблица может быть полезной для программистов, занятых проблемами сетевой диагностики.

" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "
Название объекта Цифра-точечное представление
org 1.3
dod 1.3.6
internet 1.3.6.1
directory 1.3.6.1.1
mgmt 1.3.6.1.2
experimental 1.3.6.1.3
private 1.3.6.1.4
enterprises 1.3.6.1.4.1
security 1.3.6.1.5
snmpV2 1.3.6.1.6
snmpDomains 1.3.6.1.6.1
snmpProxys 1.3.6.1.6.2
snmpModules 1.3.6.1.6.3
snmpMIB 1.3.6.1.6.3.1
snmpMIBObjects 1.3.6.1.6.3.1.1
snmpTraps 1.3.6.1.6.3.1.1.5
mib-2 1.3.6.1.2.1
ifMIB 1.3.6.1.2.1.31
interfaces 1.3.6.1.2.1.2
ifMIBObjects 1.3.6.1.2.1.31.1
ifConformance 1.3.6.1.2.1.31.2
ifTableLastChange 1.3.6.1.2.1.31.1.5
ifXTable 1.3.6.1.2.1.31.1.1
ifStackTable 1.3.6.1.2.1.31.1.2
ifStackLastChange 1.3.6.1.2.1.31.1.6
ifRcvAddressTable 1.3.6.1.2.1.31.1.4
ifTestTable 1.3.6.1.2.1.31.1.3
ifXEntry 1.3.6.1.2.1.31.1.1.1
ifName 1.3.6.1.2.1.31.1.1.1.1
ifInMulticastPkts 1.3.6.1.2.1.31.1.1.1.2
ifInBroadcastPkts 1.3.6.1.2.1.31.1.1.1.3
ifOutMulticastPkts 1.3.6.1.2.1.31.1.1.1.4
ifOutBroadcastPkts 1.3.6.1.2.1.31.1.1.1.5
ifLinkUpDownTrapEnable 1.3.6.1.2.1.31.1.1.1.14
ifHighSpeed 1.3.6.1.2.1.31.1.1.1.15
ifPromiscuousMode 1.3.6.1.2.1.31.1.1.1.16
ifConnectorPresent 1.3.6.1.2.1.31.1.1.1.17
ifAlias 1.3.6.1.2.1.31.1.1.1.18
ifCounterDiscontinuityTime 1.3.6.1.2.1.31.1.1.1.19
ifStackEntry 1.3.6.1.2.1.31.1.2.1
ifStackHigherLayer 1.3.6.1.2.1.31.1.2.1.1
ifStackLowerLayer 1.3.6.1.2.1.31.1.2.1.2
ifStackStatus 1.3.6.1.2.1.31.1.2.1.3
ifRcvAddressEntry 1.3.6.1.2.1.31.1.4.1
ifRcvAddressAddress 1.3.6.1.2.1.31.1.4.1.1
ifRcvAddressStatus 1.3.6.1.2.1.31.1.4.1.2
ifRcvAddressType1.3.6.1.2.1.31.1.4.1.3
ifTestEntry1.3.6.1.2.1.31.1.3.1
ifTestId1.3.6.1.2.1.31.1.3.1.1
ifTestStatus1.3.6.1.2.1.31.1.3.1.2
ifTestType1.3.6.1.2.1.31.1.3.1.3
ifTestResult1.3.6.1.2.1.31.1.3.1.4
ifTestCode1.3.6.1.2.1.31.1.3.1.5
ifTestOwner1.3.6.1.2.1.31.1.3.1.6
ifGroups1.3.6.1.2.1.31.2.1
ifCompliances1.3.6.1.2.1.31.2.2
ifGeneralInformationGroup1.3.6.1.2.1.31.2.1.10
ifFixedLengthGroup1.3.6.1.2.1.31.2.1.2
ifHCFixedLengthGroup1.3.6.1.2.1.31.2.1.3
ifPacketGroup1.3.6.1.2.1.31.2.1.4
ifHCPacketGroup1.3.6.1.2.1.31.2.1.5
ifVHCPacketGroup1.3.6.1.2.1.31.2.1.6
ifRcvAddressGroup1.3.6.1.2.1.31.2.1.7
ifStackGroup21.3.6.1.2.1.31.2.1.11
ifCounterDiscontinuityGroup1.3.6.1.2.1.31.2.1.13
ifGeneralGroup 1.3.6.1.2.1.31.2.1.1
ifTestGroup 1.3.6.1.2.1.31.2.1.8
ifStackGroup 1.3.6.1.2.1.31.2.1.9
ifOldObjectsGroup 1.3.6.1.2.1.31.2.1.12
ifCompliance2 1.3.6.1.2.1.31.2.2.2
ifCompliance 1.3.6.1.2.1.31.2.2.1
ifNumber 1.3.6.1.2.1.2.1
ifTable 1.3.6.1.2.1.2.2
ifEntry 1.3.6.1.2.1.2.2.1
ifIndex 1.3.6.1.2.1.2.2.1.1
ifDescr 1.3.6.1.2.1.2.2.1.2
ifType 1.3.6.1.2.1.2.2.1.3
ifMtu 1.3.6.1.2.1.2.2.1.4
ifSpeed 1.3.6.1.2.1.2.2.1.5
ifPhysAddress 1.3.6.1.2.1.2.2.1.6
ifAdminStatus 1.3.6.1.2.1.2.2.1.7
ifOperStatus 1.3.6.1.2.1.2.2.1.8
ifLastChange 1.3.6.1.2.1.2.2.1.9
ifInOctets 1.3.6.1.2.1.2.2.1.10
ifInUcastPkts 1.3.6.1.2.1.2.2.1.11
ifInNUcastPkts 1.3.6.1.2.1.2.2.1.12
ifInDiscards 1.3.6.1.2.1.2.2.1.13
ifInErrors 1.3.6.1.2.1.2.2.1.14
ifInUnknownProtos 1.3.6.1.2.1.2.2.1.15
ifOutOctets 1.3.6.1.2.1.2.2.1.16
ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17
ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18
ifOutDiscards 1.3.6.1.2.1.2.2.1.19
ifOutErrors 1.3.6.1.2.1.2.2.1.20
ifOutQLen 1.3.6.1.2.1.2.2.1.21
ifSpecific 1.3.6.1.2.1.2.2.1.22
<


/p> Таблица 4.4.13.1.3. Переменные IP-группы

Переменная IP-группы Тип данных Описание Код
ipForwarding integer Указание на то, что данный объект осуществляет переадресацию (работает как маршрутизатор). 1
IPdefaultTTL integer Значение, которое использует IP в поле TTL. 2
IPinreceives counter Число полученных дейтограмм. 3
ipInHdrErrors counter Число дейтограмм, отвергнутых из-за ошибок формата или неверных адресов или опций, из-за истекшего TTL. 4
ipInHdrErrors counter Число дейтограмм, отвергнутых из-за неверного IP-адреса, например, 0.0.0.0, или неподдерживаемого класса, например Е. 5
ipForwDatagrams counter Число дейтограмм, для которых данный объект не является местом назначения (маршрутизация отправителя). 6
ipInUnknownProtos counter Число дейтограмм с неподдерживаемым кодом протокола. 7
ipInDiscards counter Число дейтограмм, отвергнутых из-за переполнения буфера. 8
ipInDelivers counter Полное число входных дейтограмм, успешно обработанных на IP-уровне. 9
ipOutRequests counter Полное число IP и ICMP дейтограмм, переданных для отправки. 10
ipOutRequests counter Полное число IP и ICMP дейтограмм, переданных для отправки. 11
IPoutNoroutes counter Число неудач при маршрутизации. 12
ipReasmTimeout counter Максимальное число секунд ожидания сборки фрагментов. 13
ipReasmReqds counter Число полученных фрагментов 14
ipReasmOKs counter Число полученных и успешно собранных IP-дейтограмм 15
ipReasmFails counter Число полученных IP-дейтограмм, которые по тем или иным причинам не удалось собрать 16
IPFragOKs counter Число успешно фрагментированных IP- дейтограмм. 17
ipFragFails counter Число IP- дейтограмм, которые нужно фрагментировать, но сделать это нельзя (например, из-за флага). 18
ipFragCreates counter Число IP-дейтограмм фрагментов, сформированных данным объектом. 19
ipAddrTable counter Таблица адресной информации данного объекта. 20
ipRouteTable Последовательность записей маршрутной таблицы Запись в маршрутной таблице 21
ipAddrEntry
IPAdEntAddr IPaddress IP-адрес для данного ряда 1
IPadentifindex integer Число интерфейсов. 2
IPadentnetmask IPaddress Маска субсети для данного IP-адреса; 3
IPAdEntBcastAddr [0...1] Значение младшего бита широковещательного адреса (обычно 1); 4
IPAdEntReasmMaxsize [0...65535] Размер наибольшей IP-дейтограммы, полученной интерфейсом, которая может быть собрана. 5
<


/p> Помимо простых переменных объектами MIB могут быть таблицы. Для каждой таблицы имеется один или несколько индексов.

Таблица 4.4.13.1.4. Переменные TCP-группы

Переменные TCP-группы Тип данных Описание Код
tcpRtoAlgorithm integer Алгоритм выявления таймаута для повторной передачи TCP-пакетов: 1 - ни один из следующих; 2 - постоянное RTO; 3 - стандарт MIL-std-1778; 4 - алгоритм Ван Джакобсона 1
tcpRtoMin integer Минимальное допустимое время повторной передачи tcp- пакетов. 2
tcpRtoMax integer Максимальное значение тайм-аута в миллисек. 3
tcpMaxConn integer Максимальное допустимое число tcp-соединений. 4
tcpActiveOpens integer Число TCP-соединений Active-Open 5
tcpPassiveOpens integer Число TCP-соединений Passive-Open (из состояния LISTEN) 6
tcpAttemptFails integer Число неудачных TCP-соединений 7
tcpEstabResets integer Число разрывов TCP-соединений из состояний ESTABLISHED или CLOSE-WAIT 8
tcpCurrEstab Gauge Число TCP-соединений, для которых текущее состояние ESTABLISHED или CLOSE-WAIT 9
tcpInSegs counter Полное число полученных tcp-сегментов. 10
tcpOutSegs counter Полное число посланных сегментов, исключая повторно пересылаемые. 11
tcpRetransSegs counter Полное число повторно пересланных сегментов. 12
tcpConnTable counter Таблица данных специфичных для соединения 13
tcpInErrs counter Полное число сегментов, полученных с ошибкой. 14
tcpOutRsts counter Полное число посланных сегментов с флагом rst=1. 15
tcpconntable. tcp-таблица связей
tcpconnstate [1...12] Состояние соединения: 1 - closed; 2 - listen; 3 - syn_sent; 4 - syn_rcvd; 5 - established, 6 - fin_wait_1; 7 - fin_wait_2; 8 - close_wait; 9 - last_ack; 10 - closing; 11 - time_wait;, 12 - delete TCB. Только последняя переменная может устанавливаться менеджером, немедленно прерывая связь.
tcpconnlocal

address		 ipaddress Местный IP-адрес. 0.0.0.0 означает, что приемник готов установить связь через любой из интерфейсов.
tcpconnlocal

port		 [0...65535] Местный номер порта.
tcpconnlocal

address		 ipaddress Удаленный ip-адрес.
tcpconnrem

port		 [0...65535] Удаленный номер порта.
<


/p> Таблица 4.4.13.1.5. Переменные ICMP-группы (тип данных – counter)

Переменная icmp-группы Описание Код
icmpInMsgs Полное число полученных ICMP-сообщений. 1
icmpInErrors Число ICMP-сообщений, полученных с ошибками. 2
icmpInDestUnreach Число ICMP-сообщений о недостижимости адресата. 3
icmpintimeexcds Число ICMP-сообщений об истечении времени. 4
icmpInParmProbs Число полученных ICMP-сообщений о проблемах с параметрами. 5
icmpInSrcQuench Число ICMP-сообщений с требованием сократить или прервать посылку пакетов из-за перегрузки. 6
icmpInRedirects Число ICMP-сообщений о переадресации. 7
icmpInEchos Число полученных ICMP-запросов отклика. 8
icmpInEchoReps Число полученных ICMP-эхо- откликов. 9
icmpInTimestamps Число ICMP-запросов временных меток. 10
icmpInTimestampReps Число ICMP-откликов временных меток. 11
icmpInAddrMasks Число ICMP-запросов адресных масок. 12
icmpInAddrMaskReps Число ICMP-откликов на запросы адресных масок. 13
icmpOutMsgs Число отправленных ICMP- сообщений. 14
icmpOutErrors Число не отправленных ICMP- сообщений из-за проблем в ICMP (напр. нехватка буферов). 15
icmpOutDestUnreachs Число ICMP-сообщений о недоступности адресата. 16
icmpOutTimesExcds Число посланных ICMP-сообщений об истечении времени. 17
icmpOutParmProbs Число посланных ICMP-сообщений о проблемах с параметрами. 18
icmpOutSrcQuench Число посланных ICMP-сообщений об уменьшении потока пакетов. 19
icmpOutRedirects Число посланных ICMP-сообщений о переадресации. 20
icmpOutEchos Число посланных ICMP-эхо-запросов. 21
icmpOutEchoReps Число посланных ICMP-эхо-откликов. 22
icmpOutTimestamps Число посланных ICMP-запросов временных меток. 23
icmpOutTimestampReps Число посланных ICMP-откликов на запросы временных меток. 24
icmpOutAddrMasks Число посланных ICMP-запросов адресных масок. 25
Таблица 4.4.13.1.6. Переменные AT-группы (attable, преобразование адресов).



Переменные at-группы Тип данных Описание atEntry
atIfIndex integer Число интерфейсов. 1
atPhysAddress physaddress Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует. 2
atNetAddress networkaddress IP-адрес. 3
Каждый протокол (например IP) имеет свою таблицу преобразования адресов. Для IP это ipnettomediatable. Способ пропечатать эту таблицу с помощью программы SNMPI описан ниже.

MIB II содержит управляемые объекты, принадлежащие к группе snmp. SNMP-группа предоставляет информацию о SNMP-объектах, информационных потоках, о статистике ошибок:

Название объекта Описание Код
snmpInPkts Число пакетов, полученных от слоя, расположенного ниже SNMP. 1
snmpOutPkts Число пакетов доставленных от SNMP к нижележащему слою. 2
snmpInBadVersions Индицирует число PDU, полученных с ошибкой в поле версия. 3
snmpInBadCommunityNames Индицирует число PDU, полученных с нечитаемым или нелегальным именем community. 4
snmpInBadCommunityUses Полное число SNMP-пакетов, полученных с нечитаемым или нелегальным значение операции для данного имени community. 5
snmpInAsnParsErrs Указывает полное число ошибок ASN.1 или BER, которые не могут быть обработаны во входных SNMP-сообщениях 6
snmpInTooBigs Указывает число полученных PDU со слишком большим значением поля статус ошибки. 8
snmpInNoSuchNames Указывает число PDU, полученных с индикацией ошибки в поле nosuchname. 9
snmpInBadValues Указывает число PDU, полученных с индикацией ошибки в поле badvalue. 10
snmpInReadOnlys Указывает число PDU, полученных с индикацией ошибки в поле readonly. 11
snmpNnGenErrs Указывает число PDU, полученных с generr-полем. 12
snmpInTotalReqVar Указывает число объектов MIB, которые были восстановлены. 13
snmpInTotalSetVars Указывает число объектов MIB, которые были изменены. 14
snmpInGetRequests Указывает число соответствующих pdu, которые были получены. 15
snmpInGetNexts Указывает полное число pdu с запросами GetNext 16
snmpInSetRequests Указывает полное число pdu, полученных с запросами SET 17
snmpInGetResponses Указывает полное число pdu, полученных c откликами на запросы 18
snmpInTraps Указывает полное число, полученных и успешно обработанныз TRAP 19
snmpOutTooBig Указывает число посланных PDU с полем toobig. 20
snmpOutNoSuchNames Указывает число посланных PDU с полем nosuchname. 21
snmpOutBadValues Указывает число посланных PDU с полем badvalue. 22
snmpOutGenErrs Указывает число посланных PDU с полем genErrs. 24
snmpOutGetRequests Указывает число посланных PDU Get-Request 25
snmpOutGetNexts Указывает число посланных PDU Get-NEXT 26
snmpOutSetRequests Указывает число посланных PDU SET 27
snmpOutGetResponses Указывает число посланных PDU откликов 28
snmpOutTraps Указывает число посланных PDU TRAPs 29
snmpEnableAuthTraps Говорит о том, разрешены или нет ловушки (TRAPS). 30
<


/p> Стандарт на структуру управляющей информации (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ASN.1 (abstract syntax notation 1, формализованный синтаксис). ASN.1 является формальным языком, который обладает двумя основными чертами:

используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. В SMI не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: integer, octet string, object identifier и null. Практически в протоколе SNMP фигурируют следующие виды данных:



integer

. Некоторые переменные объявляются целыми (integer) с указанием начального значения или с заданным допустимым диапазоном значений (в качестве примера можно привести номера UDP- или TCP-портов).



octet string

(последовательность байтов). В соответствии с требованиями BER (basic encoding rules, ASN.1) последовательность октетов должна начинаться с числа байт в этой последовательности (от 0 до n).



object identifier

(идентификатор объекта). Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5.



null.

Указывает, что соответствующая переменная не имеет значения.



displaystring

. Строка из 0 или более байт (но не более 255), которые представляют собой ASCII-символы. Представляет собой частный случай octet string.

physaddress

. Последовательность октетов, характеризующая физический адрес объекта (6 байт для Ethernet). Частный случай object identifier.



Сетевой адрес

. Допускается выбор семейства сетевых протоколов. В рамках ASN.1 этот тип описан как choice, он позволяет выбрать протокол из семейства протоколов. В настоящее время идентифицировано только семейство протоколов Интернет.



IP-адрес

. Этот адрес используется для определения 32-разрядного Интернет-адреса. В нотации ASN.1 - это octet string.



time ticks

(такты часов). Положительное целое число, которое используется для записи, например, времени последнего изменения параметров управляемого объекта, или времени последней актуализации базы данных. Время измеряется в сотых долях секунды.





gauge

(масштаб). Положительное целое число в диапазоне 0 - (232-1), которое может увеличиваться или уменьшаться. Если эта переменная достигнет величины 232-1, она будет оставаться неизменной до тех пор пока не будет обнулена командой сброс. Примером такой переменной может служить tcpcurresta, которая характеризует число TCP соединений, находящихся в состоянии established или close_wait.



counter

(счетчик). Положительное целое число в диапазоне 0 - (232-1), которое может только увеличиваться, допуская переполнение.



sequence

. Этот объект аналогичен структуре в языке Си.

Например, MIB определяет sequence с именем udpentry, содержащую информацию об активных UDP-узлах. В этой структуре содержится две записи:

1. UDPlocaladdress типа ipaddress, содержит местные IP-адреса.

2. UDPlocalport типа integer, содержит номера местных портов.



SEQUENCE OF

. Описание вектора, все элементы которого имеют один и тот же тип. Элементы могут представлять собой простые объекты, например, типа целое. В этом случае мы имеем одномерный список. Но элементами вектора могут быть объекты типа SEQUENCE, тогда этот вектор описывает двумерный массив.

В Интернет MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.

Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT. Структура имен носит иерархический характер, отображенный на рис. 4.4.13.1.1.



Рис. 4.4.13.1.1 Структура идентификаторов переменных в MIB

В приведенной ниже таблице охарактеризованы четыре простые переменные, идентификаторы которых помещены в нижней части рис. 4.4.13.1.1. Все эти переменные допускают только чтение.

Имя переменной Тип данных Описание Код
udpInDatagrams counter Число UDP-дейтограмм, присланных процессам пользователя. 1
udpNoPorts counter Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения. 2
udpInErrors counter Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы). 3
udpOutDatagrams counter Число посланных UDP-дейтограмм. 4
udpTable counter Таблица, содержащая данные о принимающей стороне 5
<


/p> Ниже приведено описание таблицы (udptable; index = ,), состоящей из двух простых переменных (read-only).

Имя переменной Тип данных Описание
udplocaladdress ipaddress Местный IP-адрес для данного приемника;
udplocalport (0 - 65535) Местный номер порта приемника.
Согласно этой иерархии переменные, соответствующие ICMP, должны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символьном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хотите узнать значение какой-то переменной, следует послать запрос, содержащий соответствующий префикс и суффикс, последний определяет имя конкретной переменной. Для простой переменной суффикс имеет вид .0. Ветвь структуры на рис. 4.4.13.1.1, завершающейся узлом Interfaces (2) имеет продолжение в виде ifTable(2) и ifEntry(1). Таким образом переменная ifInUcastPkts будет иметь представление 1.3.6.1.2.1.2.2.1.11.

Помимо стандартного набора переменных и таблиц MIB возможно использование индивидуальных расширений этой базы данных. Это можно продемонстрировать на примере MIB маршрутизаторов Cisco (рис. 4.4.13.1.2).



Рис. 4.4.13.1.2. Расширение базы данных mib маршрутизаторов Cisco

Префикс 1.3.6.1.4.1. является стандартным, далее следует расширение, индивидуальное для маршрутизаторов компании Cisco. Например, группа IPcheckpoint accounting позволяет контролировать поток байтов с определенных адресов локальной сети, что бывает важно при работе с коммерческими провайдерами услуг.

Коды-префиксы для различных производителей телекоммуникационного оборудования приведены в таблице 4.4.13.1.7.

Таблица 4.4.13.1.7 Коды-префиксы производителей



Код префикса

Название фирмы
0 Зарезервировано
1 Proteon
2 IBM
3 CMU
4 UNIX
5 ACC
6 TWG
7 Cayman
8 PSI
9 Cisco
10 NSC
11 HP
12 Epilogue
13 U of Tennessee
14 BBN
15 Xylogics, inc.
16 Unisys
17 Canstar
18 Wellfleet
19 TRW
20 MIT
Группа локальных переменных IP checkpoint accounting (1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в каждом рекорде по четыре переменных (в скобках указан суффикс адреса MIBдля переменной):



ckactbyts [4] - число переданных байт,

ckactdst [2] - адрес места назначения,

ckactpkts [3] - число переданных пакетов

ckactsrc [1] - адрес отправителя

Маршрутизаторы Cisco поддерживают две базы данных: active accounting и checkpoint accounting. В первую заносятся текущие результаты измерения входящего и исходящего трафика. Эти результаты копируются в базу данных checkpoint accounting и, если там уже имеются предыдущие данные, они объединяются. Для очистки базы данных checkpointed database выдается команда clear IP accounting, а для базы checkpoint – clear IP accounting checkpoint (для использования этих команд необходимы системные привилегии). Объем памяти, выделяемой для этих баз данных задается командой IP accounting-threshold , по умолчанию максимальное число записей в базе данных равно 512.

Лучшим способом закрепить в памяти все вышесказанное является использование программы SNMPI (SNMP initiator) или ее аналога. Если в вашем распоряжении имеется ЭВМ, работающая под unix, например SUN, вы можете попутно узнать много полезного о вашей локальной сети. Ниже описан синтаксис обращения к SNMPI.

snmpi [-a agent] [-c community] [-f file] [-p portno] [-d] [-v] [-w]

SNMPI - крайне простая программа, используемая для тестирования SNMPD. Для того чтобы проверить, работает ли она, выдайте команду:

% SNMPI dump

Следует отметить, что в ответ на эту операцию будет произведена весьма объемная выдача.

Опция -a предлагает возможность ввести адрес SNMP-объекта - имя ЭВМ, IP-адрес или транспортный адрес. По умолчанию это местная ЭВМ. Аналогично опция -p позволяет задать номер UDP-порта. По умолчанию это порт 161.

Опция -c позволяет задать групповой пароль (community) для snmp-запроса. По умолчанию - это public, т.е. свободный доступ.

Опция -f позволяет выбрать файл, содержащий откомпилированные описания mib-модулей. По умолчанию - это objects.defs.

Опция -w включает режим наблюдения, осуществляя выдачу на терминал всех служебных сообщений. Уход из программы по команде quit (q).



Если вы работаете на IBM/PC, и ваша машина подключена к локальной сети, получите допуск к одной из UNIX-машин в сети (если вы его не имели) и приступайте. Можно начать с обращения типа:

SNMPI -a 193.124.224.33

(адрес или символьное имя надо взять из вашей локальной сети)

Машина откликнется, отобразив на экране SNMPI>, это означает, что программа имеется и вы можете вводить любые команды.

Начать можно со знакомства с системными переменными системы (в дальнейшем курсивом выделены команды, введенные с клавиатуры):

SNMPI> get sysdescr.0

snmpi> sysdescr.0="GS software (gs3-k), version 9.1(4) [fc1], software copyright (c) 1986-1993 by cisco systems, inc. compiled thu 25-mar-93 09:49 by daveu"

snmpi> get sysobjectid.0

snmpi> sysobjectid.0=1.3.6.1.4.1.9.1.1

snmpi> get sysuptime.0

snmpi> sysuptime.0=14 days, 7 hours, 0 minutes, 15.27 seconds (123481527 timeticks)

snmpi> get sysservices.0

snmpi> sysservices.0=0x6

Код 0x06 (sysservices.0) представляет собой сумму кодов уровней модели iso, поддерживаемых системой. Для справок: 0x01 - физический уровень; 0x02 – связной уровень; 0x04 - Интернет; 0x08 - связь точка-точка; 0x40 - прикладной уровень.

Если вы хотите получить информацию о состоянии интерфейсов на одной из ЭВМ, подключенных к вашей локальной сети (команды вызова snmpi далее не повторяются; в ниже приведенных примерах в круглых скобках помещены комментарии автора), выдайте команды:

SNMPI> next iftabl (команда next в данном случае соответствует запросу get-next, здесь понятие "следующий" подразумевает порядок переменных в MIB)

snmpi> ifindex.1=1

snmpi> get ifdescr.1

snmpi> ifdescr.1="ethernet0"

snmpi> get iftype.1

snmpi> iftype.1=ethernet-csmacd(6)

snmpi> get ifmtu.1

snmpi> ifmtu.1=1500

snmpi> get ifspeed.1

snmpi> ifspeed.1=10000000 (10Мб/с ethernet)

snmpi> get ifphysaddress.1

snmpi> ifphysaddress.1=0x00:00:0c:02:3a:49 (физический адрес интерфейса)

snmpi> next ifdescr.1 iftype.1 ifmtu.1 ifspeed.1 ifphysaddress.1



snmpi> ifdescr.2="serial0"

iftype.2=proppointtopointserial(22)

ifmtu.2=1500

ifspeed.2=2048000 (2 Мбит/ c радиорелейный последовательный канал, спутниковый канал был бы охарактеризован точно также).

ifphysaddress.2=

В приведенном примере размеры пересылаемых блоков для Ethernet и радиорелейного последовательного канала идентичны и равны 1500. Помните, что SLIP-канал характеризуется как pointtopointserial, а не slip. Скорость обмена по SLIP-каналу не сообщается.

Теперь просмотрим некоторые UDP-переменные. Например:

SNMPI> next UDP

SNMPI> udpindatagrams.0=98931

SNMPI> next udpindatagrams.0 (обратите внимание на суффикс простой переменной)

SNMPI> udpnoports.0=60009

SNMPI> next udplocaladdress.0

SNMPI>udplocaladdress.193.124.137.14.7=193.124.137.14

(Идентификатор этого объекта - 1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.)

SNMPI> next udplocalport

SNMPI> udplocalport.193.124.137.14.7=7

Если у вас возникла необходимость просмотреть таблицу, например, udptable, это

также можно сделать, используя snmpi:

SNMPI> next udptable

SNMPI> udplocaladdress.193.124.137.14.7=193.124.137.14

SNMPI> next udplocaladdress.193.124.137.14.7

SNMPI> udplocaladdress.193.124.224.33.67=193.124.224.33

SNMPI> next udplocaladdress.193.124.224.33.67

SNMPI> udplocaladdress.193.124.224.33.161=193.124.224.33

SNMPI> next udplocalport.193.124.224.33.67

SNMPI> udplocalport.193.124.224.33.161=161

Ниже показана методика выяснения алгоритма и параметров задания величины тайм-аута:

SNMPI> get tcprtoalgorithm.0 tcprtomin.0 tcprtomax.0 tcpmaxconn.0

SNMPI> tcprtoalgorithm.0=vanj(4) (vanj - алгоритм Ван Джакобсона для расчета времени тайм-аута)

tcprtomin.0=300 (минимальное значение тайм-аута = 300 мс)
tcprtomax.0=60000 (максимальное - 60 сек)
tcpmaxconn.0=-1 (никаких ограничений на число соединений)
Чтобы получить информацию о состоянии таблицы адресных преобразований, выдайте команду: SNMPI –a 193.124.224.33 dump at (процедуры с использование субкоманды dump требуют определенного времени для своего исполнения)

atifindex.1.1.193.124.224.33= 1
atifindex.1.1.193.124.224.35= 1
atifindex.3.1.192.148.166.203= 3
atifindex.3.1.192.148.166.205= 3
atifindex.5.1.145.249.30.33= 5
atifindex.5.1.192.148.166.98= 5
atphysaddress.1.1.193.124.224.33= 0x00:00:0c:02:3a:49
atphysaddress.1.1.193.124.224.35= 0x08:00:20:12:1b:b1
atphysaddress.1.1.193.124.224.40= 0x00:00:cd:f9:0d:e7
atphysaddress.1.1.193.124.224.50= 0x00:00:0c:02:fb:c5
atnetaddress.1.1.193.124.224.33= 193.124.224.33
atnetaddress.1.1.193.124.224.35= 193.124.224.35
atnetaddress.1.1.193.124.224.40= 193.124.224.40
atnetaddress.1.1.193.124.224.50= 193.124.224.50
atnetaddress.1.1.193.124.224.60= 193.124.224.60
<


/p> Текст выдачи с целью экономии места сокращен.

Обычно элементы таблицы расположены в порядке колонка-ряд. Если вы дошли до края колонки или всей таблицы ЭВМ выдаст вам, в зависимости от реализации программы, имя и значение следующего элемента или сообщение об ошибке.

Чтобы получить полный текст адресной таблицы в рамках SNMPI достаточно выдать команду:

SNMPI> dump ipaddrtable

snmpi> ipadentaddr.192.148.166.222= 192.148.166.222
ipadentaddr.192.168.1.1= 192.168.1.1
ipadentaddr.192.168.1.2= 192.168.1.2
ipadentaddr.193.124.224.33= 193.124.224.33
ipadentaddr.193.124.224.190= 193.124.224.190
ipadentifindex.192.148.166.222= 3
ipadentifindex.192.168.1.1= 4
ipadentifindex.192.168.1.2= 6
ipadentifindex.193.124.224.33= 1
ipadentifindex.193.124.224.190= 5
(Маски субсетей)

ipadentnetmask.192.148.166.222= 255.255.255.224
ipadentnetmask.192.168.1.1= 255.255.255.0
ipadentnetmask.192.168.1.2= 255.255.255.0
ipadentnetmask.193.124.224.33= 255.255.255.224
ipadentnetmask.193.124.224.190= 255.255.255.224
ipadentbcastaddr.192.148.166.222= 1 (Все эти субсети используют для широковещательной адресации одни и те же биты).

ipadentbcastaddr.192.168.1.1= 1
ipadentbcastaddr.192.168.1.2= 1
ipadentbcastaddr.193.124.224.33= 1
ipadentbcastaddr.193.124.224.190= 1
ipadentreasmmaxsize.192.148.166.222= 18024 (С точки зрения фрагментации и последующей сборки дейтограмм данные субсети эквивалентны).

ipadentreasmmaxsize.192.168.1.1= 18024
ipadentreasmmaxsize.192.168.1.2= 18024
ipadentreasmmaxsize.193.124.224.33= 18024
ipadentreasmmaxsize.193.124.224.190= 18024
Данная пропечатка совместно с приведенной для IFtable позволяет получить достаточно полную картину о данной конкретной локальной сети. Чтобы познакомиться с ARP таблицей, можно воспользоваться командой:

sun> arp -a

itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49

nb.itep.ru (193.124.224.60) at 0:80:ad:2:24:b7

и дополнить полученные данные с помощью SNMPI:



SNMPI> dump ipnettomediatable

SNMPI> ipnettomediaifindex.1.193.124.224.33= 1

ipnettomediaifindex.1.193.124.224.35= 1

ipnettomediaifindex.3.192.148.166.193= 3

ipnettomediaifindex.3.192.148.166.196= 3

ipnettomediaifindex.3.193.124.226.110= 3

ipnettomediaifindex.5.145.249.30.33= 5

ipnettomediaifindex.5.192.148.166.100= 5

ipnettomediaphysaddress.1.193.124.224.33= 0x00:00:0c:02:3a:49

ipnettomediaphysaddress.3.192.148.166.196= 0xaa:00:04:00:0c:04

ipnettomediaphysaddress.3.192.148.166.198= 0xaa:00:04:00:0e:04

ipnettomediaphysaddress.3.192.148.166.203= 0x00:00:01:00:54:62

.........................................

ipnettomediaphysaddress.5.145.249.30.33= 0x00:00:0c:02:69:7d

ipnettomediaphysaddress.5.192.148.166.100= 0x00:20:af:15:c1:61

ipnettomediaphysaddress.5.192.148.166.101= 0x08:00:09:42:0d:e8

ipnettomedianetaddress.1.193.124.224.33= 193.124.224.33

ipnettomedianetaddress.1.193.124.224.35= 193.124.224.35

ipnettomedianetaddress.3.192.148.166.193= 192.148.166.193

ipnettomedianetaddress.3.193.124.226.110= 193.124.226.110

ipnettomedianetaddress.5.145.249.30.33= 145.249.30.33

ipnettomediatype.1.193.124.224.33= other(1)

ipnettomediatype.1.193.124.224.35= dynamic(3)

ipnettomediatype.1.193.124.224.37= dynamic(3)

ipnettomediatype.3.192.148.166.195= dynamic(3)

ipnettomediatype.3.192.148.166.222= other(1)

ipnettomediatype.5.193.124.224.190= other(1)

ipnettomediatype.5.193.124.225.33= other(1)

ipnettomediatype.5.193.124.225.35= dynamic(3)

Синтаксис каждого объекта описывается в рамках ASN.1 и показывает побитовое представление объекта. Кодирование объекта характеризует то, как тип объекта отображается через его синтаксис и передается по телекоммуникационным каналам. Кодирование производится в соответствии с базовыми правилами кодирования asn.1. Все описания объектов базируются на типовых шаблонах и кодах asn.1 (см. RFC-1213). Формат шаблона показан ниже:

object (Объект):

Имя типа объекта с соответствующим ему идентификатором объекта (object identifier)



syntax (Синтаксис):

asn.1 описание синтаксиса типа объекта.

definition (Определение):

Текстовое описание типа объекта.

access (доступ):

Опции доступа.

status (состояние):

Статус типа объекта.

Маршруты также являются объектами mib. Согласно требованиям к mib, каждому маршруту в этой базе соответствует запись, схема которой приведена ниже на рис. 4.4.13.1.3:



Рис. 4.4.13.1.3 Формат записи маршрутной таблицы в MIB

Поле место назначения представляет собой IP-адрес конечной точки маршрута. Поле индекс интерфейса определяет локальный интерфейс (физический порт), через который можно осуществить следующий шаг по маршруту. Следующие пять полей (метрика 1-5) характеризуют оценку маршрута. В простейшем случае, например для протокола RIP, достаточно было бы одного поля. Но для протокола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг представляет собой IP-адрес следующего маршрутизатора. Поле тип маршрута имеет значение 4 для опосредованного достижения места назначения; 3 - для прямого достижения цели маршрута; 2 - для нереализуемого маршрута и 1 – для случаев отличных от вышеперечисленных.

Поле протокол маршрутизации содержит код протокола. Для RIP этот код равен 8, для OSPF - 13, для BGP - 14, для IGMP - 4, для прочих протоколов - 1. Поле возраст маршрута описывает время в секундах, прошедшее с момента последней коррекции маршрута. Следующее поле - маска маршрута используется для выполнения логической побитовой операции И над адресом в IP-дейтограммы перед сравнением результата с кодом, хранящимся в первом поле записи (место назначения). Последнее поле маршрутная информация содержит код, зависящий от протокола маршрутизации и обеспечивающий ссылки на соответствующую информацию в базе MIB.

Новым расширением MIB является система удаленного мониторинга сетей (RMON; RFC-1513, -1271). RMON служит для мониторирования сети в целом, а не отдельных сетевых устройств. В RMON предусмотрено 9 объектных групп (см. табл. 4.4.13.1.8).

Таблица 4.4.13.1.8. Функциональные группы RMON





Группа

Назначение
statistics Таблица, которая отслеживает около 20 статистических параметров сетевого трафика, включая общее число кадров и количество ошибок
history Позволяет задать частоту и интервалы для измерений трафика
alarm Позволяет установить порог и критерии, при которых агенты выдают сигнал тревоги
host Таблица, содержащая все узлы сети, данные по которым приводятся в сетевой статистике
hostTopN Позволяет создать упорядоченные списки, которые базируются на пиковых значениях трафика группы ЭВМ
matrix Две таблицы статистики трафика между парами узлов. Одна таблица базируется на адресах узлов-отправителей, другая – на адресах узлов-получателей
filter Позволяет определить конкретные характеристики кадров в канале. Например, можно выделить TCP-трафик.
packet capture Работает совместно с группой filter. Позволяет специфицировать объем ресурса памяти, выделяемой для запоминания кадров, которые отвечают критериям filter.
event Позволяет специфицировать набор параметров или условий, которые должен контролировать агент. Когда условия выполняются, информация о событии записывается в специальный журнал
Для того чтобы реализовать функционирование RMON-агента, сетевая карта должна быть способна работать в режиме 6 (promiscuous mode), когда воспринимаются все пакеты, следующие по кабельному сетевому сегменту.


Управляющие регистры модемов и их функции


10.8 Управляющие регистры модемов и их функции

Семенов Ю.А. (ГНЦ ИТЭФ)

Таблица 10.8.1

. Управляющие регистры модема

Регистр

Содержимое по умолчанию

Назначение

S0 0 1) Управляет режимом отклика модема на телефонный вызов. Устанавливает число звонков, после которых модем снимает трубку. Диапазон допустимых значений 0-255. Если S0=0, режим автоответа выключен. Для снятия трубки надо выполнить команду ATA. S1 0 Считает поступающие звонки и запоминает их число. Пользователь может прочесть регистр, но не должен менять содержимое. После 8 секунд с момента последнего звонка содержимое регистра сбрасывается в ноль. S2 43 Хранит ASCII значение символа ESC, используемого для управления переходом в командный режим и обратно в режим данных. По умолчанию это символ “+”. Значение 128-255 блокирует ESC-код. Содержимое регистра не сохраняется. S3 13 Хранит ASCII символ Carriage Return. Содержимое регистра не сохраняется. S4 10 Хранит ASCII символ Line Feed. Содержимое регистра не сохраняется. S5 8 Хранит ASCII символ Backspace. Содержимое регистра не сохраняется. Значение 128-255 блокирует функцию стирания символа Backspace. S6 3 Устанавливает число секунд, в течение которых модем ждет набора номера, если выбраны X0 или X1. Если выбраны X2, X3, X4, X5, X6 или X7, модем начинает набор, как только обнаружит гудок. Этот регистр устанавливает также величину таймаута для W-модификатора набора (диапазон 1-255 сек). Содержимое регистра не сохраняется. S7 60 Устанавливает число секунд, в течение которых модем ждет несущую после завершения набора номера. Если модем в течение этого времени не обнаружит несущую, он вешает трубку и переходит в режим NO CARRIER. Содержимое регистра не сохраняется. S8 2 Устанавливает длительность задержки, генерируемой модификатором набора запятая (,) команды ATD. Содержимое регистра не сохраняется. S9 6 Устанавливает время (в десятых секунды), в течение которого должна присутствовать несущая удаленного модема, прежде чем она будет опознана и модем передаст в ЭВМ сигнал DCD. Содержимое регистра не сохраняется. S10 7 Устанавливает время (в десятых секунды), в течение которого модем ждет после потери несущей прежде чем повесить трубку (разорвать связь). Код S10 должен быть всегда больше кода S9. Содержимое регистра не сохраняется. S11 70 Устанавливает длительность сигнала и паузы (в миллисекундах) при тоновом наборе S12   Определяет задержку, которую следует выждать до и после передачи модему ESC-последовательности (+++). Пауза между символами ESC-последовательности должна быть меньше кода в S12. S13   Зарезервировано S14 2)   Битовый регистр, определяющий состояние модема &Mn (7,6) =0 асинхронный, буферизованный =1 асинхронные команды, синхронные данные =2 прямой асинхронный без буфера =3 синхронный &Xn (5,4) =0 внутренние часы =1 внешние часы =2 удаленные часы &Ln (3,2) =0 линия с набором номера =1 2-проводная выделенная линия =2 4-проводная выделенная линия &T4 (1) =0 предоставление возможности запросов цифрового тестирования с удаленной замкнутой петлей &T5 =1 запрещает запросы тестов с удаленной петлей * 3) Mn (0) =0 Автоматический диалог в исходном режиме при работе на выделенную линию =1 Автоматический диалог в режиме отклика при работе на выделенную линию S15   Битовый регистр Zn (7,6,5)=0-4 Профайл используется для установки режима при включении питания *Сn (4,3) =0 10-битовая длина кодов символов =1 11-битовая длина кодов символов =2 9-битовая длина кодов символов =3 8-битовая длина кодов символов 4) (2)=0 1 стоп-бит =1 2 стоп-бита (1,0)=0 четная четность =1 нечетная четность =2 четность не используется. S16   Тест-статусный регистр =0 Не идет никаких тестов (по умолчанию); =1 Идет тест с аналоговой петлей =2 Зарезервировано =3 Работает локальный цифровой тест =6 Работает цифровой тест с удаленной петлей =7 Выполняется цифровое самотестирование с удаленной петлей

=8 Выполняется аналоговое самотестирование S17   Битовый регистр *In (6) =0 AT-набор команд =1 V.25bis-набор команд *Pn (4,3,2,1)=0-15 Уровень сигналов для выделенной линии *Sn (0) =0 Запрет вторичного канала =1 Разрешение вторичного канала. S18   Задает длительность теста в секундах. Если код S18=0, модем будет находиться в режиме теста до прихода команды &T0. S19 Режим соединения модема &Nn =0 Multi-auto, автоматический выбор наибольшей возможной скорости (V.32 9600T/9600/7200T/ 4800, V.22bis 2400/1200, V.22 1200, BELL 212A 1200, V17FAX 14400/12000/9600/7200, V.29FAX 9600/7200, V.27terFAX 4800/2400) =1 V.33 14400/12000 =2 V.33 12000 =3 V.32 9600T/9600/7200T/4800 =4 V.32 9600/7200T/4800 =5 V.32 4800 =6 V.29 9600 =7 V.29 7200 =8 V.29 4800 =9 V.27ter 4800 =10 V.27ter 2400 =11 V.26bis 2400 =12 V.23 1200/75 =13 V.23 600/75 =14 V22bis 2400/1200 =15 V.22 1200 =16 V.21 300 =17 V.32bis 14400/12000/9600/7200/4800 =18 V.32bis 7200/4800 =19 V.32bis 7200/4800 =24 Bell 212A 1200 =25 Bell 103 300 =32 V.17FAX 14400/12000/9600/7200 =34 Зарезервировано =35 Зарезервировано для 16800 =36 Зарезервировано для 19200 S20   Скорость DTE (определяется автоматически AT-командами) =0 76,8 кбит/c =1 57,6 кбит/c =2 38,4 кбит/c =3 19,2 кбит/c =4 16,8 кбит/c =5 14,4 кбит/c =6 12,0 кбит/c =7 9,6 кбит/c =8 7,2 кбит/c =9 4,8 кбит/c =10 3,6 кбит/c =11 2,4 кбит/c =12 1,8 кбит/c =13 1,2 кбит/c =14 600 бит/c =15 300 бит/c S21   Битовый регистр &Dn (7,6) =0 Модем игнорирует DTR-сигнал, предполагая, что он всегда присутствует =1 108.1, переключение DTE-сигнала из OFF в ON приводит к набору номера по умолчанию. Переход DTE в состояние OFF приводит к вешанью трубки =2 108.2, переход DTR в состояние OFF приводит к вешанию трубки и переключению в командный режим

&Rn (5) =0 CTS следует за RTS =1 Игнорирует RTS (CTS всегда в состоянии ON). &Cn (4) =0 CD всегда ON =1 CD следит за несущей $Sn (3) =0 Модем делает DSR всегда ON =1 В соответствии с CCITT Mn (2,1)=0 Громкоговоритель выключен =1 Громкоговоритель включен, пока не появится несущая =2 Громкоговоритель всегда включен =3 Громкоговоритель включен с момента, когда закончен набор последней цифры и до тех пор, пока не будет детектирована несущая *En (0) =0 Не поддерживает контроля ошибок, если не удалось об этом договориться =1 Разрывается связь, если не удается договориться о контроле ошибок S22 Зарезервировано S23   Битовый регистр Qn (7) =0 Модем возвращает код результата =1 Модем не возвращает код результата Vn (6) =0 Отображает код результата в цифровой форме =1 Отображает код результата в полной форме Xn (5,4,3) =0 Основной код результата (0-4). =1 Код результата (0-5, 10-21). =2 Код результата (0-6, 10-21). =3 Код результата (0-5, 7-21). =4 Код результата (0-21). =5 Управление кодом ошибки включено =6 Управление кодом ошибки включено =7 Управление кодом ошибки включено &Pn (2) =0 При импульсном наборе отношение make/break=39%/61%. =1 При импульсном наборе отношение make/break=33%/67%. T/P (1) =0 Тоновый набор =1 Импульсный набор En (0) =0 Отклик на команду блокирован =1 Отклик на команду разрешен S24   Битовый регистр Ln (7,6,5)=0-7 Управление громкостью громкоговорителя Nn (3,2,1)=0-7 Управление громкостью звонка S25   Зарезервировано S26 По умолчанию=0 RTS/CTS дисплей. Устанавливает задержку (в десятках миллисекунд) между RTS и откликом модема CTS в синхронном режиме S27   Битовый регистр *Qn (7,6) =0 Никакого отклика на плохое качество сигнала =1 Запускает повторную попытку при плохом качестве сигнала =2 Адаптивный алгоритм настройки скорости при изменении качества сигнала

=3 Разрывает связь при плохом качестве сигнала &Hn (5,4,3)=0 Управление потоком отключено =1 Зарезервировано =2 Зарезервировано =3 Аппаратный контроль потока CTS/RTS =4 Программный контроль потока XON/XOFF =5 Зарезервировано &Kn (2,1,0)=0 Никакого контроля ошибок =1 MNP4 (включая MNP3). =2 MNP4 + MNP5 =3 V.42 + MNP4 =4 V.42 + V42bis (совместимо с &K2). S28   Битовый регистр Bn (7) =0 Выбирает V.22 для связи при скорости 1200 бит/с =1 Выбирает Bell 212A для скорости 1200 бит/с &Bn (6) =0 Быстродействие DTE/DCE следует за возможностями канала =1 Быстродействие DTE/DCE фиксировано и определяется установкой DTE в диапазоне (300-76800)бит/с &Gn (5,4) =0 Ведущий тон отсутствует =1 Зарезервировано =2 Ведущий тон имеет частоту 1800 Гц S29   Указатель на номер телефона по умолчанию *Dn =n Устанавливает указатель в EEPROM на номер телефона по умолчанию (n=0-9). S30   Указатель на запасной номер телефона *Bn =0 Блокирует резервный номер телефона =n Разрешает наличие резервного номера и устанавливает указатель на его позицию в EEPROM (n=1-9). 1) Значения по умолчанию приведены для модема Zyxel U-1496

2) Функции битов для разных типов модемов варьируются

3) Опционная характеристика, присутствует не во всех модемах

4) Длина символа включает в себя стартовый бит, биты данных, бит четности и стоп-бит

Содержимое битовых регистров модема сохраняется в энергонезависимой памяти.

На этом список регистров, используемых в современном модеме не завершается, их число обычно превышает 50. Но функции этих регистров не стандартизованы и для получения информации о них рекомендуется обратиться к оригинальной документации по конкретным модемам.


Видеоконференции по каналам Интернет и ISDN


2.9 Видеоконференции по каналам Интернет и ISDN
Семенов Ю.А. (ГНЦ ИТЭФ)

Расширение международных контактов и реализация проектов с "удаленными" отечественными партнерами делает актуальной проблему экономии командировочных расходов особенно в случае коротких поездок (1-7 дней). Одним из средств решения проблемы является использование видеоконференций. Видеоконференции по каналам Интернет могут быть привлекательны для дистанционного обучения и медицинской диагностики. В отличие от телевизионных программ обучение с использованием Интернет предполагает диалог между преподавателем и обучаемым, что делает процесс более эффективным (эта техника может успешно дополнить WWW-методику, широко используемую в университетах США и Европы). Медицинские приложения еще более многообещающи. Видеоконференции позволят проконсультироваться в клинике, отстоящей на тысячи километров, устроить консилиум с участием врачей из разных городов, оперативно передать томограмму или многоканальную кардиограмму пациента с целью ее интерпретации и т.д. В более отдаленной перспективе технология видеоконференций может быть применена для целей телевидения.

Рис. 2.9.1. Оборудование, необходимое для видеоконференций

Для проведения видеоконференции необходимо иметь цифровой канал с пропускной способностью не менее 56-128кбит/с. Если канал не позволяет, можно ограничиться аудио телеконференцией (см. раздел IP-phone). Схеме оборудования, необходимого для видеоконференции показано на рис. 2.9.1.

Помимо стандартного оборудования рабочей станции (как правило, под ОС UNIX) требуется интерфейс для подключения видеокамеры и микрофонов. Этот интерфейс обычно снабжается аппаратной схемой сжатия видео и аудио данных. Многие современные мультимедиа интерфейсы снабжены входами для видеокамеры. Из обязательного оборудования на рис. 2.9.1 не показаны наушники и звуковые колонки. Полезным дополнением может служить сканнер, который позволит с высоким разрешением передать изображения документов или чертежей, видеомагнитофон, а также видео проектор для отображений принятого изображения на экране или телевизор с большим экраном.




Рис. 2.9.2. Структура системы H.323 и основных ее компонентов

H. 323 определяет четыре главных составляющих коммуникационной системы:

Терминалы Шлюзы Блоки многоточечного управления Системы управления доступом (gatekeepers)

Терминалы служат для предоставления пользователям определенных услуг и обеспечивают двухсторонний обмен данными в реальном масштабе времени. Все терминалы H.323 должны также поддерживать стандарт H.245, который служит для выбора параметров канала. Структура терминала показана на рис. 2.9.3.



Рис. 2.9.3. Структура терминала H.323

Интерфейс RAS (registration/admission/status) служит для взаимодействия с блоком доступа (gatekeeper) и поддерживает протоколы RTP/RTCP. Опционными частями H.323 являются видео кодеки, протоколы для проведения информационных конференций (T.120) и возможности поддержания многоточечной связи (mcu). Внешний шлюз также является опционным элементом конференций H.323. Шлюз может выполнять функции интерфейса для согласования с требованиями других форматов, например, H.225 – H.221 или других коммуникационных процедур, например, H.245 – H.242. Типичным шлюзом можно считать соединитель H.323 с коммутируемой телефонной сетью (GSTN). Блок схема такого шлюза показана на рис. 2.9.4.

Данный шлюз устанавливает аналоговую связь с терминалами GSTN, с терминалами H.320 по каналам ISDN и с терминалами H.324 по сети GSTN. Терминалы взаимодействуют со шлюзом через протоколы H.245 и Q.931. Применяя соответствующую перекодировку, можно обеспечить работу шлюза H.323 с терминалами, поддерживающими протоколы V.70, H.322, H.310 и H.321. Многие функции шлюза не стандартизованы, к их числу, например, относится нумерация подключенных терминалов.



Рис. 2.9.4. Схема шлюза IP/GSTN

Узел управления доступом (gatekeeper) является центральным блоком сети H.323. Через него проходят все запросы обслуживания, при этом он выполняет функцию виртуального переключателя. Узел управления доступом осуществляет преобразование имен терминалов и шлюзов в их IP и IPX-адреса в соответствии со спецификацией RAS. Например, если администратор сети установил верхний предел на число участников конференции, при достижении этого порога узел управления доступом может отказать в установлении соединения. Совокупность терминалов, шлюзов и блоков MTU, управляемая общим блоком доступа, называется зоной H.323. Узел управления доступом может опционно маршрутизовать запросы H.323. Разработчики иногда совмещают функции шлюза, MCU и узла управления доступом, возможно независимое совмещение функций MCU и узла управления доступом. К числу обязательных функций узла управления доступом относится.



преобразование адресов (например, из стандарта E.164 в транспортный формат) осуществление контроля доступа к локальной сети с использованием сообщений Admission Request, Confirm и Reject (возможен режим разрешения доступа для всех запросов) управление полосой пропускания (поддержка сообщений Bandwidth Request, Confirm и Reject) Управление зоной. Реализация всех вышеперечисленных функций для MCU, шлюза и терминалов, зарегистрированных в зоне.

Определены некоторые опционные функции узла управления доступом:

обработка запросов управления Q.931 осуществление авторизации терминалов (Q.931), допускаются ограничения доступа на определенные периоды времени управление запросами (контроль занятости терминалов и использования полосы пропускания)

Для организации конференций с числом участников три и более используется блок многоточечного доступа (MCU). MCU включает в себя многоточечный контроллер (MC) и многоточечный процессор (MP). MC осуществляет согласование рабочих параметров терминалов для обеспечения совместимости при передаче видео и аудио информации в рамках протокола H.245. Многоточечный контроллер управляет также ресурсами каналов, при этом поддерживается как уникастный, так и мультикастный обмен. Все терминалы посылают аудио, видео и данные MCU в режиме соединения точка-точка. Управляющая канальная информация H.245 передается непосредственно в MC. MP может выполнять перекодировку в случае использования кодеков различного типа. Конференция может быть организована в централизованном (все обмены идут через MCU) и децентрализованном режиме, когда терминалы непосредственно взаимодействуют друг с другом. Терминалы используют протокол H.245, для того чтобы сообщить MC, сколько видео- и аудио- потоков они могут обработать одновременно. MP может осуществлять отбор видеосигналов и смешение аудио-каналов при децентрализованной многоточечной конференции. Допускается и смешенный режим, когда одновременно реализуется централизованная и децентрализованная схема обменов.



Новейшая версия H.323 (v2) за счет аутентификации и шифрования/дешифрования обеспечивает безопасность и конфиденциальность (перехват в промежуточных узлах становится невозможным). Более подробно возможности версии 2 изложены в документе http://www.databeam.com/h323/.

Звуковой сигнал передается в оцифрованной и сжатой форме. Алгоритмы компрессии, поддерживаемые H.323, соответствуют требованиям стандартов ITU. Терминалы H.323 должны быть способны работать со стандартом компрессии голоса G.711 (56 или 64 Кбит/c). Голосовой кодек должен следовать рекомендациям G.723, а видео кодек должен соответствовать стандарту H.261 (поддержка H.263 является опционной, этот стандарт обеспечивает более высокое качество изображения). В таблице 2.9.1 приведены форматы для видео-конференций ITU.

Таблица 2.9.1

Формат картинки для видео-конференции

Размер изображения в пикселях

H.261

H.263

Sub-QCIF

128*96

не специфицировано

необходимо

QCIF

176*44

необходимо

необходимо

CIF

352*288

опционно

опционно

4CIF

702*576

-

опционно

16CIF

1408*1152

-

опционно

Видеоконференции реализуемы на ЭВМ IBM/PC [1,2], Mackintosh, SUN, HP, DEC. Пакетная техника обеспечивает удовлетворительное качество изображения и звукового сопровождения при низкой загрузке канала и малой вероятности ошибок при передаче пакетов. Достижимое сжатие видеосигнала - 1000:1, звукового 8:1.

Например, система SPARC classic M позволяет передавать по сети Ethernet до 30 кадров в секунду при разрешении 768x576 точек (PAL). Рассмотренное оборудование может использоваться не только для "дальней" связи, но для коллективного редактирования документов и чертежей в пределах одного предприятия, используя локальную сеть. Это может найти применение при реализации систем САПР больших предприятий. Для компрессии применяются методы CellB, JFPEG, MPEG1, Capture (YUV, RGB-8).

Наиболее популярные программные продукты для телеконференций: vic, vat, nv, wb, sd, ivs. (см. http://www.anl.gov/linda/video.html.)

Такие программные средства как VAT (Visual Audio Tool, ftp.ee.lbl.gov), nevot (network voice terminal, gaia.cs.umass.edu:/pub/hgschulz/nevot), VIC (Video Conference), IVS (INTRA Videoconferencing System, avahi.inria.fr:/pub/videoconference), NV (Net Video, beta.xerox.com:/pub/net-research) или wb (whiteboard, ftp.ee.lbl.gov) базируются на утилитах X11, они позволяют пользователю осуществить связь ЭВМ-ЭВМ или сессии с большим числом участников по каналам Интернет. Поддерживаются следующие схемы кодирования и передачи данных: PCM (64 Кбит/с), DVI, GSM и LPC (8 Кбит/с). В wb имеется возможность импорта файлов Postscript (обычно используемых для прозрачек). При этом достигается разрешение 640*512, число цветов равно 256, число кадров 2-20, коэффициент сжатия информации ~20:1, а требуемая полоса пропускания канала >128 Кбит/с. Эти параметры не идеальны. Желательно вдвое большее разрешение, число цветов должно быть равно 16 миллионам, а частота кадров 25-50, но это требует существенно большей пропускной способности каналов (> 2 Мбит/с). Но прогресс в области быстродействия каналов связи столь стремителен....



Система mmcc (Multimedia Conference Control program, ftp.isi.edu:confctrl/mmcc.tar.Z) во многом аналогична описанным выше, она позволяет клиенту осуществить вызов нужного партнера. Весьма полезной утилитой является SD (Session Directory, ftp.ee.lbl.gov:sd.tar.Z), которая может запускать приложения, необходимые для проведения видео конференций.

Пакет CUSeeMe (gated.cornell.edu:/pub/video/Mac.CU-SeeMe0.60b1) предназначен для персонального общения через Интернет, он работает на IBM/PC и MAC, требует 4 Мбайт оперативной памяти. Один кадр передается за 6-7 сек при полосе 28,8 Кбит/с, разрешение 320*240 пикселей. Такое качество соответствует скорее видео телефону. На экране предусмотрена область прокрутки, где можно напечатать какой-либо текст. Этим список доступных программных продуктов не исчерпывается. Приведенные здесь краткие описания даны лишь в качестве примеров.

Подчеркну, что качество работы сети более критично для передачи звука, чем изображения, ведь потеря нескольких кадров подчас совсем незаметна. Потеря же пакетов при передаче звука более заметна, особенно при диалоге. Когда же используется сжатие, любые повреждения пакетов приводят к потере целых блоков данных.

Для экспериментов с передачей звука и изображения группой IETF (Internet Engineering Task Force) была сформирована структура мультикастинг-сети MBONE. MBONE (Multicast Backbone, до 300 Кбит/с) представляет собой виртуальную сеть, построенную из уникаст-туннелей, которые функционируют поверх Интернет. MBONE составляет около 3,5% от всего Интернет. Рабочие станции для доступа к MBONE должны поддерживать IP-мультикастинг (см. RFC-1112 "Host Extensions for IP Multicasting"). Следует иметь в виду, что не все маршрутизаторы поддерживают мультикастинг.

При работе с MBONE отправитель не должен знать, кто является получателем, а требуемая пропускная способность канала не зависит от того, обслуживается один клиент или 100.

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

Частота
кадров/с

Размер экрана (24 цветовых бит)

1280*1024

640*480

320*240

160*120

30

900 Мбит/с

211 Мбит/с

53 Мбит/с

13 Мбит/с



В таблице приведены требования на пропускную способность канала при использовании различных степеней сжатия передаваемых видеоданных для частоты кадров 30/с и 24 бит на пиксель для отображения цвета.

Степень сжатия данных

Размер экрана
 

1280*1024

640*480

320*240

160*120

100:1

9 Мбит/с

2.11 Мбит/с

0.53 Мбит/с

0.13 Мбит/с

50:1

18

4,22

1,06

0,26

25:1

36

8,44

2,12

0.52

12:1

75

17,58

4,4

1,08

6:1

150

35,17

8,8

2,16

Требования при передаче звука определяются необходимым качеством, так для получения полосы 6 Кгц нужно 64 Кбит/с, а для уровня, сопоставимого с CD, - 1,4 Мбит/с. Применение сжатия информации позволяет снизить эти требования в 4-8 раз. Общепринятыми стандартами для сжатия изображения при видеоконференциях являются JPEG, MPEG, H.261. Обычно они реализуются программно, но есть и аппаратные реализации.

Если сегодня базовым транспортным протоколом для мультимедиа является UDP, то в самое ближайшее время его потеснит RTR и дополнят RSVP и ST-II, что заметно повысит качество и надежность (см. также раздел IP-phone).

Набор стеков протоколов, которые могут использоваться для реализации видео конференций в рамках стандартов ITU (транспортный протокол H.320):

1.

GSTN – H.324 – H.320 – [T.120; H.243; H.281]

2.

ISDN – H.221 – H.320 – [T.120; H.243; H.281]

3.

ISDN – PPP – IP – H.323 – H.320 – [T.120; H.243; H.281]

4.

LC – PPP – IP – H.323 – H.320 – [T.120; H.243; H.281]

5.

ATM – AAL5 – IP – H.323 – H.320 – [T.120; H.243; H.281]

6.

ATM – AAL1 – H.221 – H.320 – [T.120; H.243; H.281]


Виртуальные локальные сети VLAN, Интранет


6.2 Виртуальные локальные сети VLAN, Интранет
Семенов Ю.А. (ГНЦ ИТЭФ)

Широкое внедрение ИНТРАНЕТ, где группы разбросанных по сети пользователей локальных сетей объединяются друг с другом с помощью виртуальных каналов VLAN (Virtual Local Area Network; http://www.3com.com/nsc/200374.html), потребовало разработки новых протоколов. Архитектура VLAN позволяет эффективно разделять трафик, лучше использовать полосу канала, гарантировать успешную совместную работу сетевого оборудования различных производителей и обеспечить высокую степень безопасности. При этом пакеты следуют между портами в пределах локальной сети. В последнее время для задач построения VLAN разработан стандартный протокол IEEE 802.10 (3-ий сетевой уровень). Этот протокол предполагает, что пакеты VLAN имеют свои идентификаторы, которые и используются для их переключения. Протокол может поддерживать работу 500 пользователей и более. Полное название стандарта - IEEE 802.10 Interoperable LAN/MAN Security (MAN - Metropolitan Area Network - региональная или муниципальная сеть). Стандарт принят в конце 1992 года. Количество VLAN в пределах одной сети практически не ограничено. Протокол позволяет шифровать часть заголовка и информационное поле пакетов.

Стандарт ieee 802.10 определяет один протокольный блок данных (PDU), который носит название SDE (Secure Data Exchange) PDU. Заголовок пакета ieee 802.10 имеет внутреннюю и внешнюю секции и показан на рис. 6.2.1.

Рис. 6.2.1 Формат пакета IEEE 802.10

Поле чистый заголовок включает в себя три субполя. MDF (Management Defined Field) является опционным и содержит информацию о способе обработки PDU. Четырехбайтовое субполе said (Security Association Identifier) - идентификатор сетевого объекта (VLAN ID). Субполе 802.10 LSAP (Link Service Access Point) представляет собой код, указывающий принадлежность пакета к протоколу vlan. Предусматривается режим, когда используется только этот заголовок.

Защищенный заголовок копирует себе адрес отправителя из mac-заголовка (MAC - Media Access Control), что повышает надежность.

Поле ICV (Integrity Check Value) - служит для защиты пакета от несанкционированной модификации. Для управления VLAN используется защищенная управляющая база данных SMIB(security management information base).

Наличие VLAN ID (said) в пакете выделяет его из общего потока и переправляет на опорную магистраль, через которую и осуществляется доставка конечному адресату. Размер поля data определяется физической сетевой средой. Благодаря наличию mac-заголовка VLAN-пакеты обрабатываются как обычные сетевые кадры. По этой причине VLAN может работать в сетях TCP/IP (Appletalk или Decnet менее удобны). В среде типа Netbios работа практически невозможна. Сети ATM прозрачны для VLAN. Протокол VLAN поддерживается корпорацией cisco, 3com и др.. Хотя VLAN ориентирован на локальные сети, он может работать и в WAN, но заметно менее эффективно. В последнее время разработано большое число специальных программных средств сетевой безопасности. Среди них Firewall занимает лидирующее положение.

В разделе “Повторители, мосты (бриджи), мультиплексоры, переключатели и маршрутизаторы” упоминалась технология виртуальных сетей (vlan). Созданная для целей безопасности эта техника оказалась полезной для структуризации локальных сетей, приводящей к улучшению их рабочих характеристик. В настоящее время доступны переключатели, маршрутизаторы и даже концентраторы, поддерживающие виртуальные сети.

Виртуальные сети просто необходимы, когда локальная сеть в пределах одного здания совместно используется несколькими фирмами, а несанкционированный доступ к информации желательно ограничить. Принцип построения виртуальной сети показан на рис. 6.2.2.

Рис. 6.2.2. Схема переключателя (или концентратора) с поддержкой VLAN.

Для формирования VLAN необходимо устройство, где возможно осуществлять управление тем, какие порты могут соединяться. Например, пусть запрограммирована возможность пересылки пакетов между портами 1, 3 и 6, 2 и 5, а также между портами 4, 7 и 8. Тогда пакет из порта 1 никогда не попадет в порт 2, а из порта 8 в порт 6 и т.д. Таким образом, переключатель как бы разделяется на три независимых переключателя, принадлежащих различным виртуальным сетям. Управление матрицей переключения возможно через подключаемый из вне терминал или удаленным образом с использованием протокола SNMP. Если система переключателей, концентраторов (и возможно маршрутизаторов) запрограммирована корректно, возникнет три независимые виртуальные сети.

Данная технология может быть реализована не только в рамках локальной сети. Возможно выделение виртуальной сети в масштабах Интернет. В сущности, идея создания корпоративных сетей в Интернет (ИНТРАНЕТ) является обобщением идей виртуальных сетей на региональные сети.

Такая корпоративная сеть должна иметь один шлюз для входа в Интернет. Такой шлюз может выполнять функции Firewall, решая проблемы безопасности корпоративной сети.




Влияние шумов и помех


2.1.1 Влияние шумов и помех

Семенов Ю.А. (ГНЦ ИТЭФ)

Шумы определяют емкость канала и задают частоту ошибок при передаче цифровых данных. Шум по своей природе нестабилен и можно говорить лишь о том, что его величина с некоторой вероятностью лежит в определенном интервале значений. Плотность вероятности p(x) определяет вероятность того, что случайный сигнал X имеет значение амплитуды в интервале между x и x+Dx. При этом вероятность того, что значение х лежит в интервале между x1 и x2 определяется равенством:

.

P(x) – вероятность, а p(x) – плотность вероятности. Вероятность того, что x меньше некоторой величины y равна

Так называемый белый шум подчиняется непрерывному нормальному (Гауссову) распределению а – среднее значение x, а s – среднеквадратичное отклонение х от a. В случае шумов среднее значение х с учетом полярности часто принимает нулевое значение (а=0).

В этом случае, если мы хотим знать вероятность того, что амплитуда шумового сигнала лежит в пределах ±

v, то можно воспользоваться выражением

Для вычисления P{x1<x<-x1} обычно используются равенства

. Тогда P{x11} = .

Распределение P(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность

P{-kss}=Pk(k s) =

Из числа дискретных распределений наиболее часто используемым является распределение Пуассона.


Среднее значение x . Среднеквадратичное отклонение s случайной величины х определяется как: .

Как уже говорилось, во многих случаях шум имеет гауссово распределение с нулевым средним значением амплитуды. В этих случаях среднее значение мощности шумового сигнала равно вариации функции плотности вероятности. В этом случае отношение сигнал-шум будет равно

Шум определяет вероятность ошибки при передаче сообщения по каналу связи и, в конечном итоге, пропускную способность канала (см. теорему Шеннона; раздел 2.1 Передача сигналов по линиям связи ).



Внешний протокол BGP


4.4.11.4 Внешний протокол BGP

Семенов Ю.А. (ГНЦ ИТЭФ)

Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае – это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

1 OPEN (открыть) 2 UPDATE (изменить) 3 NOTIFICATION (внимание) 4 KEEPALIVE (еще жив)

После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):




Рис. 4.4.11.4.2 Формат сообщения open

Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.

Одно-октетный код идентификации позволяет организовать систему доступа, если он равен нулю, маркер всех сообщений заполняется единицами, а поле идентификационных данных должно иметь нулевую длину. При неравном нулю коде идентификации должна быть определена процедура доступа и алгоритм вычисления кодов поля маркера. Длина поля идентификационных данных определяется по формуле:

Длина сообщения = 29 + длина поля идентификационных данных.

Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный заголовок и может содержать другие поля в соответствии со схемой:



Рис. 4.4.11.4.3 Формат update-сообщения



Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны. Каждая такая запись имеет формат:



Длина префикса (в битах), равная нулю означает, что префикс соответствует всем IP-адресам, а сам имеет нулевой размер. Поле префикс содержит IP-адресные префиксы, за которыми следуют разряды, дополняющие их до полного числа октетов. Значения этих двоичных разрядов смысла не имеют.

Нулевое значение полной длины списка атрибутов пути говорит о том, что информация о доступности сетевого уровня в UPDATE-сообщении отсутствует. Список атрибутов пути присутствует в любом UPDATE-сообщении. Этот список имеет переменную длину, а каждый атрибут содержит три составные части: тип атрибута, длину атрибута и значение атрибута. Тип атрибута представляет собой двух-октетное поле со структурой:



Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0). Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля Флагов атрибута определяет, является ли информация в опционном переходном атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут пути характеризуют значение атрибута и интерпретируются согласно флагам атрибута.



Атрибуты пути бывают "стандартные обязательные" (well-known mandatory), "стандартные на усмотрение оператора", "опционные переходные" и "опционные непереходные". Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься, как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз.

Предусмотрены следующие разновидности кодов типа атрибута:

ORIGIN (код типа = 1) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:



Код атрибута

 Описание
0 IGP - информация достижимости сетевого уровня является внутренней по отношению к исходной автономной системе;
1 EGP - информация достижимости сетевого уровня получена с помощью внешнего протокола маршрутизации;
2 Incomplete - информация достижимости сетевого уровня получена каким-то иным способом.
AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH-атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей . Тип сегмента пути представляет в свою очередь однооктетное поле, которое может принимать следующие значения:



Код типа сегмента

Описание


1

 AS_set: неупорядоченный набор маршрутов в update сообщении;


2

 AS_sequence: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении.
<


/p> Длина сегмента пути представляет собой одно-октетное поле, содержащее число as, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый.

NEXT_HOP (код типа = 3) - стандартный обязательный атрибут, определяющий IP-адрес пограничного маршрутизатора, который должен рассматриваться как цель следующего шага на пути к точке назначения.

MULTI_EXIT_DISC (код типа = 4) представляет собой опционный непереходной атрибут, который занимает 4 октета и является положительным целым числом. Величина этого атрибута может использоваться при выборе одного из нескольких путей к соседней автономной системе.

LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.

ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который используется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов.

aggregator (код типа = 7) - опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета). Объем информации о достижимости сетевого уровня равен (в октетах):

Длина сообщения UPDATE - 23 - полная длина атрибутов пути - длина списка отмененных маршрутов. Информация о достижимости кодируется в следующей форме:



Поле длина определяет длину IP-адресного префикса в битах. Если длина равна нулю, префикс соответствует всем IP-адресам. Префикс содержит IP-адресные префиксы и двоичные разряды, дополняющие код до целого числа октетов.

Информация о работоспособности соседних маршрутизаторов получается из KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы уложиться во время, отведенное таймером сохранения (hold). Обычно это время не должно превышать одной трети от времени сохранения, но не должно быть и меньше 1 секунды. Если выбранное значение времени сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не обязательна.



NOTIFICATION- сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается. Помимо заголовка NOTIFICATION-сообщение имеет следующие поля:



Код ошибки представляет собой одно-октетное поле и указывает на тип данного сообщения. Возможны следующие коды ошибки:

Таблица 4.4.11.4.1. Коды ошибок



Код ошибки

 Описание
1 Ошибка в заголовке сообщения.
2 Ошибка в сообщении open
3 Ошибка в сообщении update
4 Истекло время сохранения
5 Ошибка машины конечных состояний
6 Прерывание
При отсутствии фатальной ошибки BGP-партнер может в любой момент прервать связь, послав NOTIFICATION-сообщение с кодом ошибки прерывание.

Одно-октетное поле cубкод ошибки предоставляет дополнительную информацию об ошибке. Каждый код ошибки может иметь один или более субкодов. Если поле содержит нуль, это означает, что никаких субкодов не определено.

Таблица 4.4.11.4.2 Субкоды ошибок



Ошибка

Субкод

Описание
Заголовок 1

2

3		 Соединение не синхронизовано

Неверная длина сообщения

Неверный тип сообщения
Сообщения OPEN 1

2

3

4

5

6		 Неверный код версии

Ошибочный код as-партнера

Ошибочный идентификатор BGP

Ошибка в коде идентификации

Ошибка при идентификации

Неприемлемое время сохранения
Сообщения UPDATE 1

2

3

4

5

6

7

8

9

10

11		 Ошибка в списке атрибутов

Не узнан стандартный атрибут

Отсутствует стандартный атрибут

Ошибка в флагах атрибута

Ошибка в длине атрибута

Неправильный атрибут origin

Циклический маршрут

Ошибка в атрибуте next_hop

Ошибка в опционном атрибуте

Ошибка в сетевом поле

Ошибка в as_path
Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:

1. ADJ-RIBS-IN: Запоминает маршрутную информацию, которая получена из update-сообщений. Это список маршрутов, из которого можно выбирать. (policy information base - PIB).
2. LOC-RIB: Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN.
3. ADJ-RIBS-OUT: Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений.
<


/p> Так как разные BGP- партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам.

Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел "Автономные системы и маршрутная политика"). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов.

BGP использует три таймера:

Connectretry (сбрасывается при инициализации и коррекции; 120 сек),

Holdtime (запускается при получении команд Update или Keepalive; 90сек) и

keepalive (запускается при посылке сообщения Keepalive; 30сек).

BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.

BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается.



Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:

Вычисление степени предпочтения для каждого маршрута, полученного от соседней AS, и передача информации другим узлам местной AS.

Выбор лучшего маршрута из наличного числа для каждой точки назначения и укладка результата в LOC-RIB.

Рассылка информации из loc_rib всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.

Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) – способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 – "Маршрутная политика"). Для приведенных примеров это в терминах масок выглядит следующим образом:





24 и 17 длины префикса сети.

Следует помнить, что маски с разрывами здесь недопустимы. Ниже приведена таблица метрик маршрутизации для различных протоколов.



Протокол

Метрика

Диапазон

Код "маршрут недостижим"
RIP

hello

BGP		 Число скачков

Задержка в ms

Не определена		 0-15

0-29999

0-65534		 16

30000

65535
Колонка "маршрут недостижим" содержит коды метрики, которые говорят о недоступности маршрута. Обычно предполагается, что если послан пакет из точки <А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не совпадают, представлен на рис. 4.4.11.4.4. В предложенной схеме имеется две ЭВМ "Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и "GW-1".



Рис. 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно".

Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:

1 GW-1 (192.148.166.35)
2 Место назначения (192.148.166.33)
Команда же traceroute 192.148.165.80 распечатает:

1 GW-1 (192.148.166.35)
2 GW-2 (192.148.166.7)
3 Место назначения (192.148.165.80)
Команда traceroute -g 192.148.165.80 сообщит вам:

1 GW-1 (192.148.166.35)
2 ***** ; В этом режиме маршрутизатор не откликается
3 Место назначения (192.148.165.80)
4 GW-1 (192.148.166.35)
5 ЭВМ-отправитель (192.148.166.32)
Из приведенных примеров видна также полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.

Другой полезной командой является Netstat, которая позволяет получить разнообразную информацию о состоянии сети. Существует четыре модификации этой команды:

-a отображает состояния всех соединений;

-i отображает значения конфигурационных параметров;



-r отображает таблицу маршрутов;

- v отображает статистику обмена локального Ethernet-интерфейса.

Например, команда netstat -r может выдать:

Routing tables (таблицы маршрутизации)



Destination

Gateway

Flags

Refcnt

Use

Interface
Stavropol-GW.ITEP.RU nb UGHD

0

 109 le0
ihep.su itepgw UGHD 0 103 le0
m10.ihep.su itepgw UGHD 0 16 le0
194.85.66.50 itepgw UGHD 0 455 le0
Kharkov.ITEP-Kharkov nb UGHD 0 105 le0
Bryansk-GW.ITEP.Ru nb UGHD 1 8113 le0
193.124.225.67 nb UGHD 0 0 le0
ixwin.ihep.su itepgw UGHD 1 6450 le0
ihep.su itepgw UGHD 0 14 le0
192.148.166.21 nb UGHD 0 109 le0
ihep.su itepgw UGHD 0 224 le0
193.124.225.71 nb UGHD 0 10 le0
194.85.112.0 ITEP-FDDI-BBone.ITEP UGD 0 253 le0
default itepgw UG 10 102497 le0
Здесь приведен только фрагмент маршрутной таблицы. Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway – имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Базовая команда netstat может обеспечить следующую информацию:

Active Internet connections (активные Интернет связи)



Proto

Recv-Q

Send-Q

Local Address

Foreign Address

(state)
tcp 0 0 127.0.0.1.1313 127.0.0.1.sunrpc TIME_WAIT
tcp 0 0 ns.1312 193.124.18.65.smtp SYN_SENT
tcp 0 0 127.0.0.1.1311 127.0.0.1.sunrpc TIME_WAIT
tcp 0 0 ns.1310 ns.domain TIME_WAIT
tcp 0 0 127.0.0.1.1309 127.0.0.1.sunrpc TIME_WAIT
tcp 39 24576 ns.nntp Bryansk-GW.ITEP.1697 ESTABLISHED
tcp 0 0 ns.telnet semenov.1802 ESTABLISHED
tcp 0 188 ns.1033 xmart.desy.de.6000 ESTABLISHED
udp 0 0 127.0.0.1.domain *.*
udp 0 0 ns.domain *.*
<


/p> Active UNIX domain sockets (активные UNIX-соединители домена)



Address

Type

Recv-Q

Send-Q

Vnode

Conn

Refs

Nextref Addr
ff64b38c stream 0 0 ff13187c 0 0 0 /dev/printer
ff64b28c dgram 0 0 0 0 0 0
ff64698c dgram 0 0 ff137fa8 0 0 0 /dev/log