Главная  Классификация протоколов сигнализации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [ 159 ] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169]

Архитектура OSI

Прикладной уровень

Уровень представления

Сеансовый уровень

Транспортный уровень

Сетевой уровень

Уровень звена данных

Физический уровень

Архитектура X 25

Уровень пакетов

Уровень звена данных

Физический уровень

Рис. 9.5. Взаимосвязь между архитектурами OSI и Х.25

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

Формат пакетов Х.25 имеет вид, показанный на рис. 9.6 [59]. Первый разряд К/И в байте 3 указывает, является ли пакет информационным или управляющим. Остальная часть байта 3 служит для указания типа управляющего пакета. В следующем байте две группы по 4 разряда служат для указания длины адресного поля вызывающего и вызываемого DTE, соответственно. Затем следуют сами эти поля. В режиме быстрого поиска в конце пакета могут быть добавлены данные пользователя (до 16 байтов).

8 7 6 5 4 3 2 1

Идентификатор формата

Номер группы логических каналов

Байт 1

Номер логического канала

Байт 2

Идентификатор типа пакета

БайтЗ

Добавляемый заголовок пакета или данные пользователя

Байт 4

Рис. 9.6. Структура пакета Х.25: общий формат

Фактически различия между архитектурами Х.25 и OSI имеют место именно на этом, сетевом уровне, который по терминологии Х.25 называется уровнем пакетов. Протокол Х.25 ориентирован на соединения в виде виртуальных каналов, которые организуются с использованием ресурса постоянно существующих логических каналов. Каждому DTE доступно до 4095 таких каналов. Точнее говоря, предусматривается до 15 групп логических каналов по 255 каналов в каждом. Еруппа адресуется четырьмя, а канал - восемью битами в заголовке пакета. Двоичные значения этих полей означают номер группы и номер канала соответственно. Существует взаимно однозначное соответствие между номерами логических каналов в DTE и ВСЕ. Фактическое количество логических каналов, которые может использовать DTE, определяется администрацией сети. Логические каналы используются для организации двух типов виртуальных соединений - устанавливаемых по запросу и постоянных. Иными словами, пакетный уровень реализует два типа услуг предоставления виртуальных каналов - услуги оперативного предоставления виртуального соединения (Virtual Call service, VC) и услуги предоставления постоянного виртуального канала связи {Permanent Virtual Circuit service, РУС),



Виртуальные соединения по запросу (virtual calls) формируются процедурами создания и аннулирования соединения, т.е. пакеты маршрутизируются по виртуальному каналу, организуемому в сети протоколом третьего уровня перед передачей пакетов. Процедура создания инициируется со стороны DTE, посылающего к DCE по свободному логическому каналу пакет запроса соединения. Протокол Х25 предполагает выбор свободного канала с наибольшим номером. Пакет запроса должен в явном виде содержать адрес получателя. По получении пакета с запросом соединения DCE передает этот пакет через сеть к DCE, с которым связан вызываемый DTE, причем на вызываемой стороне выбирается свободный логический канал с наименьшим номером. Вызываемый DTE имеет возможность принять или отвергнуть поступивший запрос, а вызывающий DTE получит ответ, указывающий на то, принял или нет запрос вызываемый DTE. В случае принятия запроса между двумя DTE организуется виртуальное соединение и наступает фаза переноса данных. В случае же, когда соединение по какой-либо причине не может быть установлено, сеть возвращает вызывающему DTE пакет разьединения, содержащий информацию о соответствующей причине. Нарушить установленное соединение может любой из DTE, в нем участвующих.

Постоянный виртуальный канал связи (permanent virtual circuit) представляет собой постоянное соединение между двумя DTE и поддерживается сетью все время. Процедуры оперативного создания и аннулирования для него не нужны, и постоянный виртуальный канал связи подобен, таким образом, выделенной линии связи.

9.4. ПРИМЕНЕНИЯ ПРОТОКОЛА Х.25

Протокол Х.25 широко используется уже почти четверть века, в первую очередь, для создания всемирной сети с коммутацией пакетов.

Ближе к тематике данной книги применение Х.25 в системах централизации технической эксплуатации ТфОП. Именно таким образом, например, организованы центры дистанционного технического обслуживания и эксплуатации (MMSW) коммутационных станций DX-200 (Nokia) и АТСЦ-90 (ЛОНИИС).

Другая сфера применения Х.25 связана также с дистанционным, но не техническим обслуживанием АТС. Речь идет о мониторинге телефонных разговоров. Практика мониторинга телефонных линий существует достаточно давно: первые упомянутые в литературе устройства для мониторинга телефонных переговоров в России были установлены в помещении IV Государственной думы в 1913 году [45]. Сегодня организационные аспекты в этой области регламентируются законом «Об оперативно-розыскной деятельности в Российской Федерации» от 13.03.92, но более глубокая, по мнению автора, регламентирующая формула появилась на 19 веков раньше и принадлежит Ювеналу: Quis custodiet ipsos custodes? (Кто устережет самих сторожей?). По этой причине технические детали данной сферы применения протокола Х.25 останутся за пределами книги, а внимание будет уделено другой области - ISDN.

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

При использовании варианта, обозначенного в рекомендации как Case А, сеть ISDN предоставляет оборудованию Х.25 прозрачный канал (коммутируемый или полупостоянный) ДЛЯ доступа к шлюзу сети Х.25. Устройство DTE Х.25 запрашивает через терминальный адаптер ISDN соединение с устройством DCE Х.25 в режиме виртуального канала. Для установления соединения ISDN между терминальным адаптером и шлюзом используется D-канал и протоколы ISDN. Сигнализация по D-каналу ISDN заканчивается в АТС, а собственно виртуальный канал между DCE и DTE устанавливается по В-каналу ISDN средствами уровня 3 протокола Х.25. Этот же В-канал используется затем для передачи



трафика пакетов Х.25.

При использовании варианта Case В возможности коммутации пакетов Х.25 становятся частью ISDN. Устройство DTE создает виртуальный канал средствами ISDN, а АТС ISDN может обеспечить коммутацию пакетов или получить доступ к DCE Х.25. Обслуживание вызова и управление реализуются средствами ISDN. Данный вариант принят в качестве стандарта для североамериканских сетей ISDN и служит основным способом запроса пересылки кадров LAPB по В-каналу, а также методом инкапсуляции кадров LAPB в кадры LAPD для пересылки по D-каналу.

С тех пор, как в исходных стандартах ISDN для коммутации пакетов неречевого трафика был использован стандарт Х.25, произошли значительные усовершенствования в среде передачи данных и в применяемых протоколах, позволяющие достичь очень низкого уровня ошибок. В нормативных документах ISDN, выпущенных после 1988 г., уже рекомендуется вместо коммутации пакетов Х.25 использовать технику Frame Relay, ориентированную лишь на минимальный контроль ошибок при передаче. Снижение непроизводительных затрат времени на контроль ошибок может позволить соответствующим образом увеличить скорость обмена данными.

Глава 10

ПРОТОКОЛЫ ИНТЕРНЕТ

Все реки текут в море, но море не переполняется: к тому месту, откуда реки текут, они возвращаются, чтобы опять течь, Екклесиаст (гл. 1, ст.4-11)

10.1. ПРОТОКОЛЫ TCP/IP и МОДЕЛЬ OSI

в истории античных времен названы семь чудес света: египетские пирамиды, храм Артемиды в Эфесе, Мавзолей в Еаликариасе, статуя Зевса в Олимпе, Колосс Родосский, висячие сады Семирамиды в Вавилоне и Александрийский маяк. Для истории XX века в семерку чудес света наряду с телефоном, радио, компьютером, вероятно, должна войти и всемирная сеть Интернет, базирующаяся на наборе протоколов TCP/IP (Transmission Control Protocol/Internet Protocol).

Протоколы ТСРЯР были разработаны почти три десятилетия назад по заказу Управления перспективных исследований и разработок Министерства обороны США (ARP А) и внедрены в государственной сети Defense Data Network (DDN), включающей в себя сети ARPANET и MILNET. Первоначальная цель была связана с построением отказоустойчивой коммуникационной сети, которая могла бы функционировать даже при выходе из строя ее большей части, например, из-за ядерных бомбардировок. Широкое распространение ТСРЯР получили в 1982 году, когда средства их поддержки были включены в ядро операционной системы UNIX 4.2BSD. Это объединение TCP/IP с ОС UNIX сделало протоколы TCP/IP доступными для всех UNIX-сетей. В том же году произошло еще одно важное событие в истории TCP/IP - в упомянутый комплект был включен протокол разрешения адреса ARP (Address Resolution Protocol), который ставит Ethernet-адреса в соответствие межсетевым ТСР/1Р-адресам. Затем протоколы ТСРЯР были реализованы на рабочих станциях семейства Sun в сетевых файловых системах NFS (Network File System) для обеспечения межсетевых коммуникаций. Сейчас практически невозможно найти аппаратуру или операционную систему, где в той или иной форме не применялся бы протокол TCP/IP. Но самое главное для набора протоколов ТСРЯР сегодня - обслуживание Сети сетей - Интернет.

В предыдущей, да и во многих других главах этой книги автор пропагандировал комплект протоколов OSI в качестве стандарта в области построения

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



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [ 159 ] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169]

0.0011