Получатель
Каждый маршрутизатор, поддерживающий протокол RSVP, получив сообщение Path, фиксирует адрес предыдущего маршрутизатора как элемент “структуры пути”. Таким образом, в сети создается фиксированный маршрут. Поскольку сообщения Path содержат те же адреса отправителя и получателя, что и пакеты данных, пакеты будут маршрутизироваться корректно даже через сетевые области, не поддерживающие протокол RSVP.
Сообщение Path содержит шаблон данных отправителя (Sender Template), описывающий тип этих данных. Шаблон специфицирует фильтр, который может отделять пакеты этого отправителя от других пакетов в пределах сессии.
Кроме того, сообщение Path должно содержать спецификацию потока данных отправителя Tspec, которая определяет характеристики этого потока. Спецификация Tspec используется для того, чтобы предотвратить избыточное резервирование.
Шаблон данных отправителя имеет тот же формат, что и спецификация фильтра в сообщениях Resv (Reservation).
В зависимости от идентификатора протокола, заданного для сессии, шаблон может специфицировать только IP-адрес отправителя или (но не обязательно) также и UDP/TCP-порт.
Приняв сообщение Path, получатель передает к маршрутизатору, от которого пришло это сообщение (т.е. по направлению к отправителю), запрос резервирования ресурсов – сообщение Resv.
В дополнение к информации Tspec, сообщение Resv содержит спецификацию запроса (Rspec), в которой указываются нужные получателю параметры качества доставки и спецификацию фильтра (filterspec), которая определяет, к каким пакетам сессии относится данная процедура (рисунок 3).
Вместе Rspec и filterspec представляют собой дескриптор потока, используемый маршрутизатором для идентификации каждой процедуры резервирования ресурсов.
Когда получатель данных передает запрос резервирования, он может запросить передачу ему ответного сообщения, подтверждающего резервирование.
При получении сообщения Resv каждый маршрутизатор в резервируемом пути, поддерживающий протокол RSVP, определяет, приемлем ли этот запрос, для чего выполняются две процедуры:
механизм управления доступом;
процедура режимного контроля (policy control).
С помощью механизмов управления доступом проверяется, имеются ли у маршрутизатора ресурсы, необходимые для поддержки запрашиваемого качества доставки информации, а с помощью процедуры режимного контроля (policy control) – правомерен ли запрос резервирования ресурсов. Если запрос не может быть удовлетворен, маршрутизатор отвечает на него сообщением об ошибке.
Если запрос приемлем, маршрутизатор передает сообщение Resv следующему маршрутизатору, находящемуся ближе к отправителю данных.
Сообщение Resv содержит спецификацию flowspec, в которую входит два набора параметров:
“Rspec”, который определяет желательное качество доставки информации;
“Tspec”, который описывает информационный поток.
Когда маршрутизатор, ближайший к инициатору процедуры резервирования, получает сообщение Resv и выясняет, что запрос приемлем, он передает подтверждающее сообщение получателю данных.
После окончания описанной процедуры ее инициатор начинает передавать данные и на их пути к получателю будет обеспечено требуемое качество доставки информации.
Совместное использование двух протоколов – RSVP на уровне доступа и MPLS на уровне транспортной сети – позволяет предоставлять пользователям конвергентной сети гарантированное качество доставки информации.
Взаимодействие существующих сетей с NGN
На начальном этапе ССОП может стать частью конвергентной сети, а на стыках между ССОП и транспортной сетью IP/MPLS будут устанавливаться шлюзы VoIP – устройства, которые предназначены для преобразования потока информации, поступающего от сети связи общего пользования, к виду, пригодному для передачи по IP-сетям.
Кроме того, в конвергентную сеть войдут сети IP-телефонии альтернативных операторов, использующие для установления соединений протоколы Н.323 и SIP. Сегодня такие сети используются, в основном, для междугородной и международной связи, но в условиях конвергентной сети они станут альтернативой ССОП.
Для управление взаимодействием сетей, входящих в конвергентную сеть, используется многофункциональный и весьма ответственный узел Softswitch.
Этот узел призван управлять соединениями при межсетевой связи, шлюзами и сетевым трафиком. В процессе управления соединениями Softswitch решает задачи поддержки систем сигнализации взаимодействующих сетей. Следует отметить, что Softswitch управляет обслуживанием вызовов и не отвечает за соединение через маршрутизаторы IP-сети. Известны российские разработки: Tario.Net Softswitch и Протей-Softswitch.
На рисунке 4 приведен пример установления соединения абонента ССОП с пользователем сети IP-телефонии в мультисервисной сети, использующей Softswitch и транспортную сеть с технологией IP/MPLS.
Рассмотрим случай, когда нужно связать двух пользователей, один из которых является абонентом ССОП, а второй – пользователем сети IP-телефонии. Пусть инициатором соединения будет VoIP-пользователь (абонент А), а сеть IP-телефонии использует протокол Н.323.
С помощью сообщения Setup протокола сигнализации H.225.0 стека Н.323 абонент А сообщает узлу Softswitch номер абонента ССОП (абонента Б). Softswitch должен определить местонахождение вызываемого абонента и, так как это абонент ССОП, найти ближайший к нему шлюз VoIP.
Рисунок 4. Пример установления соединения абонента ССОП с пользователем сети IP-телефонии в мультисервисной сети, использующей Softswitch и транспортную сеть с технологией IP/MPLS
Терминал абонента А с помощью протокола RSVP запрашивает у маршрутизатора MPLS и получает в сети доступа требуемые ресурсы связи, необходимые ему для гарантированной передачи речевой информации в реальном масштабе времени с соответствующим качеством доставки информации.
Терминал абонента А далеко не всегда имеет прямой доступ к сети MPLS. Доступ к ней может обеспечиваться через Internet общего пользования, которая не обеспечивает гарантированного качества доставки информации. Поэтому в сети доступа необходимо использовать протокол RSVP.
Если в ССОП/ISDN используется система сигнализации ОКС №7, Softswitch посылает сигнальное сообщение IAM (начальное адресное сообщение) в сторону вызываемой станции (которая может находиться в зоне действия другого Softswitch, и тогда сначала сообщениями протокола SIP будут обмениваться узлы Softswitch, а уже потом сообщение IAM будет транслироваться на АТС вызываемого абонента).
Получив от вызываемой станции сообщение ANM об ответе вызываемого абонента, Softswitch транслирует это сообщение в сторону вызывающего абонента А.
Между шлюзом VoIP, который был найден узлом Softswitch, и ближайшим к нему маршрутизатором MPLS устанавливается RSVP-соединение.
Так образуется цепочка: VoIP терминал – маршрутизаторы домена IP/MPLS – шлюз VoIP – АТС – терминал ССОП, и на всем ее протяжении действуют механизмы обеспечения гарантированного качества доставки информации.
Затем начинается передача речевой информации между абонентами через IP-сеть с использованием протоколов RTP/RTCP.
После завершения сеанса соединение разрушается. Для этого абоненты (абонент А взаимодействует с Softswitch, а абонент Б - с АТС) информируют об окончании разговора, после чего резервирование ресурсов протоколом RSVP отменяется.
Предложенный симбиоз технологий MPLS и RSVP пока не может решить проблемы характерного для IP-сетей негарантированного режима доставки информации, применение которого будет негативно влиять на абонентов телефонной сети, которые привыкли к норме потерь по вызовам порядка 3-5 процентов и к малым задержкам в получении сигнала "ответ станции".