Сценарии доставки сообщений.

не ориентированный на соединение/исходящий пункт. Первое сообщение от пользователя передается по цепочке USER-SCМР-SCRT-SCMP-USER-SCMP-MTP. Пользователь первоначально выдает в SCMP адрес в виде GT. В результате пересчета в SCRT получается значение DPC первого транзитного узла SCCP, которое возвращается пользователю. Пользователь запоминает пересчитанный адрес. Это сделано во избежание пересчета GT для каждого сообщения. Остальные сообщения передаются по цепочке USER-SCMP-MTP. Все сообщения, передаваемые в МТР содержат, как GT, так и DPC.

ориентированный на соединение/исходящий пункт. Последовательность взаимодействия для первого сообщения следующая: USER-SСМР-SCRТ-SCМР-MTP. Пользователь, обращаясь первый раз к SCCP примитивом N-CONNECT REQUEST, выдает в качестве параметра ссылку, позволяющую ему в дальнейшем идентифицировать устанавливаемое соединение. Эта ссылка будет использована SCCP при обращении к пользователю (в обратном направлении). Для установления виртуального соединения SCMP выделяет управляющий буфер соединения (ССВ), в который записывается эта ссылка. Идентификатор ССВ сам используется как ссылка, но уже для установления соединения со следующим (транзитным или оконечным) узлом. Он включается в сообщение ЗАПРОС СОЕДИНЕНИЯ (CR). Со следующего узла в результате установления соединения должно поступить сообщение ПОДТВЕРЖДЕНИЕ СОЕДИНЕНИЯ, содержащее данную ссылку на наш ССВ и удаленную ссылку на собственный ССВ. Последняя  записывается в наш ССВ и будет использоваться  вместо адреса в процессе передачи данных по данному соединению. После установления соединения используется фиксированный путь (последовательность ссылок), поэтому сценарий взаимодействий может быть упрощен USER-SCМР-MTP.

ориентированный на соединение/промежуточный пункт. Последовательность взаимодействий на промежуточном пункте при обработке сообщения ЗАПРОС СОЕДИНЕНИЯ выглядит следующим образом MTP1-SCMP-SCRT-MTP3 (рис. 123 — 125). Получив это сообщение из МТР, SCMP выделяет для него ССВ, в который записывает удаленную  ссылку, содержащуюся в принятом сообщении. Далее с помощью SCRT пересчитывается GT, полученный в составе сообщения. Результатом пересчета является DPC (и SSF) следующего узла SCCP. Если следующий пункт будет оконечным, то дополнительно может быть получен SSN пользователя, которому данное сообщение адресовано. Для установления следующего этапа соединения  SCCP выделяет еще один ССВ в который записывает ссылку на ССВ входящей стороны. Идентификатор этого нового ССВ будет включен в сообщение ЗАПРОС СОЕДИНЕНИЯ, которое  передается через МТР к следующему узлу SCCP. В ответ от него должно быть получено сообщение ПОДТВЕРЖДЕНИЕ СОЕДИНЕНИЯ, содержащее две ссылки. Первая — локальная — укажет нам ССВ исходящей стороны к которому относится сообщение, вторая — удаленная — должна быть записана в этот ССВ, для использования далее в качестве адреса при передаче сообщений данных на следующий узел. Кроме того, из данного ССВ мы извлечем, ранее записанную туда ссылку на ССВ входящей стороны. По этой ссылке мы найдем соответствующий ССВ и запишем в него в качестве ссылки идентификатор ССВ исходящей стороны. Таким образом, ССВ на двух сторонах соединения окажутся связанными взаимными ссылками. При передаче последующих сообщений будет работать только SCMP, имеющая для этого всю необходимую информацию. Последовательность взаимодействия, таким образом, MTP-SCMP-MTP.

не ориентированный на соединение / промежуточный пункт. Для единичного сообщения последовательность взаимодействия выглядит следующим образом MTP1-SCMP-SCRT-SCMP-MTP2 (рис. 126).

Установленное виртуальное соединение в течение времени его существования поддерживается и обслуживается OSI-CE. Идентификатор этого СЕ включается в локальную ссылку соединения, объявляемую как локальная ссылка на источник в сообщениях CR (запрос соединения — исходящее) и СС (завершение установления соединения — входящее), используемых для установления соединения.

Ссылка на основную публикацию
Adblock detector