Автор: Пользователь скрыл имя, 20 Ноября 2012 в 22:44, дипломная работа
Сети NGN – это мультисервисная сеть, ядром которой является IP сеть, поддерживающая полную или частичную интеграцию услуг речи, данных и мультимедиа. NGN, так же, обеспечивает широкополосный доступ и поддерживает механизмы качества обслуживания.
Введение
1. Архитектура существующих систем NGN и обоснованность их построения
1.1 Принципы построения традиционных телефонных сетей
1.2 Недостатки TDM сетей и предпосылки перехода к NGN
1.3 Общие принципы построения сетей NGN
1.4 Трехуровневая модель NGN
2. Функциональная структура NGN
2.1 Классификация оборудования
2.2 Построение транспортных пакетных сетей
2.3 Протоколы сетей NGN
3. Технология SIGTRAN
3.1 Описание технологии
3.2 Архитектура SIGTRAN
3.3 Алгоритм взаимодействия NGN и ТфОП сетей при использовании SIGTRAN
3.4 Вызов со стороны SIP
3.5 Вызов со стороны SIGTRAN
4. Применение серверов приложений в сетях NGN
5. Механизмы обеспечения качества обслуживания в пакетных сетях
6. Охрана труда и техника безопасности
7. Экономическая эффективность
8. Деталь проекта. Учебный материал.
Заключение
Литература
Наиболее перспективными на сегодняшний день типами клиентов считаются web-клиент и апплет, а также их переходные формы (например, «активный» web-клиент - часть пользовательского интерфейса которого реализована посредством апплетов). Их перспективность определяется тем, что они достаточно универсальны и обеспечивают необходимую гибкость при создании и эксплуатации, а достаточно высокие требования к ресурсам клиентского терминала нивелируются прогрессом в области аппаратного обеспечения.
Взаимодействие между клиентом и сервером приложений может осуществляться посредством любого стандартного протокола информационного обмена в компьютерных сетях (Telnet, SNMP, LDAP, FTP, HTTP, RPC и т. п.) или специального (специфичного для приложения или технологии разработки) протокола поверх транспортного уровня (например, поверх TCP/IP или UDP/IP), или поверх вышеуказанных стандартных протоколов, или посредством группы протоколов, а не одного какого-либо протокола. Выбор протоколов взаимодействия определяется потребностями конкретного приложения, т. е. зависит от типа клиента, вида информационного контента, используемых технологий разработки приложений и т. п. Сегодня наиболее часто в качестве базового протокола взаимодействия используется HTTP, так как он обладает достаточной функциональностью для приложений «клиент-сервер» и при этом обеспечивает прозрачную (беспрепятственную) передачу пользовательского трафика поверх любых сетей.
Логика взаимодействия между серверным и клиентским процессами приложения обычно строится на базе модели «вызова удаленной процедуры» (RPC), так как это значительно облегчает процесс разработки приложения и упрощает логическое представление приложения в виде единого целого, выполняющего в единой среде исполнения.
Современные приложения разрабатываются на базе объектных моделей программирования, поскольку сами операционные системы строятся на базе объектных моделей, дополнительно упрощается логическая модель приложения и облегчается формирование пользовательского интерфейса. Сегодня наиболее широко используются следующие объектные технологии:
Самой перспективной на сегодняшний день объектной технологией является SOAP/XML, так как она наиболее универсальна, основывается на международных стандартах и имеет обширную поддержку со стороны различных производителей программного обеспечения. Эта технология чаще всего используется для создания web-сервисов (серверный процесс) и для обеспечения их взаимодействия с клиентским процессом. В качестве клиента в этом случае обычно выступает апплет или «активный» web-клиент. Как говорилось ранее, для работы данных клиентов требуется специальная среда исполнения. В основном используются только J2EE (Java SUN) и «.NET Framework» (Microsoft) среды исполнения, так как они базируются на открытых стандартах и поддерживаются большинством производителей программного обеспечения.
В компьютерных сетях взаимодействие между клиентом и сервером происходит напрямую или при посредничестве специализированных серверов (proxy и т.п.). В сетях NGN такое взаимодействие осуществляется при участии программного коммутатора (SX - SoftSwitch). Программный коммутатор в этом случае выполняет следующие функции;
На рис. 2.10 представлена возможная логическая схема информационных потоков между различным оборудованием NGN сети при взаимодействии клиента сети с сервером приложений. Через программный коммутатор обычно проходят только потоки управления, а потоки, связанные с передачей информационного контента приложения, проходят помимо него. В качестве протокола взаимодействия между программным коммутатором и сервером приложений, а также между коммутатором и абонентом сети NGN наиболее перспективным считается использование протокола SIP и его расширения.
При предоставлении дополнительных услуг, связанных с соединением, посредством программного коммутатора возможны следующие сценарии его взаимодействия с сервером приложения:
. Организация уровня
предоставления услуг и
Рис. 4.1
Все сценарии, где при предоставлении услуги непосредственно используется сервер базы данных (первые три сценария), больше подходят для предоставления статических услуг, т. е. таких услуг, которые требуют предварительного заказа услуги. Последний сценарий больше подходит для предоставления интерактивных или динамических услуг, т. е. таких услуг, которым требуется управление в процессе их предоставления со стороны пользователя, абонента или провайдера услуги.
5. МЕХАНИЗМЫ ОБЕСПЕЧЕНИЯ
5. Механизмы обеспечения качества обслуживания в пакетных сетях
Классификация сетевых механизмов QoS
Механизмы QoS должны обеспечивать реализацию следующих функций:
В соответствии с назначением все механизмы обеспечения качества обслуживания в сетях с пакетной коммутацией можно разделить на следующие группы:
Следует отметить, что не все из перечисленных механизмов имеют одинаковое значение во всей сети. Целесообразным является их распределение между пограничными и центральными сетевыми устройствами.
Например, задачи приоритезации и определения полномочий или контроля доступа (контроля соединения) должны возлагаться на пограничные устройства.
Задачи по предотвращению перегрузок в большей степени актуальны для магистральных устройств сети. В то же время очевидна необходимость создания единого сетевого механизма управления правилами назначения приоритетов и распределения сетевых ресурсов.
На каждом из этих участков могут
быть задействованы различные
При классификации трафика на границе сети нет необходимости повторять эту операцию в магистрали сети - пакеты будут там обрабатываться в
соответствии с уже заданными уровнями приоритетности.
Пакеты могут быть классифицированы
пограничным маршрутизатором
Механизмы управления трафиком
Цель управления трафиком заключается в оптимальном распределении сетевых ресурсов (пропускная способность каналов связи, буферное пространство, процессорное время обработки и т. д.), их максимально эффективном использовании, а также в исключении взаимного влияния различных видов трафика друг на друга.
В зависимости от решаемых задач управление трафиком можно разделить на составные элементы:
Механизмы обеспечения QoS в IP-сетях
Все механизмы обеспечения QoS в IP-сетях могут быть отнесены к двум классам:
Технология DiffServ
В соответствии с моделью DiffServ обеспечение качества обслуживания в сети IP предполагает наличие небольшого числа четко определенных блоков, на основе которых создаются различные услуги. Главной задачей DiffServ является определение стандартизованного байта дифференцированной услуги (DS) - байта типа обслуживания ToS (Type of Service) из заголовка пакета IP версии 4 и байта класса трафика (traffic Class) версии 6 - и его соответствующая маркировка, от которой зависит принятие решения о продвижении пакета данных на каждом переходе РНВ (Per-Hop Behavior).
Все узлы внутри DiffServ-домена определяют РНВ-политику, которая должна быть применена к пакету на основе хранящегося в нем значения поля кода дифференцированной услуги. РНВ-политика - это наблюдаемая извне политика поведения сетевого узла в отношении пакетов с определенным значением поля кода дифференцированной услуги (DSCP). Все пакеты потока трафика со специфическим требованием к обслуживанию имеют одно и то же значение поля DSCP. Пограничные узлы DiffServ-домена выполняют функцию формирования поступающего в DiffServ-домен трафика. Формирование трафика включает в себя выполнение функций классификации пакетов и ограничение трафика. При формировании трафика для каждого пакета сеть может определить соответствующую ему РНВ-политику.
Архитектура дифференцированных услуг представлена на рис. 5.1.
Архитектура дифференцированных услуг
Рис. 5.1
Преимуществом дифференцированного обслуживания (DiffServ) является возможность минимизации служебного трафика для исключения возможных задержек. Архитектура с дифференциацией сервисов прозрачна для приложений; основная нагрузка ложится на маршрутизаторы и коммутаторы поставщиков сетевых услуг. Необходимо сформировать некоторую зону в сети, поддерживающую качество сервиса: граничные маршрутизаторы классифицируют входной график, маркируют его и передают на транзитные устройства для дальнейшего продвижения. При этом однотипные приложения имеют одинаковые приоритеты, а соответствующие пакеты обрабатываются сходным образом.
Архитектура DiffServ предлагает базовый уровень сервисов, который обеспечивает поддержку качества обслуживания, предоставляет гибкий механизм для разработчиков активного сетевого оборудования. Но при использовании данной архитектуры возникают и определенные сложности. Каждый поставщик сетевых услуг обеспечивает качество сервиса в своей «зоне ответственности», однако нет гарантии, что поддержка будет сквозной для всей сети, как это имеет место в архитектуре IntServ.
Технология IntServ
Технология IntServ обеспечивает обслуживание трафика реального времени. Для этой цели вводятся два новых класса: гарантированного обслуживания (обеспечивает определенную полосу частот, задержку и отсутствие потерь в случае переполнения очередей, но не минимизирует величину разброса задержек) и контролируемой загрузки сети (обеспечивает обслуживание, аналогичное best effort, но, в отличие от него, при увеличении нагрузки QoS остается неизменным).
Рабочая группа IETF определила протокол RSVP как сигнальный протокол для архитектуры IntServ. Этот протокол позволяет приложениям посылать сигналы в сеть о своих QoS-требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.
Протокол RSVP сигнализирует о запросах резервирования ресурсов по доступному маршрутизируемому пути в сети. При этом RSVP не производит собственную маршрутизацию. При определении пути для данных и управляющего трафика RSVP полагается на используемый в сети протокол маршрутизации.
На рис. 3.3 показаны основные модули, информация о потоке данных и информация об управляющих потоках клиента и маршрутизатора, поддерживающих протокол RSVP.
Реализация протокола RSVP в узлах и маршрутизаторах
Рис. 5.2