- •Содержание
- •Глава 5. Типы оборудования в мультисервисных сетях………….…………………….41
- •Глава 9. Технологии сетей широкополосного абонентского доступа…………….……74
- •Глава12. Примеры построения мультисервисных сетей связи в рф….…………...…106
- •Введение
- •Глава 1. Понятие мсс и ее базовые принципы
- •1.1. Понятие и основные определения мсс
- •1.2. Требования к мсс как сетям связи нового поколения
- •1.3. Особенности инфокоммуникационных услуг
- •Глава 2. Архитектура мультисервисных сетей связи
- •Глава 3. Услуги и службы мультисервисных сетей
- •3.1. Классификация служб и услуг мультисервисных сетей Дадим некоторые основные понятия и определения
- •3.2. Коммуникационные службы мсс
- •3.3. Информационные службы мсс
- •3.4. Операторы на рынке перспективных инфокоммуникационных услуг
- •Vpn как услуга
- •Услуги Triple Play
- •Глава 4. Протоколы мультисервисных сетей связи
- •4.1. Основные типы протоколов
- •4.2. Протокол н.323
- •4.3. Протокол sip
- •4.4. Протокол mgcp
- •4.5. Протокол megaco/h.248
- •4.6. Протокол sigtran
- •4.7. Протокол передачи информации с управлением потоком
- •Глава 5. Типы оборудования в мультисервисных сетях
- •5.1. Гибкий (программный) коммутатор Softswitch
- •5.1.1. Эталонная архитектура Softswitch
- •Транспортная плоскость
- •Плоскость управления обслуживанием вызова и сигнализации
- •Плоскость услуг и приложений
- •5.1.2. Основные характеристики Softswitch
- •Поддерживаемые протоколы
- •Поддерживаемые интерфейсы
- •5.2. Шлюзы
- •5.2.1. Основные характеристики шлюзов Емкость
- •Производительность
- •Поддерживаемые интерфейсы
- •5.3. Терминальное оборудование
- •5.4. Сервер приложений
- •Глава 6. Ims-единая платформа для доставки услуг в мсс
- •6.1. Способы предоставления услуг
- •Некоторые протоколы, подсистемы, стандарты, применяемые в современных сетях сотовой подвижной связи
- •Обозначение и функции элементов ip Multimedia Core Network
- •6.2. Конвергенция услуг и сетей
- •6.3. Универсальная технология для всех услуг
- •6.4. Аспекты стандартизации
- •6.5. Поступательное развитие сетей
- •Стандартизация применяемых решений
- •Глава 7. Технология mpls - фундамент для инфраструктуры мультисервисных сетей следующего поколения
- •7.2. Принцип коммутации
- •7.3. Элементы архитектуры Метки и способы маркировки
- •Стек меток
- •Компоненты коммутируемого маршрута
- •Привязка и распределение меток
- •7.4. Построение коммутируемого маршрута
- •7.5. Перспективы технологии mpls
- •7.6. Краткий глоссарий терминов по технологии mpls
- •8.1. Понятие «качество обслуживания»
- •8.2. Резервирование ресурсов
- •8.3. Дифференцированные услуги
- •8.4. Коммутация по меткам
- •8.5. Пути реализации качества обслуживания
- •Глава 9. Технологии сетей широкополосного абонентского доступа
- •9.1. Основные технологии доступа
- •9.1.1. Беспроводная технология
- •Третьим положительным фактором технологии беспроводной связи является значительно более короткое время ввода системы в действие по сравнению с кабельной инфраструктурой.
- •9.1.2. Спутник для доступа в мсс
- •9.1.3. Семейство технологий хDsl
- •9.2. Сетевая архитектура
- •Глава 10. Управление и эксплуатационно-техническое обслуживание мсс
- •10.1. Система управления, построенная на базе snmp
- •10.2. Система управления на базе архитектуры tmn
- •10.3. Суэто для мультисервисных сетей
- •Глава 11. Обеспечение информационной безопасности в мультисервисных сетях
- •11.1. Рынок информационной безопасности
- •11. 2. Архитектура информационной безопасности
- •11.3. Угрозы безопасности мсс
- •11.4. Классификация угроз нсд в мсс
- •Цели (объекты) угроз
- •Пути проникновения действия угроз
- •11.5. От каких угроз иб следует защищать мсс
- •11.6. Пять наиболее важных технологий в области информационной безопасности
- •11.6.2. Встроенные средства биометрии
- •11.6.3. Жесткие диски со встроенной возможностью шифрования
- •11.6.4. Браузеры и приложения со встроенными функциями защиты
- •11.6.5. Защита для мобильных устройств
- •11.7. Перспективы информационной безопасности
- •Глава 12. Примеры построения мультисервисных сетей связи в Российской Федерации
- •12.1. Мсс нового поколения от основных операторов связи
- •12.2. Мсс в регионах России
- •12.2.1. Мультисервисная сеть птт
- •12.2.2. Сеть нового поколения в Новокузнецке
- •12.2.3. Мультимедийная сеть нового поколения в Якутии
- •12.2.4. Мультисервисная сеть в Ханты-Мансийском округе
- •Заключение
- •Список литературы
- •Термины и определения
- •Махровский
8.2. Резервирование ресурсов
Протокол сигнализации Resource reSerVation Protocol (RSVP) обеспечивает управление резервированием сетевых ресурсов в IP-сети для реализации интегрированных сервисов (Integrated Services, IntServ). Первоначальная его спецификация, разработанная сотрудниками Университета шт. Южная Каролина и компании Xerox, была опубликована консорциумом IETF в 1997 году (RFC 2205). Около трех лет назад появилась обновленная версия RSVP (RFC 2750). Архитектура IntServ впервые описана в 1994 году в документе RFC 1633.
Протокол RSVP предусматривает два принципиально различных типа сервисов — гарантированный (IntServ Guaranteed) и с контролируемой сетевой нагрузкой (IntServ Controlled). В первом случае речь идет об эмуляции выделенного виртуального канала в IP-сети: потоку гарантируется доступность запрошенной полосы пропускания и одновременно задаются жесткие границы для величины суммарной задержки. Сервис IntServ Guaranteed можно воспринимать как формирование сети коммутации каналов, наложенной на сеть коммутации пакетов. Второй случай аналогичен сервису best effort в условиях незагруженной сети; конкретные диапазоны задержек и других параметров передачи не устанавливаются.
Не вдаваясь в детали, работу протокола RSVP можно представить следующим образом. Источник данных отправляет одному или нескольким получателям сообщение PATH, в котором содержится спецификация трафика (нижняя и верхняя границы полосы пропускания, максимальная задержка и ее неравномерность). Каждый поддерживающий RSVP маршрутизатор, расположенный на пути предполагаемого следования трафика, при получении сообщения PATH запоминает содержащиеся в нем параметры потока и адрес узла, от которого поступило данное сообщение, после чего транслирует его на следующий узел.
Собственно резервирование ресурсов инициируется получателем, который после приема сообщения PATH отправляет в обратном направлении (источнику) запрос RESV. Помимо характеристик трафика, полученных от источника, этот запрос содержит спецификации потока (тип сервиса и ряд вспомогательных параметров) и фильтра (транспортный протокол и номер порта). Две последние спецификации играют роль дескриптора потока.
При получении запроса RESV очередной маршрутизатор производит аутентификацию запроса и выделяет требуемые ресурсы. Если запрос не может быть удовлетворен, источнику отправляется сообщение об ошибке, в противном случае запрос RESV отсылается дальше в восходящем направлении. Наконец, если последний маршрутизатор (то есть расположенный ближе всего к источнику) также в состоянии удовлетворить запрос RESV, он отправляет получателю подтверждающее сообщение.
После этого начинается передача данных. Поддерживающие RSVP маршрутизаторы отправляют поступающие пакеты на классификатор, который отвечает за их приоритезацию. Затем пакеты помещаются в буферные очереди. Распределение пакетов по классам сервиса осуществляет пакетный фильтр, он же определяет маршрут их дальнейшего следования. Управление очередями пакетов и выделение ресурсов для их транспортировки относятся к сфере компетенции диспетчера пакетов.
Ресурсы могут выделяться потокам на индивидуальной либо разделяемой основе. При индивидуальном резервировании в каждом сеансе для каждого отправителя формируется отдельный поток. Разделяемый режим означает, что несколько отправителей могут использовать один и тот же поток, если они не создают друг другу помех.
Выбор режима определяется спецификацией фильтра. Для фиксированного фильтра (Fixed Filter, FF) используется индивидуальное резервирование: каждому отправителю соответствует отдельный запрос RESV, а общая емкость выделенных ресурсов определяется совокупностью запросов к явно заданному набору отправителей. (Если несколько получателей ожидают трафик от одного и того же отправителя, их запросы объединяются, а ресурсы выделяются на разделяемой основе.) Спецификация фильтра с явным указанием отправителей применяется и для разделяемого резервирования (Shared Explicit, SE), только потоки от источников, перечисленных в запросе RESV, используют одни и те же ресурсы. Неявная спецификация (Wildcard Filter, WF) предполагает, что по единому виртуальному каналу будет передаваться трафик от всех отправителей.
Фильтры SE и WF подходят для обработки многоадресного трафика, например при проведении аудиоконференций. Применение FF предпочтительнее для передачи видеосигналов.
Следует отметить несколько принципиальных особенностей механизма резервирования ресурсов в рамках RSVP, отличающих его от других протоколов:
сам по себе протокол RSVP не отвечает за транспортировку или маршрутизацию данных, а лишь управляет этими процессами, а потому может функционировать параллельно с TCP или UDP;
RSVP ориентирован только на полудуплексную передачу, и для двустороннего обмена требуется устанавливать два самостоятельных сеанса RSVP;
каждый маршрутизатор выделяет ресурсы на ограниченный промежуток времени (soft reservation), в течение которого получатель должен успеть обновить свой запрос RESV. Процедура периодического обновления полезна для оперативного реагирования на изменения маршрутов и состава групп многоадресной рассылки;
при передаче трафика через несколько сетей на его пути могут встретиться устройства, не поддерживающие RSVP. Протокол применим и в этом случае (вариант с туннелированием), хотя вне доменов RSVP можно рассчитывать только сервис best effort;
ключевая роль получателей в резервировании ресурсов позволяет выделять последние для многоадресного трафика даже в том случае, когда спецификации, поступающие от разных получателей, различны. Для их обработки используется схема «вложения» запросов в узлах тиражирования трафика.
С точки зрения поддержки на уровне приложений и сетевых устройств протокол RSVP является, пожалуй, самым сложным из всех аналогичных технологий. Радикальное отступление от принципа best effort позволяет достичь наивысшего уровня сервиса в плане гарантированности параметров передачи, степени детализации при описании запрашиваемых ресурсов и качества обратной связи с приложениями. Применение архитектуры IntServ и протокола RSVP оказывается идеальным выбором для поддержки приложений реального времени, но в других случаях обеспечиваемый уровень QoS становится ненужным, а «цена» (излишняя сложность конкретных реализаций) — неоправданно высокой. Это обстоятельство обусловило появление не столь изощренных методов поддержки QoS в глобальной сетевой среде, одним из которых является DiffServ.