Способ установления двунаправленного соединения

Способ установления двунаправленного соединения

Иллюстрации

Показать все

Реферат

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

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

Технологии коммутации по меткам IP/MPLS и GMPLS были разработаны для обеспечения единообразного контроля над сетями, для которых плоскость данных использует разные протоколы и/или технологии физического уровня, и для выполнения передового проектирования потоков обмена с использованием плоскости управления IP. В частности, резервирование ресурсов посредством сообщений сигнализации, например с использованием протокола RSVP или RSVP-TE, предусматривает средство установки соединений или виртуальных цепей с контролем по характеристикам исходя из показателей качества обслуживания или других.

В соответствии с Рабочими предложениями 3471, узел-инициатор обозначает хост-узел RSVP, способный к запуску установки тракта с коммутацией по меткам (LSP) сообщением PATH (ТРАКТ), а окончательный узел обозначает хост-узел RSVP, который может формировать противоположный конец LSP и отвечает на сообщение PATH сообщением RESV (РЕЗЕРВ).

В контексте семейства GMPLS, разработанном IETF, двунаправленное соединение может устанавливаться либо в виде двух независимых однонаправленных соединений или в виде симметричного двунаправленного соединения. Эта вторая возможность обладает преимуществами, описанными в разделе 4 Рабочих предложений 3471, опубликованных IETF.

Было бы желательно быть способным извлекать пользу от по меньшей мере некоторых из этих преимуществ для установки несимметричного соединения. Такая попытка была сделана Дубе и Костой в предложении, представленном на рассмотрение в IETF в ноябре 2002 года, «Двунаправленные LSP для классического MPLS». Кроме семантических проблем, это предложение не дает удовлетворительного решения вследствие обязанности, навязанной хост-узлам RSVP, эффективно резервировать ресурсы связи для восходящего потока перед отправкой сообщения PATH в оконечный узел. Результатом является относительно высокий риск, что попытка установить двунаправленный LSP будет претерпевать неудачу, например, в ситуациях, в которых доступность ресурсов недостаточна, несбалансированной нагрузки на узлы сети или разнородности узлов коммутации или маршрутизаторов. Если она претерпевает неудачу, процедура резервирования должна повторно запускаться с начала, что привносит время ожидания и неэффективно расходует ресурсы плоскости планирования.

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

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

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

отправки сообщения открытого соединения, содержащего первый дескриптор трафика и второй дескриптор трафика, из узла-инициатора в оконечный узел по тракту соединения в упомянутой сети, приема упомянутого сообщения открытого соединения в промежуточном узле в тракте соединения,

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

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

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

и резервирования ресурсов связи для нисходящего потока в качестве функции третьего дескриптора трафика и ресурсов связи для восходящего трафика в качестве функции четвертого дескриптора трафика по тракту соединения.

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

Преимущественно промежуточный узел обновляет сообщение открытого соединения, выделенное под характеристики тракта соединения, в качестве функции упомянутых доступных ресурсов связи. Например, эта часть содержит объект ADSPEC и/или U_ADSPEC.

Согласно еще одному конкретному варианту осуществления промежуточный узел обновляет упомянутое сообщение открытого соединения добавлением информации об упомянутых доступных ресурсах связи. Например, эта информация может включать в себя список меток, обозначающих доступные ресурсы, в частности в виде объекта LABEL SET (НАБОР МЕТОК) или UPSTREAM LABEL SET (НАБОР МЕТОК ВОСХОДЯЩЕГО ПОТОКА).

Предпочтительно сообщение открытого соединения является сообщением PATH в семействе протоколов RSVP, а сообщение резервирования является сообщением RESV в семействе протоколов RSVP.

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

подготовки резервирования первых ресурсов связи промежуточного узла для упомянутого восходящего потока в качестве функции упомянутого первого дескриптора трафика и доступности ресурсов связи промежуточного узла для упомянутого соединения,

подготовки резервирования вторых ресурсов связи промежуточного узла для упомянутого нисходящего потока в качестве функции упомянутого второго дескриптора трафика и доступности ресурсов связи промежуточного узла для упомянутого соединения.

Изобретение также обеспечивает устройство связи для сети связи с плоскостью управления IP, содержащее:

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

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

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

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

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

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

Фиг.1 представляет этапы в способе для установки двунаправленного LSP согласно одному из вариантов осуществления изобретения.

Фиг.2 - краткое представление сообщения PATH, используемого в способе по Фиг.1.

Фиг.3 - примерный дескриптор трафика, используемый в сообщении по Фиг.2.

Фиг.4 - краткое представление сообщения RESV, используемого в способе по Фиг.1.

Фиг.5 - примерный дескриптор трафика, используемый в сообщении по Фиг.4.

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

Фиг.7 - пример дескриптора тракта соединения, используемый в сообщении по Фиг.2.

Фиг.8 - функциональная схема маршрутизатора IP/MPLS согласно одному варианту осуществления изобретения.

Фиг.1 схематично показывает три узла A, B и C в сети с плоскостью управления IP/MPLS или GMPLS. Например, узлы A, B и C являются маршрутизаторами IP/MPLS. Характер линий связи и физических интерфейсов между узлами может быть произвольным. Топология и протяженность сети может быть произвольной, в частности количество промежуточных узлов может быть большим или меньшим, чем показанное на Фиг.1.

Далее будет описано, каким образом следует устанавливать двунаправленный LSP для сеанса связи между узлами A и C, в качестве примера. Предполагается, что контроллер сигнализации (хост-узел RSVP) узла A принял запрос для установки двунаправленного соединения с узлом C, например, от приложения или из системы администрирования сети. Контроллер маршрутизации рассчитал маршрут для этого соединения с использованием способов маршрутизации, которые не будут описываться в материалах настоящей заявки. Рассчитанный маршрут проходит через узел B. Линии в таблице на Фиг.1 представляют передачи следующих одно за другим сообщений сигнализации, чтобы установить это соединение.

На этапе 10 контроллер сигнализации узла A определяет характеристики соединения, которое должно быть установлено в нисходящем направлении, которое означает передачу из A в C, и в восходящем направлении, которое означает передачу из C в A. Эти характеристики независимо обрабатываются контроллерами сигнализации, а потому могут быть идентичными для установления симметричного соединения или разными, чтобы установить несимметричное соединение. Например, эти характеристики могут задаваться приложением или системой администрирования сети, которая запрашивает соединение. Начиная с этих характеристик, контроллер сигнализации узла A формирует объект SENDER_TSPEC, который является дескриптором трафика для нисходящего потока, и объект U_TSPEC, который является дескриптором трафика для восходящего потока. Эти дескрипторы трафика формируют описание, на более или менее детализированном уровне, ресурсов, которые контроллер сигнализации узла A желал бы видеть назначенными соединению в каждом направлении. Контроллер сигнализации узла A затем формирует сигнальное сообщение PATH, содержащее два этих объекта среди прочего, и отправляет его на следующий транзитный участок, которым в этом случае является узел B, на этапе 15.

Фиг.2 дает пример формата, который может использоваться для сообщения PATH. Квадратные скобки обозначают необязательные объекты. Кроме объектов U_TSPEC и U_ADSPEC, этот формат соответствует RFC 3473. Объекты ADSPEC и U_ADSPEC являются дескрипторами тракта соединения, которые устанавливаются и обновляются узлами, обрабатывающими сообщение PATH с тем, чтобы задавать характеристики элементов, формирующих тракт соединения, как пояснено в RFC 2210. В этом случае объект ADSPEC выделен под характеристики тракта соединения в нисходящем направлении, а объект U_ADSPEC выделен под характеристики тракта соединения в восходящем направлении.

Фиг.3 показывает примерный формат, который может использоваться для объектов SENDER_TSPEC и U_TSPEC. Этот формат соответствует сети пакетного типа, в которой качество обслуживания управляется в пределах инфраструктуры, определенной RFC 2210. Содержимое дескрипторов трафика зависит от характера нижних уровней сети. Другие параметры трафика могут использоваться в зависимости от возможностей, предоставляемых сетью. Например, RFC 3946 определяет параметры трафика для физического уровня SONET/SDH. Предложение «Параметры трафика сети Ethernet MEF», представленное к рассмотрению Пападимитрио в IETF в апреле 2006 года, определяет параметры трафика для сети Ethernet. На Фиг.1 значение параметров трафика, переносимое в сообщениях сигнализации, символически показано поперечником 11 сечения прохода для нисходящего соединения и поперечником 12 сечения прохода для восходящего соединения.

Фиг.7 дает пример формата, который может использоваться для объектов ADSPEC и U_ADSPEC. Этот формат соответствует сети пакетного типа, в которой качество обслуживания управляется в пределах инфраструктуры, определенной RFC 2210. Содержимое дескрипторов тракта соединения также может обновляться в зависимости от характера нижних уровней сети.

На этапе 20 контроллер сигнализации узла B принимает сообщение PATH и обрабатывает его содержимое с использованием стандартных процедур, в частности создавая запись в таблице, названной Блок состояний тракта. Более того, дескрипторы трафика SENDER_TSPEC и U_TSPEC пересылаются в контроллер доступа узла B, который проверяет, достаточны ли ресурсы связи узла в каждом направлении для установки соединения с требуемыми характеристиками.

Если доступные ресурсы соответствуют запрошенным характеристикам в одном направлении, контроллер доступа предварительно резервирует эти ресурсы в плоскости управления, так что они не могут считаться доступными для последующих запросов соединения. Однако эти ресурсы не выделяются в плоскости данных до тех пор, пока узел не принимает сообщение резервирования RESV, соответствующее сообщению PATH. Например, это означает, что физические коммутации в узле или преимущественное право на ресурсы, которые в настоящее время используются для потока с более низким приоритетом, чем запрошенное новое соединение, не реализуются до тех пор, пока не принимается сообщение резервирования RESV. Ресурсы связи, предварительно зарезервированные в плоскости управления, символически представлены на Фиг.1 проходом, очерченным пунктирной линией. Ресурсы связи, выделенные в плоскости данных, символически показаны на Фиг.1 проходом, очерченным сплошной линией. Стрелка указывает направление передачи, рассматриваемое в каждом случае.

Контроллер сигнализации узла B обновляет содержимое сигнального сообщения PATH и отправляет его на следующий транзитный участок, которым в этом случае является узел C, на этапе 25. В сообщении PATH объект UPSTREAM_LABEL обновляется узлом B, чтобы задать интерфейс, который он желает использовать для восходящего потока. В примере на Фиг.1 доступные ресурсы предполагаются достаточными в двух направлениях. Например, параметры 11 и 12 трафика, несомые в сигнальном сообщении, могут быть неизменными. Если используются объекты ADSPEC и U_ADSPEC, контроллер сигнализации узла B обновляет их содержимое в качестве функции характеристик узла, например, в показателях времени ожидания, полосы пропускания или коэффициента готовности службы.

Если доступные ресурсы не способны к достижению характеристик трафика, запрошенных в одном направлении, контроллер доступа предварительно резервирует ресурсы в пределах их доступности. Этот случай будет описан со ссылкой на Фиг.6.

На этапе 30 контроллер сигнализации оконечного узла C принимает сообщение PATH и обрабатывает его содержимое с использованием стандартных процедур, в частности создавая запись в таблице, названной Блок состояний тракта. Дескрипторы трафика SENDER_TSPEC и U_TSPEC и, возможно, дескрипторы тракта соединения ADSPEC и U_ADSPEC пересылаются в контроллер доступа узла C.

На этапе 35 контроллер доступа проверяет, во-первых, достаточны ли ресурсы связи узла C для установки соединения с характеристиками, заданными дескрипторами трафика, а во-вторых, если применимо, достаточны ли характеристики тракта соединения в каждом направлении для установки соединения с характеристиками, заданными дескрипторами трафика.

Если характеристики тракта соединения, а также доступные ресурсы узла C соответствуют запрошенным характеристикам в одном направлении, контроллер доступа эффективно резервирует эти ресурсы, также выделяя эти ресурсы в плоскости данных.

Если характеристики тракта соединения или доступные ресурсы узла C не достаточны для достижения запрошенных характеристик трафика в одном направлении, контроллер доступа определяет наиболее ограничивающие характеристики и резервирует ресурсы узла C в пределах характеристик соединения, которые могут эффективно устанавливаться в каждом направлении.

Другими словами, контроллер доступа узла C определяет характеристики соединения, которые могут эффективно устанавливаться в каждом направлении, в качестве функции информации, содержащейся в сообщении PATH, в частности, двух дескрипторов трафика SENDER_TSPEC и U_TSPEC и дескрипторов тракта соединения ADSPEC и U_ADSPEC, если применимо, и доступных ресурсов на узле C, и он пересылает соответствующую информацию в контроллер сигнализации. Контроллер сигнализации узла C использует эту информацию для формирования объекта FLOWSPEC, который является дескриптором трафика для нисходящего потока, и объекта U_FLOWSPEC, который является дескриптором трафика для восходящего потока. Эти дескрипторы трафика формируют описание ресурсов, которые контроллер доступа узла C решил выделить на соединение в каждом направлении. Эти дескрипторы трафика могут совпадать со значениями параметров, содержащихся в объектах SENDER_TSPEC и U_TSPEC, или они могут быть отличными. В частности, они могут задавать параметры трафика на уровне, более низком, чем изначально запрошенный узлом-инициатором, например, в показателях потока данных.

Контроллер сигнализации узла C затем формирует сообщение сигнализации RESV, включающее в себя два этих объекта среди прочего, и отправляет его на следующий транзитный участок, которым в этом случае является узел B, на этапе 40. В примере, показанном на Фиг.1, доступные ресурсы предполагаются достаточными в обоих направлениях. Параметры 31 и 32 трафика, несомые дескрипторами трафика сообщения RESV, например, могут быть идентичными заданным в сообщении PATH. Сообщение RESV также используется для распространения меток, обозначающих интерфейсы, которые должны использоваться узлами для соединения в каждом направлении.

Фиг.4 показывает примерный формат, который может использоваться для сообщения RESV. Кроме объектов U_FLOWSPEC и U_F1LTER_SPEC, этот формат соответствует RFC 3473. Объект FILTER_SPEC и объект U_FILTER_SPEC определяют подмножество пакетов сеанса связи в восходящем и нисходящем направлениях соответственно, которое может извлекать пользу из характеристик, заданных в дескрипторах FLOWSPEC и U_FLOWSPEC соответственно.

Фиг.5 показывает примерный формат, который может использоваться для объектов FLOWSPEC и U_FLOWSPEC. Этот формат соответствует сети пакетного типа, в которой качество обслуживания управляется в пределах инфраструктуры, определенной RFC 2210.

На этапе 45 контроллер сигнализации промежуточного узла B принимает сообщение RESV и обрабатывает его содержимое. Контроллер сигнализации обновляет таблицы коммутации в качестве функции принятых меток. Дескрипторы трафика FLOWSPEC и U_FLOWSPEC пересылаются в контроллер доступа узла C, который определяет резервирование ресурсов и их выделение в плоскости данных в соответствии со значениями параметров трафика, несомых в дескрипторах трафика. Таким образом, количество зарезервированных ресурсов может быть равным или меньшим, чем количество предварительно зарезервированных ресурсов. Поэтому предварительно зарезервированный ресурс освобождается, если не обязательно устанавливать соединение в соответствии с дескриптором трафика FLOWSPEC или U_FLOWSPEC.

Контроллер сигнализации узла B затем обновляет содержимое сообщения сигнализации RESV и отправляет его на следующий транзитный участок, которым в этом случае является узел-инициатор A, на этапе 50.

На этапе 55 контроллер сигнализации узла-инициатора A принимает сообщение RESV и обрабатывает его содержимое. Контроллер сигнализации обновляет таблицы коммутации в качестве функции принятых меток. Дескрипторы трафика FLOWSPEC и U_FLOWSPEC пересылаются в контроллер доступа узла C, который определяет резервирование ресурсов и их выделение в плоскости данных в соответствии со значениями параметров трафика, несомых в дескрипторах трафика. Таким образом, количество зарезервированных ресурсов может быть равным или меньшим, чем количество предварительно зарезервированных ресурсов в момент времени, в который было отправлено сообщение PATH. Поэтому предварительно зарезервированный ресурс освобождается, если не обязательно устанавливать соединение в соответствии с дескриптором трафика FLOWSPEC или U_FLOWSPEC.

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

Со ссылкой на Фиг.6 далее будет описан случай, в котором характеристики трафика, запрошенные узлом-инициатором, не могут быть удовлетворены сетью. Такие же номера ссылок, как на Фиг.1, используются для обозначения идентичных или эквивалентных этапов. В этом случае на этапе 20 контроллер доступа узла B обнаруживает, что доступные ресурсы не могут удовлетворить запрошенные характеристики трафика в по меньшей мере одном направлении, например в восходящем направлении. Контроллер доступа повторно оценивает допустимые характеристики трафика в восходящем направлении в качестве функции фактически доступных ресурсов связи в узле B, производит соответствующее предварительное резервирование и пересылает соответствующую информацию в контроллер сигнализации узла B.

Согласно первому варианту осуществления контроллер сигнализации узла B способен к обновлению дескрипторов трафика в сообщении PATH в качестве функции информации, предоставленной контроллером доступа, о доступных ресурсах связи. Поэтому сообщение PATH отправляется на следующем транзитном участке с одним или несколькими модифицированными параметрами 21 и 22 трафика, по меньшей мере для одного направления связи, а именно модифицированными параметрами, содержащимися в объекте U_TSPEC, в этом примере. Оставшаяся часть процедуры в таком случае является такой же, как в предыдущем описании. Таким образом, если оконечный узел C не вводит никаких дополнительных ограничений, дескрипторы трафика в сообщении RESV будут иметь такие же значения параметров, как в сообщении PATH, как указано стрелками 31 и 32. Этот вариант осуществления может выполняться с использованием необязательных объектов или без использования их. Во всех случаях ограничения каждого промежуточного узла B используются для определения характеристик соединения, которые должны быть установлены в каждом направлении из условия, чтобы вероятность благоприятного исхода была лучшей, чем с более жесткими способами согласно предшествующему уровню техники. Этот вариант осуществления не мешает контроллеру доступа оконечного узла C в заключение быть способным помещать параметры потока со значениями, отличными от переданных промежуточным узлом B, в сообщение RESV, как пояснено выше.

Согласно второму варианту осуществления контроллер сигнализации узла B не способен к обновлению дескрипторов трафика SENDER_TSPEC и U_TSPEC в сообщении PATH. В этом случае информация, выдаваемая контроллером доступа, о доступных ресурсах связи пересылается на следующем транзитном участке в качестве характеристик тракта соединения в объекте ADSPEC или U_ADSPEC, так что они могут использоваться контроллером доступа оконечного узла C во время определения дескриптора трафика FLOWSPEC или U_FLOWSPEC.

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

Параметры, содержащиеся в объектах U_TSPEC, U_ADSPEC и U_FLOWSPEC, могут быть идентичными, например, смотрите Фиг.3 и 5, или они могут быть разными, например, смотрите Фиг.5 и 7. Контроллер доступа оконечного узла C способен к осуществлению необходимых расчетов и преобразований для формулирования параметров трафика в формате дескриптора трафика U_FLOWSPEC, зависящего от параметров трафика, принятых в формате дескриптора трафика U_TSPEC, и характеристик тракта соединения, принятых в формате дескриптора тракта соединения U_ADSPEC. Такое же замечание применимо для объектов, ассоциативно связанных с нисходящим направлением.

Двунаправленный характер запроса установления соединения предпочтительно сообщается наличием объекта UPSTREAM_LABEL в сообщении PATH. Преимущественно объект UPSTREAM_LABEL_SET также используется для дополнительного улучшения вероятности благоприятного исхода запроса, как описано в публикации Ейджи Оки и других, IEICE TRANS. COMMUN., том E87-B, № 6, июнь 2004 года.

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

Фиг.8 показывает пример функциональной архитектуры маршрутизатора IP/MPLS или GMPLS для создания узлов A, B и C. Маршрутизатор 60 содержит контроллер 61 сигнализации, поддерживающий связь с другими элементами сети через каналы 66 управления, контроллер 62 маршрутизации, контроллер 63 доступа и контроллер 64 трафика, поддерживающий связь с другими элементами сети через каналы 65 данных. Контроллер 64 трафика ответственен за передачу пакетов данных в качестве функции меток. Канал 65 данных и канал 66 управления могут быть надстроены над общим или раздельных интерфейсах.

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

Полученная несимметричность соединения может применяться к полосе пропускания, технологии коммутации, технологии кодирования данных или другим характеристикам соединения.

Способы, описанные выше, основаны на протоколе RSVP-TE. Однако они могли бы использоваться с другими протоколами сигнализации с эквивалентными функциями.

Некоторые из описанных элементов, в частности контроллеры сигнализации, маршрутизации и доступа, могут быть произведены в разных формах, единой или распределенной, с использованием компонентов аппаратных средств и/или программного обеспечения. Компоненты аппаратных средств, которые могут использоваться, включают в себя специализированные интегральные схемы, ASIC, программируемые пользователем логические схемы, FPGA, или микропроцессоры. Компоненты программного обеспечения могут быть написаны на разных языках программирования, например C, C++, Java или VHDL. Этот перечень не является исчерпывающим. Несколько контроллеров могут быть представлены одиночным элементом аппаратных средств.

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

Ресурсы связи обычно охватывают все физические или логические элементы, которые могут быть пущены в обращение сетью для передачи трафика. В зависимости от характера физических уровней и уровней управления для доступа к поддержке MAC в узлах, в частности, ресурсы связи могут обозначать элементы, такие как такт ЦПУ, пространство памяти, регистры, логические или физические порты, радио- или оптические каналы, временные интервалы и прочее.

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

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

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

1. Способ установления двунаправленного соединения между узлом-инициатором (А) и оконечным узлом (С) в сети связи с плоскостью управления Интернет-протокола (IP), содержащий этапы, на которых:создают первый дескриптор (11) трафика, содержащий параметры трафика для нисходящего потока данных, который должен передаваться узлом-инициатором в оконечный узел, и второй дескриптор (12) трафика, содержащий параметры трафика для восходящего потока данных, который должен приниматься узлом-инициатором из оконечного узла,отправляют (15) сообщение открытого соединения, содержащее первый дескриптор трафика и второй дескриптор трафика, из узла-инициатора в оконечный узел по тракту соединения в упомянутой сети,принимают (20) упомянутое сообщение открытого соединения на промежуточном узле (В) по тракту соединения,оценивают ресурсы связи промежуточного узла, доступные для упомянутого нисходящего потока и упомянутого восходящего потока,обновляют содержимое упомянутого сообщения открытого соединения в качестве функции упомянутых доступных ресурсов связи и передают (25) упомянутое обновленное сообщение открытого соединения из промежуточного узла в оконечный узел по тракту соединения,принимают (30) упомянутое сообщение открытого соединения на оконечном узле, создают третий дескриптор (31) трафика, содержащий параметры трафика для упомянутого нисходящего потока, и четвертый дескриптор (32) трафика, содержащий параметры трафика для упомянутого восходящего потока, зависящие от содержимого обновленного сообщения открытого соединения, и отправляют (40) сообщение резервирования, содержащее третий дескриптор трафика и четвертый дескриптор трафика, из оконечного узла в узел-инициатор по тракту соединения,и резервируют (35, 45) ресурсы связи для нисходящего потока в качестве функции третьего дескриптора трафика и ресурсы связи для восходящего потока в качестве функции четвертого дескриптора трафика по тракту соединения.

2. Способ по п.1, отличающийся тем, что промежуточный узел обновляет по меньшей мере первый или второй дескриптор (21, 22) трафика в зависимости от упомянутых доступных ресурсов связи.

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

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

5. Способ по п.1, отличающийся тем, что сообщение открытого соединения является сообщением PATH (ТРАКТ) в семействе протоколов резервирования сетевых ресурсов (RSVP), а сообщение резервирования является сообщением RESV (РЕЗЕРВ) в семействе протоколов RSVP.

6. Способ по п.1, отличающийся тем, что промежуточный узел (В), принимающий сообщение открытого соединения, выполняет этапы, на которых: подготавливают (20) резервирование первых ресурсов связи промежуточного узла для упомянутого нисходящего потока в качестве функции упомянутого первого дескриптора трафика и доступности ресурсов связи промежуточного узла для упомянутого соединения, подготавливают (20) резервирование вторых ресурсов связи промежуточного узла для упомянутого нисходящего потока в качестве функции упомянутого второго дескриптора трафика и доступности ресурсов связи промежуточного узла для упомянутого соедине