Размещено на http://www.allbest.ru/

Введение

ОАО Московская государственная телефонная сеть (МГТС) установлен статус признанной эксплуатационной организации - оператор местной сети электросвязи общего пользования Российской Федерации, которая является одной из крупнейших местных сетей в мире. По числу абонентов, сложности кабельной сети и объему оборудования МГТС сравнима с национальными сетями таких стран, как Бельгия, Норвегия, Дания. На МГТС установлено более 500 автоматических телефонных станций (АТС). Дальнейшее расширение емкости МГТС путем введения кода «499» в дополнение к существующему коду «495» снимает проблему нехватки номерной емкости.

Начало деятельности Московской городской телефонной сети относится еще к 1882 году, когда была введена в эксплуатацию первая телефонная станция ручного обслуживания ёмкостью всего на 800 номеров. В списке ее телефонных абонентов числилось 26 человек. Это были в основном богатые коммерсанты, промышленники, способные позволить себе такую роскошь. Телефон удовлетворил насущную общественную потребность, сделав возможной связь через большие расстояния без использования промежуточных кодов, громоздких телеграфных аппаратов и посредников-телеграфистов. Общаться по телефону людям стало так же легко, как разговаривать, находясь лицом к лицу.

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

В течение последних лет были разработаны устройства, обеспечивающие передачу голоса по сетям, изначально нацеленным на передачу данных - сетям компьютерной телефонии. Основные выгоды, получаемые от таких способов передачи голосовой информации, следующие: во-первых, одну и ту же линию можно использовать и для передачи данных, и для передачи голоса. Пропускная способность линии используется более эффективно, чем при передаче цифровых данных по аналоговым сетям через модем. Цифровые данные передаются непосредственно в цифровом виде как соответствующая принятой кодировке последовательность импульсов, а голосовая информация перед передачей сжимается. Современные алгоритмы сжатия позволяют без потери качества сжимать голосовой поток 64 кбит/с в 10 раз (до 6,3 кбит/с), а с некоторыми издержками до 2,4 кбит/с. Во-вторых, при передаче голоса в виде пакетов возможно динамическое использование пропускной способности имеющихся каналов связи: суммарная емкость канала расходуется только на фактическую передачу информации. При работе с коммутацией каналов временной канал выделяется в течение всего времени соединения, независимо от того, действительно ли передается информация.

Таким образом, перспективным направлением развития телекоммуникационных сетей, в том числе и Московской городской телефонной сети, является эволюционный переход к цифровым сетям и в последующем переход от технологии коммутации каналов к технологии коммутации пакетов. При постоянно усложняющейся сетевой инфраструктуре и быстро растущем наборе услуг такой оператор перспективной телекоммуникационной сети, как ОАО «МГТС» должен располагать набором универсальных решений - совокупностью специализированных шлюзов для взаимодействия сетей и оборудования разного типа.

Глава 1. Структура протокола TCP/IP

1.1 Стек TCP/IP

Стек TCP/IP, называемый также стеком DoD и стеком Internet, является одним из наиболее популярных и перспективных стеков коммуникационных протоколов.

Стек был разработан по инициативе Министерства обороны США (Department of Defence, DoD) более 20 лет назад для связи экспериментальной сети ARPAnet с другими сателлитными сетями как набор общих протоколов для разнородной вычислительной среды. Сеть ARPA поддерживала разработчиков и исследователей в военных областях. В сети ARPA связь между двумя компьютерами осуществлялась с использованием протокола Internet Protocol (IP), который и по сей день является одним из основных в стеке TCP/IP и фигурирует в названии стека.

Большой вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает всемирная информационная сеть Internet, чье подразделение Internet Engineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.

Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.

Структура протоколов TCP/IP приведена на рисунке 1.1. Протоколы TCP/IP делятся на 4 уровня.



Рис. 1.1. Стек TCP/IP

Самый нижний (уровень IV) - уровень межсетевых интерфейсов - соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: для локальных каналов это Ethernet, Token Ring, FDDI, для глобальных каналов - собственные протоколы работы на аналоговых коммутируемых и выделенных линиях SLIP/PPP, которые устанавливают соединения типа "точка-точка" через последовательные каналы глобальных сетей, и протоколы территориальных сетей X.25 и ISDN. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня.

Следующий уровень (уровень III) - это уровень межсетевого взаимодействия, который занимается передачей дейтаграмм с использованием различных локальных сетей, территориальных сетей X.25, линий специальной связи и т. п. В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP, который изначально проектировался как протокол передачи пакетов в составных сетях, состоящих из большого количества локальных сетей, объединенных как локальными, так и глобальными связями. Поэтому протокол IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP является дейтаграммным протоколом.

К уровню межсетевого взаимодействия относятся и все протоколы, связанные с составлением и модификацией таблиц маршрутизации, такие как протоколы сбора маршрутной информации RIP (Routing Internet Protocol) и OSPF (Open Shortest Path First), а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol). Последний протокол предназначен для обмена информацией об ошибках между маршрутизатором и шлюзом, системой-источником и системой-приемником, то есть для организации обратной связи. С помощью специальных пакетов ICMP сообщается о невозможности доставки пакета, о превышении времени жизни или продолжительности сборки пакета из фрагментов, об аномальных величинах параметров, об изменении маршрута пересылки и типа обслуживания, о состоянии системы и т.п.

Следующий уровень (уровень II) называется основным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает устойчивое виртуальное соединение между удаленными прикладными процессами. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным методом, то есть без установления виртуального соединения, и поэтому требует меньших накладных расходов, чем TCP.

Верхний уровень (уровень I) называется прикладным. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и сервисов прикладного уровня. К ним относятся такие широко используемые протоколы, как протокол копирования файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet и ее российской ветви РЕЛКОМ, гипертекстовые сервисы доступа к удаленной информации, такие как WWW и многие другие.

Протокол SNMP (Simple Network Management Protocol) используется для организации сетевого управления. Проблема управления разделяется здесь на две задачи. Первая задача связана с передачей информации. Протоколы передачи управляющей информации определяют процедуру взаимодействия сервера с программой-клиентом, работающей на хосте администратора. Они определяют форматы сообщений, которыми обмениваются клиенты и серверы, а также форматы имен и адресов. Вторая задача связана с контролируемыми данными. Стандарты регламентируют, какие данные должны сохраняться и накапливаться в шлюзах, имена этих данных и синтаксис этих имен. В стандарте SNMP определена спецификация информационной базы данных управления сетью. Эта спецификация, известная как база данных MIB (Management Information Base), определяет те элементы данных, которые хост или шлюз должен сохранять, и допустимые операции над ними.

Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP. Кроме пересылки файлов протокол, FTP предлагает и другие услуги. Так пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов, FTP позволяет пользователю указывать тип и формат запоминаемых данных. Наконец, FTP выполняет аутентификацию пользователей. Прежде, чем получить доступ к файлу, в соответствии с протоколом пользователи должны сообщить свое имя и пароль.

В стеке TCP/IP протокол FTP предлагает наиболее широкий набор услуг для работы с файлами, однако он является и самым сложным для программирования. Приложения, которым не требуются все возможности FTP, могут использовать другой, более экономичный протокол - простейший протокол пересылки файлов TFTP (Trivial File Transfer Protocol). Этот протокол реализует только передачу файлов, причем в качестве транспорта используется более простой, чем TCP, протокол без установления соединения - UDP.

Протокол telnet обеспечивает передачу потока байтов между процессами, а также между процессом и терминалом. Наиболее часто этот протокол используется для эмуляции терминала удаленной ЭВМ.

1.2 Технология IP

1.2.1 Этапы развития

К настоящему моменту IP-телефония прошла три этапа развития протокола сигнализации: докоммерческий этап (1980-1995), компьютерный этап (1995-1999), и начавшийся на рубеже веков инфо-коммуникационный этап, продолжающийся и сегодня.

Докоммерческий этап характеризовался научно-исследовательской деятельностью в разных университетах и исследовательских организациях сообщества Интернет. Первая в истории попытка испробовать IP-телефонию была произведена в 1983 году в Кембридже, Массачусетс. В состав оборудования рабочих станций разных исследовательских проектов была включена так называемая «речевая воронка», выполнявшая функции цифровизации речи, ее пакетирования и передачи через Интернет между офисами BBN (Bolt, Beranek, Newman) на Восточном и Западном побережьях США. Немногочисленные энтузиасты IP-телефонии первого поколения должны были заранее находиться в режиме подключения к системе к моменту вызова, использовать на обоих концах одно самодельное программное обеспечение и тратить во время разговора значительные усилия на регулировку компрессии и попытки компенсации эха. Качество речи портили и длинные паузы, вызванные случайными задержками при прохождении пакетов по Интернет,«рваная» речь, получавшаяся в результате потерь пакетов, эхо из-за близкого расположения динамика компьютера и микрофона. И все же, именно в то время были созданы две рабочие группы IEFT: AVT {Audio/Video Transport) - группа транспортировки аудио/видео, которая создала транспортный протокол реального времени RTP, и MMUSIC (Multiparty Multimedia Session Control) - группа управления мультимедийным сеансом, спроектировавшая семейство протоколов для мультимедийной конференцсвязи через Интернет, включая самый удачный протокол IР-телефонии - протокол SIP [10].

Компьютерный этап был начат израильской компанией VocalTec, сумевшей к 1995 году собрать воедино достижения в областях процессоров цифровой обработки сигналов (DSP), кодеков, компьютеров, протоколов маршрутизации и увеличившей свой доход с 46 тысяч долларов во втором квартале 1995 года до 181 миллиона долларов во втором квартале 1996 года (из-за чего, собственно, предшествовавший этому этап развития IP-телефонии и назван до-коммерческим). Первоначально продукты VocalTec допускали только соединения PC - PC. Все функции сигнализации и управления реализовались непосредственно в этих PC, а программное обеспечение сеансов связи все еще ориентировалось на нестандартные протоколы разных компаний-производителей. Но уже в июне 1996 года 16-я Исследовательская комиссия Международного союза электросвязи (ITU-T) согласовала версию 1 протокола Н.323, названную стандартом для видеоконференцсвязи с негарантированным качеством обслуживания через локальную вычислительную сеть. Этот первый «зонтичный» стандарт IP-телефонии появился в нужное время и открыл тем самым следующий этап инфокоммуникационных услуг.

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

Да и по мере развития первых сетей IP-телефонии стали проявляться недостатки и ограничения Н.323. Весьма важным ограничением стало то, что шлюз Н.323 обрабатывает сигнализацию, выполняет управление обслуживанием вызова и транскодирование транспортных потоков в едином блоке, что создает проблему масштабируемости при росте трафика. Кроме того, Н.323 не обеспечивает также возможности подключения к ОКС7, что препятствует его «бесшовной» интеграции с существующей телефонной сетью общего пользования. Для того чтобы справиться с этими проблемами,

и была разработана концепция декомпозиции шлюза, при которой управление обслуживанием вызова сосредоточено в одном блоке, называемом Softswitch или контроллером транспортного шлюза MGC (Media Gateway Controller), а элементы преобразования транспортных потоков находятся в другом блоке, называемом транспортным шлюзом MG (Media Gateway. Тогда же, в 1998 году, был создан протокол управления шлюзами MGCP (Media Gateway Control Protocol), а после еще двух лет напряженной работы Исследовательской комиссии 16 ITU-T и IETF в июне 2000 появился стандарт управления транспортным шлюзом, названный Н.248 или MEGACO. Сам же мультимедийный трафик переносится по IP-сети, как правило, протоколом RTP.

1.2.2 Межсетевой протокол IP

IP (англ. Internet Protocol - межсетевой протокол) - маршрутизируемый сетевой протокол, основа стека протоколов TCP/IP.

Протокол IP (RFC 791) используется для ненадёжной доставки данных (разделяемых на так называемые пакеты) от одного узла сети к другому. Это означает, что на уровне этого протокола не даётся гарантий надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, оказаться повреждёнными или не прибыть вовсе. Гарантии безошибочной доставки пакетов дают протоколы более высокого (транспортного) уровня - например, TCP - которые используют IP в качестве транспорта.

В современной сети Интернет используется IP четвёртой версии, также известный как IPv4. В протоколе IP этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 4 октета (иногда говорят «байта», подразумевая распространённый восьмибитовый минимальный адресуемый фрагмент памяти ЭВМ). При этом компьютеры в подсетях объединяются общими начальными битами адреса. Количество этих бит, общее для данной подсети, называется маской подсети (ранее использовалось деление пространства адресов по классам - A, B, C; класс сети определялся диапазоном значений старшего октета и определял число адресуемых узлов в данной сети, сейчас используется бесклассовая адресация).

В настоящее время вводится в эксплуатацию шестая версия протокола - IPv6, которая позволяет адресовать значительно большее количество узлов, чем IPv4. Эта версия отличается повышенной разрядностью адреса, встроенной возможностью шифрования и некоторыми другими особенностями. Переход с IPv4 на IPv6 связан с трудоёмкой работой операторов связи и производителей программного обеспечения и не может быть выполнен одномоментно. На начало 2007 года в Интернете присутствовало около 760 сетей, работающих по протоколу IPv6. Для сравнения, на то же время в адресном пространстве IPv4 присутствовало более 203 тысяч сетей, но в IPv6 сети гораздо более крупные, нежели в IPv4(табл. 1.2.).

1.2.3 IP-пакет

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

Структура IP-датаграммы (пакета) в протоколе четвертой версии (IPv4) Таблица 1.2.

Версия (4 бит)	Длина (4 бит)	Тип обслуживания (8 бит)
Длина пакета
Идентификатор
0	DF	MF	Смещение фрагмента
Число переходов (TTL)	Протокол
Контрольная сумма заголовка
IP-адрес отправителя (32 бита)
IP-адрес получателя (32 бита)
Параметры (до 320 бит)
Данные (до 65535 байт минус заголовок)

Версия - для IPv4 значение поля должно быть равно 4.

Длина - длина заголовка IP-пакета в 32-битных словах (dword). Именно это поле указывает на начало блока данных в пакете. Минимальное корректное значение для этого поля равно 5.

Идентификатор - значение, определяемое отправителем пакета и предназначенное для определения корректной последовательности пакетов.

3 бита флагов. Первый бит должен быть всегда равен нулю, второй бит DF (don't fragment) определяет возможность фрагментации пакета и третий бит MF (more fragments) показывает, не является ли этот пакет последним в цепочке пакетов. Смещение фрагмента - значение, определяющее позицию фрагмента в потоке данных.

Протокол - идентификатор интернет-протокола следующего уровня (см. IANA protocol numbers и RFC 1700). В IPv6(табл. 1.3.) называется «Next Header».

Структура IP-датаграммы (пакета) в протоколе шестой версии (IPv6) Таблица 1.3.

Версия (4 бита)	Класс трафика (8 бит)	Метка потока (20 бит)
Длина полезной нагрузки (16 бит)	След. заголовок (8 бит)	Число переходов
IP-адрес отправителя (128 бит)
IP-адрес получателя (128 бит)
Данные

Версия - для IPv6 значение поля должно быть равно 6.

Класс трафика - определяет приоритет трафика (QoS, класс обслуживания).

Метка потока - уникальное число, одинаковое для однородного потока пакетов.

Длина полезной нагрузки - длина данных (заголовок IP-пакета не учитывается).

Следующий заголовок - определяет следующий инкапсулированный протокол.

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

Диапазоны для локальных сетей

При подключении пользовательского компьютера к Интернету, IP-адреса выбираются из диапазона, предоставленного провайдером. Компьютеры, не имеющие IP-адреса, выданного провайдером, могут (при правильной настройке маршрутизации) работать с другими локальными компьютерами, имея IP-адреса из диапазонов, зарезервированных для локальных сетей (RFC 1918):

· сеть класса А 10.0.0.0 - 10.255.255.255 (маска подсети 255.0.0.0),

· сеть класса B 172.16.0.0 - 172.31.255.255 (маска подсети 255.240.0.0),

· сеть класса C 192.168.0.0 - 192.168.255.255 (маска подсети 255.255.0.0),

· сеть 2001:0DB8::/32 в IPv6 - зарезервировано для примеров и документации.

Компьютеры с такими адресами могут получать доступ к Интернету посредством прокси-серверов или NAT.

При построении сетей, составляющих Интернет (например сетей провайдеров), выбираются строго определённые диапазоны адресов, назначенные организацией ICANN. ICANN является «высшей инстанцией» в вопросах резервирования диапазонов и имеет свои представительства по всему миру - например, в Европе распределение адресов координирует RIPE NCC.

RIPE NCC (фр. Rйseaux IP Europйens + англ. Network Coordination Centre) - один из пяти региональных интернет-регистратур (Regional Internet Registries, RIRs), выполняющих распределение интернет-ресурсов, а также связанную с этим регистрацию и координацию деятельности, направленную на глобальную поддержку функционирования Интернета.

RIPE NCC функционирует как кооператив локальных интернет-регистратур (англ. Local Internet Registry, LIR), каждая из которых платит членский взнос. В роли LIR обычно выступают крупные интернет-провайдеры или корпорации.

Выделение интернет-ресурсов происходит согласно процедурам RIPE NCC, формализованным в соответствующих документах. Документы, устанавливающие процедуры работы с ресурсами, принимаются собранием членов RIPE (англ. RIPE General Meeting) - открытого тематического форума, проходящим дважды в год. Перед вынесением документов на

голосование производится работа над проектами документов в рабочих группах и обсуждение проектов в открытых почтовых рассылках RIPE.

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

RIPE NCC руководит Аксель Паулик (англ. Axel Pawlik).

Офис RIPE NCC находится в Амстердаме, Нидерланды.

1.2.4 IP-адрес

IP-адрес (aй-пи адрес, сокращение от англ. Internet Protocol Address) - уникальный идентификатор (адрес) устройства (обычно компьютера), подключённого к локальной сети или интернету.

IP-адрес представляет собой 32-битовое (по версии IPv4) или 128-битовое (по версии IPv6) двоичное число. Удобной формой записи IP-адреса (IPv4) является запись в виде четырёх десятичных чисел (от 0 до 255), разделённых точками, например, 192.168.0.1. (или 128.10.2.30 - традиционная десятичная форма представления адреса, а 10000000 00001010 00000010 00011110 - двоичная форма представления этого же адреса).

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

IP-адрес состоит из двух частей: номера сети и номера узла. В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12 или 10.0.0.0/8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером либо региональным интернет-регистратором (Regional Internet Registry, RIR). Всего существует пять RIR: ARIN, обслуживающий Северную Америку; APNIC, обслуживающий страны Юго-Восточной Азии; AfriNIC, обслуживающий страны Африки. LACNIC, обслуживающий страны Южной Америки и бассейна Карибского моря; и RIPE NCC, обслуживающий Европу, Центральную Азию, Ближний Восток. Региональные регистраторы получают номера автономных систем и большие блоки адресов у ICANN, а затем выдают номера автономных систем и блоки адресов меньшего размера локальным интернет-регистраторам (Local Internet Registries, LIR), обычно являющихся крупными провайдерами.

Номер узла в протоколе IP назначается независимо от локального адреса узла. Маршрутизатор по определению входит сразу в несколько сетей. Поэтому каждый порт маршрутизатора имеет собственный IP-адрес. Конечный узел также может входить в несколько IP-сетей. В этом случае компьютер должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом, IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.

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

На рис. 1.4. показана структура IP-адреса разных классов.

Рис. 1.4. Структура IP-адреса разных классов

Бесклассовая адресация

Со второй половины 90-х годов XX века классовая адресация повсеместно вытеснена бесклассовой адресацией, при которой количество адресов в сети определяется только и исключительно маской подсети.

Особые IP-адреса

· В протоколе IP существует несколько соглашений об особой интерпретации IP-адресов:

· если весь IP-адрес состоит только из двоичных нулей, то он обозначает адрес того узла, который сгенерировал этот пакет; этот режим используется только в некоторых сообщениях ICMP;

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

· если все двоичные разряды IP-адреса равны 1, то пакет с таким адресом назначения должен рассылаться всем узлам, находящимся в той же сети, что и источник этого пакета. Такая рассылка называется ограниченным широковещательным сообщением (limited broadcast);

· если в поле номера узла назначения стоят только единицы, то пакет, имеющий такой адрес, рассылается всем узлам сети с заданным номером сети. Например, в сети 192.190.21.0 с маской 255.0.0.0 пакет с адресом 192.190.21.255 доставляется всем узлам этой сети. Такая рассылка называется широковещательным сообщением (broadcast).

Динамические IP-адреса

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

Для получения IP-адреса клиент может использовать один из следующих протоколов:

· DHCP (RFC 2131) - наиболее распространённый протокол настройки сетевых параметров,

· BOOTP (RFC 951) - простой протокол настройки сетевого адреса, обычно используется для бездисковых станций,

· IPCP (RFC 1332) в рамках протокола PPP (RFC 1661),

· Zeroconf (RFC 3927) - протокол настройки сетевого адреса, определения имени, поиск служб.

Постоянный IP адрес

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

Также постоянный IP адрес пригодится для того, чтобы к вашему компьютеру можно было получить доступ из сети Интернет. Когда вы соединяетесь с модемным пулом, то ресурсам машины, к которым вы пожелали открыть доступ можно получить доступ из сети. Но для этого нужно знать IP-адрес вашего компьютера. При входе в сеть интернет вам выдается динамический адрес, но этот адрес будет вашим только в течение данного сеанса связи, и в следующий раз он изменится. Поэтому пользователь, который захочет установить с вами соединение (например, для онлайн игры, или соединению по протоколу FTP) не будет знать имени вашей машины.

1.2.5 Протокол RTP

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).



Рис. 1.5. Уровни протоколов RTP/UDP/IP

На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP -- это транспортный протокол, реализованный на прикладном уровне.

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).

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

Рис. 1.6. Заголовок RTP

Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.

RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

1.2.6 Кодеки VoIP

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

Революционным толчком, позволившим прийти к передаче речи средствами IP-телефонии, стало появление процессоров цифровой обработки сигналов DSP (Digital Signal Processor), архитектура которых оптимизирована для выполнения операций, характерных для типичных алгоритмов обработки сигналов, например, умножение с накоплением или выборку операндов с бит-инверсной адресацией для выполнения быстрого преобразования Фурье. Физически DSP выполняются в виде интегральных микросхем, содержащих в одном кристалле ядро процессора, память и периферийные устройства для обмена информацией. Наличие встроенной памяти обеспечивает быстрый доступ ядра к ее содержимому для получения максимальной производительности. Функционально на DSP реализуются кодеки для использования в приложениях VoIP.

Различаются эти кодеки, в частности, по требуемой полосе пропускания канала. Для узкополосных кодеков скорость передачи информации лежит в пределах 1.2-64 Кбит/с, что определяет качество передачи речи. Существует несколько подходов к проблеме определения качества, наиболее популярным из которых является оценка MOS (Mean Opinion Score), которая определяется как среднее значение оценок качества по пятибалльной шкале, данных большой группой слушателей. Экспертам предъявляются для прослушивания разные звуковые фрагменты - речь, музыка, речь на фоне того или иного шума и т.д. Оценки интерпретируют следующим образом: 4-5 - высокое качество, которое аналогично или выше качества передачи речи при разговоре по сети ISDN; 3.5-4 - качество ТфОП (toll quality), обеспечиваемое при большинстве телефонных связей через ТфОП, а мобильные сети обеспечивают качество чуть ниже toll quality; 3-3.5 - качество речи по-прежнему удовлетворительное, однако его ухудшение хорошо заметно на слух; 2.5-3 - речь разборчива, однако для ее понимания требуется концентрация внимания.

Кроме того, еще одной функцией кодеков в шлюзах VoIP является подавление периодов молчания (VAD, CNG, DTX), позволяющее уменьшить объем информации, передаваемой в течение таких периодов, и освободить на это время занимаемую полосу пропускания. В двустороннем разговоре такие меры позволяют сократить объем передаваемой информации до 50%, а в децентрализованных многоадресных конференциях за счет большего числа говорящих - и более. Технология подавления молчания имеет три важных составляющих: детектор речевой активности VAD (Voice Activity Detector) определяет моменты времени, когда пользователь говорит, оценивает энергию входного сигнала и активизирует передачу, если она выше некоторого порога; прерывистая передача DTX (Discontinuous Transmission) вынуждает кодек прекратить передачу пакетов в то время, когда VAD обнаружил период молчания (а возобновляет ее снова VAD), генератор комфортного шума CNG (Comfort Noise Generator), создающий у говорящего ощущение присутствия собеседника на другом конце при отключенной передаче. Совершенные кодеки, например, G.723.1 Annex А или G.729 AnnexВ имеют возможность предоставлять удаленному декодеру информацию для восстановления шума с близкими к исходному параметрами.

Большинство кодеков обрабатывает речевую информацию блоками, называемыми кадрами. Выбор размера кадра (frame) важен, так как минимальная теоретически достижимая задержка передачи информации (т.н. алгоритмическая задержка) определяется суммой этого параметра и длины буфера предварительного анализа.

Как было показано в предыдущем параграфе, к кадру, сгенерированному кодеком, добавляется необходимая дополнительная информация: заголовки IP (20 байтов), UDP (8 байтов) и RTP (12 байтов), поэтому большинство реализаций VoIP использует пересылку нескольких кадров в пакете. Число таких кадров ограничено максимально допустимой задержкой. В большинстве случаев в одном пакете передается до 120 мс речевой информации.

Еще одним фактором работы шлюзов VoIP является чувствительность к потерям кадров, являющимся неотъемлемым атрибутом IP-сетей. Применяются коды с исправлением ошибок, позволяющие снизить количество потерь кадров при данном числе потерянных пакетов. Некоторая избыточная информация распределяется между несколькими пакетами так, что при потерях некоторого числа пакетов кадры могут быть восстановлены. Но положительный эффект при введении избыточности для борьбы с потерями кадров не столь легко достижим, так как потери в IP-сетях происходят пачками, т.е. значительно более вероятно, что будут наблюдаться потери сразу нескольких пакетов подряд, чем потери всего одного из нескольких последовательно передаваемых пакетов. Так что, если применить простые схемы введения избыточности, например, повторяя посылку каждого кадра два раза в соседних пакетах, то это, скорее всего, окажется в реальных условиях бесполезным, приводя лишь к передаче значительного объема избыточной информации. Кроме того, введение избыточности отрицательно сказывается на задержке воспроизведения сигнала. Например, если мы повторяем один и тот же кадр в четырех следующих один за другим пакетах, для того чтобы обеспечить возможность восстановления информации при потере трех подряд идущих пакетов, декодер вынужден поддерживать буфер из четырех пакетов, а это вносит значительную дополнительную задержку. Влияние потерь кадров на качество воспроизводимой речи зависит от используемого кодека. Если потерян кадр, состоящий из N отсчетов кодека G.711, то на приемном конце будет отмечен пропуск звукового фрагмента длительностью N*125 мкс. Если используется более совершенный узкополосный кодек, то потеря кадра может сказываться на воспроизведении нескольких последующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером - потеря кадра длительностью 20 мс может привести к слышимому эффекту длительностью 150 мс и более. Кодеры типа G.723.1 разрабатывались так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качество ухудшается катастрофически.

Отметим, что G.711 - наиболее известный, часто называемый просто ИКМ, цифровой кодек речевых сигналов, поддерживаемый всеми шлюзами VoIP, был стандартизован ITU-T в 1965 году, его типичная оценка MOS составляет 4.3. Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 года. Кодек G.723.1 имеет длительность кадра 30 мс с длительностью предварительного анализа 7.5 мс и два режима работы: 6.3 Кбит/ с (кадр имеет размер 189 битов, выровненных до 24 байтов) и 5.3 Кбит/с (кадр имеет размер 158 битов, выровненных до 20 байтов). G.723.1 обеспечивает оценку MOS 3.7 в режиме 6.3 Кбит/с и 3.9 в режиме 5.3 Кбит/с, имеет детектор речевой активности и обеспечивает генерацию комфортного шума на удаленном конце в период молчания.

ADPCM кодек G.726 (рекомендация принята в 1990 г.) обеспечивает кодирование цифрового потока G.711 со скоростью 40, 32, 24 или 16 Кбит/с, поддерживая оценки MOS на уровне 4.3 (32 Кбит/с), что часто принимается за эталон уровня качества телефонной связи (toll quality). В приложениях VoIP этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потере информации.

Кодек G.728 использует оригинальную технологию линейного предсказания с малой задержкой LD-CELP (low delay code excited linear prediction) и обеспечивают оценки MOS, аналогичные G.726 при скорости передачи только 16 Кбит/с.

Кодек G.729 очень популярен в сетях Frame Relay, использует технологию CS-ASELP (Conjugate Structure, Algebraic Code Excited Linear Prediction) и обеспечивает скорость передачи 8 Кбит/с. В рамках спецификаций G.729 определены алгоритмы VAD, CNG и DTX.

Еще одной задачей шлюзов VoIP является передача сигналов многочастотного набора номера DTMF. Узкополосные кодеки, чтобы достичь низких скоростей передачи информации, опираются на тот факт, что сигнал, который они кодируют, представляет собой именно речь, а сигналы DTMF при прохождении через такие кодеки искажаются и не могут быть успешно опознаны соответствующим приемником на удаленном конце. В ряде случаев, а именно, когда пользователь ТфОП вынужден ввести какую-то дополнительную информацию в удаленную систему при уже установленном соединении (например, номер дебитной карты или номер пункта меню автоинформатора), необходимо обеспечить возможность надежной передачи DTMF-сигналов через сеть VoIP. Существуют две процедуры передачи DTMF-информации по сетям VoIP:

обязательный метод, в соответствии с которым специальное сообщение протокола Н.245 (Userinputindication) может содержать символы цифр и знаки «*» и «#». Используется надежное TCP-соединение, так что информация не может быть потеряна, однако из-за особенностей TCP могут иметь место значительные задержки;

нестандартный метод, предложенный VoIP форумом, может быть использован в терминалах H.323v2 при использовании процедуры fastStart и отсутствии канала Н.245. В этом случае для передачи DTMF открывается специальный RTP-сеанс, в котором передаются кодированные значения принятых цифр, а также амплитуды и длительности сигналов. Использование RTP позволяет четко привязать сигналы DTMF к реальному времени, что является важным преимуществом этого метода.

1.2.7 Сценарии IP-телефонии

1.2.7.1 Сети Н.323

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323. Сети на базе протоколов Н.323 ориентировались на интеграцию с телефонными сетями и вначале рассматривались как сети ISDN, наложенные на IP-сети.

В частности, процедура установления соединения в сетях IP-телефонии по Н.323 базировалась на рекомендации Q.931 и аналогична процедуре, используемой в ISDN.

Протокол Н.323 подробно рассматривается в главе 5 книги, а здесь отметим, что рекомендация Н.323 включает в себя довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов, а обеспечивает работу мультимедийных приложений в сетях с не гарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видео и данными. Протокол RAS (Registration, Admission, Status), входящий в семейство протоколов Н.323, обеспечивает контроль использования сетевых ресурсов и поддерживает аутентификацию пользователей и начисление платы за услуги. Основными устройствами сети Н.323 являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit).

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

Входящий в состав Н.323 протокол Н.225.0 (Q.931) специфицирует процедуры установления, поддержания и разрушения соединения, а в качестве транспортного протокола использует протокол TCP. По протоколу И.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP, которые рассмотрены выше и представлены на рис. 1.6.

В этом же параграфе была упомянута еще одна важная проблема - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, этот протокол используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

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

1.2.7.2 SIP-сеть

Более популярный сегодня подход к построению сетей IP-телефонии был предложен рабочей группой IETF с музыкальным названием MMUSIC в документе RFC 2543. В его основу положен протокол SIP (Session Initiation Protocol). Эта архитектура включает в себя также протокол резервирования ресурсов RSVP (Resource Reservation Protocol), рассмотренные выше в этой главе транспортный протокол реального времени RTP (Real-Time Transport Protocol; RFC 1889) и протокол передачи потоков в реальном времени RTSP (Real-Time Streaming Protocol; RFC 2326), протокол описания параметров связи SDP (Session Description Protocol; RFC 2327), а также протокол уведомления о связи SAP (Session Announcement Protocol). Сразу же подчеркнем, что функции протокола SIP не зависят ни от одного из этих протоколов.

Сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDR. Там же протокол SIP поддерживает услуги Интеллектуальной сети, такие как преобразование (мэппинг) имён, переадресация и маршрутизация, что существенно при использовании SIP в Softswitch сети общего пользования, где приоритетной задачей Оператора является предоставление широкого спектра телефонных услуг. Другой важной особенностью протокола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутен-тифицировать пользователя при его перемещении из одного места в другое.

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации. Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент UAC (User Agent Client) и агент пользователя - сервер UAS (User Agent Server). Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и передает обратно ответы, т.е. выступает в качестве вызываемой стороны. Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации.

Глава 2. Взаимодействие систем коммутации каналов и коммутации пакетов

Определенно первым этапом реконструкции сети должен быть заменой электромеханических АТС на цифровые по технологии с коммутацией каналов (КК). В последние годы ОАО МГТС вкладывает большие инвестиции в реконструкцию существующей аналоговой сети, заменяя электромеханические АТС на цифровые, и по утвержденной программе развития и реконструкции сети предусмотрена ежегодная замена электромеханических АТС на цифровые в объеме 400-500 тыс. номеров. На рис.2.1 приведена динамика развития и реконструкции сети ОАО МГТС. При этом в самый разгар работ по реконструкции в телекоммуникационной отрасли происходит принципиальная смена поколений технологий. На смену системам КК приходит технология коммутации пакетов (КП).

Рис. 2.1. Динамика развития сети 1995 - 2012 г.

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

Использование пакетных технологий будет положительно влиять на развитие ОАО МГТС для предоставления широкого спектра новых услуг пользователям.

При этом первые опыты уже были получены при создании широкополосной сети передачи данных общего пользования (СПД ОП), которая охватывала всю территорию города. Ёмкость сети СПД ОП в 2010 году превысила 240,0 тыс. номеров. Практически услугу СПД ОП может получить каждый абонент МГТС.

На Рис.2.2 показана перспективная структурная схема сети ОАО МГТС, которая включает:

· транзитную сеть, образованную транзитными узлами ТУЭ, установленными на волоконно-оптических кольцах SDH верхнего уровня (SDH-BУ) и кольцах XDM;

· цифровую сеть, образованную ОПТСЭ, установленными на волоконно-оптических кольцах XDM и кольцах SDH нижнего уровня (SDH-HУ);

· сеть передачи данных общего пользования, использующую волоконно-оптические кольца BУ и HУ и сеть доступа ОАО МГТС.

Характерными особенностями перспективной сети ОАО МГТС являются:

· Использование единой магистральной транспортной среды, построенной на принципах пакетной коммутации и обеспечивающей передачу всех видов трафика (речь, данные, видео и др.).

Рис.2.2. Структурная схема перспективной сети ОАО «МГТС»