Сети NGN

Автор: Пользователь скрыл имя, 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. Деталь проекта. Учебный материал.
Заключение
Литература

Работа содержит 1 файл

Готовый diplomniy proekt.doc

— 2.07 Мб (Скачать)

Наиболее перспективными на сегодняшний  день типами клиентов считаются  web-клиент и апплет, а также их переходные формы (например, «активный» web-клиент - часть пользовательского интерфейса которого реализована посредством апплетов). Их перспективность определяется тем, что они достаточно универсальны и обеспечивают необходимую гибкость при создании и эксплуатации, а достаточно высокие требования к ресурсам клиентского терминала нивелируются прогрессом в области аппаратного обеспечения.

Взаимодействие между клиентом и сервером приложений может осуществляться посредством любого стандартного протокола информационного обмена в компьютерных сетях (Telnet, SNMP, LDAP, FTP, HTTP, RPC и т. п.) или специального (специфичного для приложения или технологии разработки) протокола поверх транспортного уровня (например, поверх TCP/IP или UDP/IP), или поверх вышеуказанных стандартных протоколов, или посредством группы протоколов, а не одного какого-либо протокола. Выбор протоколов взаимодействия определяется потребностями конкретного приложения, т. е. зависит от типа клиента, вида информационного контента, используемых технологий разработки приложений и т. п. Сегодня наиболее часто в качестве базового протокола взаимодействия используется HTTP, так как он обладает достаточной функциональностью для приложений «клиент-сервер» и при этом обеспечивает прозрачную (беспрепятственную) передачу пользовательского трафика поверх любых сетей.

Логика взаимодействия между серверным  и клиентским процессами приложения обычно строится на базе модели «вызова удаленной процедуры» (RPC), так как это значительно облегчает процесс разработки приложения и упрощает логическое представление приложения в виде единого целого, выполняющего в единой среде исполнения.

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

  • COM/DCOM/OLE;
  • CORBA;
  • SOAP/XML/UDDI/WSDL.

Самой перспективной на сегодняшний  день объектной технологией является SOAP/XML, так как она наиболее универсальна, основывается на международных стандартах и имеет обширную поддержку со стороны различных производителей программного обеспечения. Эта технология чаще всего используется для создания web-сервисов (серверный процесс) и для обеспечения их взаимодействия с клиентским процессом. В качестве клиента в этом случае обычно выступает апплет или «активный» web-клиент. Как говорилось ранее, для работы данных клиентов требуется специальная среда исполнения. В основном используются только J2EE (Java SUN) и «.NET Framework» (Microsoft) среды исполнения, так как они базируются на открытых стандартах и поддерживаются большинством производителей программного обеспечения.

В компьютерных сетях взаимодействие между клиентом и сервером происходит напрямую или при посредничестве специализированных серверов (proxy и т.п.). В сетях NGN такое взаимодействие осуществляется при участии программного коммутатора (SX - SoftSwitch). Программный коммутатор в этом случае выполняет следующие функции;

  • аутентификации и авторизации, как клиента, так и сервера приложений (AS - Application Server);
  • учета (accounting) предоставленных услуг, трафика, времени со единения и т. п.;
  • управления соединением между клиентом и сервером, а также другими соединениями, предусмотренными логикой приложения (услуги);
  • управления сетевыми экранами (FW - Firewall) при взаимодействии с другими сетями, например, когда сервер приложений и клиент находятся в разных сетях;
  • управления шлюзами, например, когда осуществляется взаимодействие сервера приложений с абонентом сети с коммутацией каналов. Такое взаимодействие возможно, если сервер приложения поддерживает акустический интерфейс, символьный или специальный командный (например, Generic Functional Protocol в ISDN сетях).

На рис. 2.10 представлена возможная  логическая схема информационных потоков  между различным оборудованием NGN сети при взаимодействии клиента сети с сервером приложений. Через программный коммутатор обычно проходят только потоки управления, а потоки, связанные с передачей информационного контента приложения, проходят помимо него. В качестве протокола взаимодействия между программным коммутатором и сервером приложений, а также между коммутатором и абонентом сети NGN наиболее перспективным считается использование протокола SIP и его расширения.

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

. Организация уровня  предоставления услуг и управления  услугами

 

 

Рис. 4.1

 

  • сервер приложений обрабатывает запросы клиента и, взаимодействуя с сервером баз данных (DB), ассоциированным с программным коммутатором, вносит необходимые изменения в базы данных. Коммутатор, в свою очередь, взаимодействует с сервером баз данных (обычно посредством протокола LDAP) и предоставляет клиенту сети запрошенную услугу с заданными параметра ми. Недостатком данного сценария является то, что структура базы данных должна быть известна обоим устройствам, т. е. теряется универсальность и гибкость взаимодействия;
  • сервер приложений обрабатывает запросы клиента и, взаимодействуя с сервером баз данных (DB), ассоциированным с ним, вносит необходимые изменения в базы данных. Коммутатор, в свою очередь, взаимодействуя с сервером приложений, запрашивает необходимую информацию у сервера приложений и предоставляет клиенту сети запрошенную услугу с заданными параметрами. В этом сценарии роль сервера исполняет сервер приложений, а программный коммутатор исполняет роль клиента. Данный сценарий лишен недостатков первого сценария, но имеет свой недостаток, связанный с неоправданной повышенной нагрузкой на сервер приложений;
  • сервер приложений обрабатывает запросы клиента и, взаимодействуя с программным коммутатором, вносит изменения в базы данных, расположенные на сервере баз данных, ассоциированном с коммутатором. Коммутатор, в свою очередь, взаимодействует с сервером баз данных и предоставляет клиенту сети запрошенную ус лугу с заданными параметрами. В этом сценарии роль сервера исполняет программный коммутатор, а роль клиента исполняет сервер приложений. Данный сценарий лишен недостатков предыдущего сценария, но программный коммутатор должен быть способен исполнять роль сервера приложений, хотя и в ограниченных рамках;
  • сервер приложений обрабатывает запросы клиента и управляет программным коммутатором в процессе предоставления услуги. Подобное взаимодействие аналогично взаимодействию SSP с SCP в интеллектуальных сетях связи. В этом случае в качестве протокола взаимодействия может использоваться протокол INAP.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5. МЕХАНИЗМЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА  ОБСЛУЖИВАНИЯ В ПАКЕТНЫХ СЕТЯХ

 

 

 

 

 

 

 

 

 

 

 

 

5. Механизмы обеспечения качества обслуживания в пакетных сетях

 

Классификация сетевых  механизмов QoS

 

Механизмы QoS должны обеспечивать реализацию следующих функций:

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

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

  • механизмы QoS в каждом сетевом элементе (например, функции организации очереди, маршрутизации и профилирования трафика);
  • механизмы сигнализации QoS для обеспечения сквозного качества в сети между сетевыми элементами;
  • функции расчетов, управления и методов обеспечения QoS для управления и администрирования сетевого трафика.

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

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

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

На каждом из этих участков могут  быть задействованы различные механизмы  QoS. На пограничные устройства, прежде всего, возлагаются задачи классификации трафика (ToS) и четкого выполнения правил его обработки (policing). Основная же задача магистральной сети - максимально быстрая передача данных (в соответствии с их классом) и предотвращение перегрузок.

При классификации трафика на границе  сети нет необходимости повторять  эту операцию в магистрали сети - пакеты будут там обрабатываться в

соответствии с уже заданными  уровнями приоритетности.

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

 

Механизмы управления трафиком

 

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

В зависимости от решаемых задач  управление трафиком можно разделить на составные элементы:

  • формирование трафика (traffic shaping);
  • ограничение трафика (traffic policing);
  • организация и обработка очередей (queuing and scheduling);
  • контроль доступа (admission control).

 

Механизмы обеспечения QoS в IP-сетях

 

Все механизмы обеспечения  QoS в IP-сетях могут быть отнесены к двум классам:

  • дифференцированное обслуживание (DiffServ);
  • интегрированное обслуживание (IntServ).

 

Технология 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

Информация о работе Сети NGN