Обмен оам эхо-сообщениями для проверки сетевого маршрута распространения, основанного на услуге

Обмен оам эхо-сообщениями для проверки сетевого маршрута распространения, основанного на услуге

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА СВЯЗАННЫЕ ПАТЕНТНЫЕ ЗАЯВКИ

Эта заявка притязает на приоритет патентной заявки США № 60/466248, озаглавленной "Echo messaging to Verify Service-based Network Distribution Paths", поданной 28 апреля 2003 г., которая включена здесь посредством ссылки во всей ее полноте.

Эта заявка связана с находящейся на одновременном рассмотрении патентной заявкой США № 10/833489 (номер дела патентного поверенного № 137797), озаглавленной "Using Network Transport Tunnels To Provide Service-Based Data Transport", поданной совместно с настоящей заявкой, и притязает на приоритет предварительной патентной заявки США № 60/466340, озаглавленной "Using Network Transport Tunnels To Provide Service-Based Distribution Path", поданной 28 апреля 2003, которая включена в настоящее описание посредством ссылки во всей ее полноте.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

ПЕРЕЧЕНЬ ФИГУР ЧЕРТЕЖЕЙ

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

Фиг.1 - иллюстративная система для привязки услуг к маршрутам с коммутацией по меткам;

Фиг.2А - иллюстративная система для использования транспортных туннелей, привязанных к маршрутам распространения, основанным на услуге;

Фиг.2B - иллюстративный маршрут распространения, основанный на услуге, включая ассоциированные транспортные туннели;

Фиг.3 - иллюстративная система, имеющая однонаправленные транспортные туннели, соединяющие конечные точки по сети.

Фиг.4 - иллюстративный формат OAM сообщения;

Фиг.5A - иллюстрация процесса определения действующей услуги, в соответствии с вариантом реализации;

Фиг.5B - иллюстрация дополнительного процесса проверки сообщения эхо-ответа, в соответствии с вариантом реализации;

Фиг.6 - иллюстрация процесса для OAM эхо-сообщения для проверки маршрута распространения, основанного на услуге, в соответствии с вариантом реализации; и

Фиг.7 - иллюстрация процесса обмена OAM эхо-сообщениями для проверки услуги на маршруте распространения, основанном на услуге, в соответствии с вариантом реализации.

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

Межсетевой обмен и передача данных по одной или более сетям может потребовать множества протоколов или методик для передачи пакетов между конечными точками, такими как межсетевые граничные маршрутизаторы, выполненные с возможностью межсетевого взаимодействия. Конечные точки, такие как граничные маршрутизаторы сети провайдера (PE маршрутизаторы), граничные маршрутизаторы услуг (ESR) или граничные маршрутизаторы меток (LER) могут использовать транспортный туннель, например, маршрут распространения, основанный на услуге, (SDP) для транспортировки данных маршрутизаторам стороны клиента (CE) нисходящего потока и конечным адресатам информации (например, адресам протокола управления доступа к среде (MAC адресам)). Маршрут распространения, основанный на услуге, может быть также пунктом распространения услуги и одним или более ассоциированными транспортными туннелями. SDP маршруты могут быть установлены с использованием различных протоколов, таких как услуга мультипротокольной маршрутизации по меткам (MPLS), MPLS-Traffic Engineering (MPLS-TE), IP или другие типы протоколов общей инкапсуляции при маршрутизации (GRE протоколы), которые влияют на осуществление связи на уровнях 2 и 3. SDP маршруты могут быть реализованы как транспортные туннели (например, однонаправленные, двунаправленные, всенаправленные) между конечными точками для обеспечения транспортного туннеля для передачи пакета услуги. Тем не менее, в дополнение к транспортным возможностям, в SDP маршрутах могут поддерживаться OAM функции. В случае MPLS, маршруты с коммутацией по меткам (LSP) могут быть ассоциированы (как отдельные маршруты или как подмаршруты) с SDP маршрутами, которые в свою очередь могут иметь услугу или набор услуг, отображаемых на них или привязанных к ним. OAM функции запускаются с использованием SDP маршрутов, используя информацию, сгенерированную на основе обмена эхо-сообщениями, системы для обмена OAM сообщениями и сбора информации/данных. Вне зависимости от используемого базового протокола, SDP маршрут делает возможным улучшенные управление, мониторинг, конфигурирование услуги и возможности OAM.

Транспортный туннель (например, SDP маршрут, однонаправленный транспортный туннель и так далее) может иметь один или более маршрутов, ассоциированных с ним (например, множество LSP). SDP маршрут может включать в себя однонаправленные транспортные туннели или туннели других типов для передачи пакетов данных от множества услуг. Использование LSP маршрутов, таких как использованы в MPLS, может быть реализовано как отдельные маршруты в пределах определенного SDP, который маршрутизирует пакеты данных между местами назначения на ближнем и дальнем концах (например, ESR). Как только маршрут ассоциирован с транспортным туннелем, услуга отображается на соответствующий маршрут и транспортный туннель. После отображения может быть выполнена проверка в отношении операционного статуса услуги, SDP, маршрута и так далее. Проверка на действующие услугу и SDP маршрута может определить конфигурацию, возможность соединения, сквозное рабочее состояние SDP, нерабочий SDP, времена на передачу и подтверждение приема (RTT), характеристики полезной нагрузки или другую информацию о услуге или SDP, или другие OAM возможности.

OAM возможности могут быть реализованы в SDP с использованием обмена OAM сообщениями. Примером типа такого обмена является обмен OAM эхо-сообщениями. В общем случае, обмен OAM эхо-сообщениями может быть использован для высокоуровневой проверки того, что заданный SDP или идентификатор (ID) услуги (Service-ID) находятся в рабочем состоянии и образуют соединение между ESR маршрутизаторами. Форматы OAM эхо-сообщений включают запрос отклика (эхо-запрос) SDP и ответ на запрос отклика (эхо-ответ) SDP, эхо-запрос и эхо-ответ услуги, которые могут включать в себя различные поля заголовка для идентификации типа задачи, для выполнения которой предназначено конкретное сообщение.

Фиг.1 иллюстрирует систему для привязки услуг непосредственно к отдельным маршрутам с коммутацией по меткам. Услуги 102-106 посылают данные граничному маршрутизатору A сети провайдера (PE маршрутизатору) через LSP A 112, используя межпоточные коммутаторы (кросс-коммутаторы) (CC) 108, 116 и 120 соответственно. Услуги 102-106 посылают данные PE маршрутизатору B через LSP B 114, используя кросс-коммутаторы (CC) 110, 118 и 122 соответственно. Каждая услуга 102-106 индивидуально сконфигурирована с независимым кросс-коммутатором для каждого LSP. Может быть реализовано большее или меньшее количество кросс-коммутаторов и услуг, но когда используется множество услуг, управление, мониторинг и контроль могут стать значительно затруднены. Например, переключение на LSP 112 будет требовать, чтобы каждый из кросс-коммутаторов 108, 116, и 120 был переконфигурирован для отражения этого переключения. В упрощенном примере, показанном на Фиг.1, только три услуги (и ассоциированные с ними кросс-коммутаторы) должны быть переконфигурированы. Тем не менее, в характерной коммерческой реализации имеются тысячи услуг и десятки или более LSP. Кроме того, персонал, подготавливающий к работе услуги 102-106, должен знать определенную информацию о LSP 112 и 114, для того чтобы быть способным привязать услуги непосредственно к LSP маршрутам с помощью правильного конфигурирования кросс-маршрутизаторов, что требует, чтобы персонал, конфигурирующий услуги, имел знания о транспортных маршрутах (LSP), которые в других случаях ему необязательно иметь, тем самым, потенциально увеличивается обучение, наймы, зарплаты и другие издержки.

Фиг.2А - иллюстрация системы 200, в которой транспортные туннели, привязанные к маршрутам распространения, основанным на услуге, (SDP) используются для обеспечения основанной на услуге передачи сетевого трафика. Услуги 1-3, обозначенные 202-206 на Фиг.2А, привязаны модулем 208 отображения SDP к одному или более SDP 210-216. Хотя модуль 208 отображения SDP показан как единый блок на Фиг.2A, в некоторых вариантах реализации он может быть реализован как набор отдельных кросс-коммутаторов, привязывающих каждую услугу к одному или более из SDP 210-216. SDP 210-216 могут быть реализованы, как имеющие один или более транспортных туннелей (например, LSP), ассоциированных с каждым SDP. Транспортные туннели могут быть статическими или динамическими. В одной реализации, каждый SDP содержит пункт распространения для одного целевого (исходящего) PE маршрутизатора. Каждый SDP может иметь множество услуг, привязанных к нему или отображенных на него модулем 208 отображения SDP. В одном варианте реализации, входящий PE маршрутизатор может иметь более чем один SDP, ассоциированный с тем же самым целевым (исходящим) PE, но каждая услуга может быть привязана или отображена только на один SDP для каждого места назначения, для отправки данных к которому может быть сконфигурирована услуга. LSP являются одним примером типа транспортного туннеля, который может быть ассоциирован с SDP для передачи пакетов услуги по базовой сети MPLS. С другими типами базовых сетей или сетей, которые могут использовать другие базовые протоколы маршрутизации, могут быть использованы маршруты других типов. Вне зависимости от базового сетевого протокола, каждый SDP 210-216 может рассматриваться как пункт распространения, имеющий один или более ассоциированных транспортных туннелей, которые соединяют точку ближнего конца с точкой/местом назначения на дальнем конце, на которую одна или более услуг могут быть отображены для того, чтобы сделать возможной отправку пакетов услуг (или данных услуг в какой-либо другой форме) услугами к месту назначения, ассоциированному с SDP. Благодаря привязке услуг 202-206 к маршрутам SDP, вместо привязки услуг непосредственно к транспортным туннелям (например, LSP), как показано на Фиг.1, услуги 202-206 могут быть сконфигурированы независимо от транспортных туннелей, и наоборот, тем самым, упрощая подготовку к работе и/или повторное конфигурирование каждого из них. Например, если бы LSP в SDP 1 (210) был добавлен, удален или изменен, информация о LSP должна была бы быть модифицирована только один раз, в SDP. Услуги 202-206, которые находятся в системе 200 и привязаны SDP модулем 208 отображения SDP к SDP, но не привязаны непосредственно к транспортными туннелями, ассоциированным с SDP, не будут требовать никаких изменений. Аналогичным образом, услуги могут добавляться, удаляться или изменяться без требования того, чтобы множество кросс-коммутаторов к множеству LSP (или другим транспортным маршрутам) изменялось.

В одном варианте реализации, SDP имеет несколько атрибутов для обеспечения возможностей передачи данных, основанной на услуге. Примеры таких атрибутов включают в себя адрес (например, IP адрес) для места назначения на дальнем конце (например, PE или другого исходящего оборудования или узла), которое представляет собой конечную точку, к которой сетевой трафик, ассоциированный с услугой, может быть отправлен для дальнейшей доставки к клиентскому месту назначения, ассоциированному с услугой, тип инкапсуляции, используемый для передачи данных к месту назначения (например, GRE, MPLS, L2TP, и так далее), маршрут, используемый для достижения места назначения на дальнем конце (где применимо, например MPLS), и максимальный размер блока передачи (MTU) для маршрута. SDP обеспечивает возможности управления с использованием этих атрибутов, которые определяют то, как пакеты услуги (то есть, пакеты, передаваемые для реализации определенной услуги, такой как виртуальные выделенные линии (VLL) или услуги другого типа, предоставляемой производителем или поставщиком услуги, и так далее) передаются и обрабатываются на основе сквозного прохождения через сеть. SDP может быть использован для передачи пакетов, ассоциированных с одной услугой или с множеством услуг. При помощи группирования множества LSP или маршрутов в один транспортный туннель (SDP), нагрузка, связанная с пакетами услуги, может быть разделена между LSP маршрутами, составляющим SDP. Таким образом, пакеты могут распространяться по нескольким маршрутам для маршрутизации к конечному месту назначения услуги, вместо отправки пакетов для конкретной услуги по одному маршруту. Также может быть использован протокол для динамического мониторинга сквозного рабочего состояния SDP, обеспечивая возможность определения, изменилось ли рабочее состояние SDP, и если да, то на какие услуги это может повлиять. В качестве примера может быть реализован протокол контроля работоспособности ("keep alive"), который предоставляет определенные значения заголовка или информацию, которые при демультиплексировании могут быть использованы для функций эксплуатации, и управления и обслуживания (OAM).

Фиг.2B - иллюстративный маршрут распространения, основанный на услуге, включая ассоциированные транспортные туннели. SDP 230 показан, имеющим несколько LSP 232-240 (предполагая, что используется MPLS), ассоциированных с ним. В других примерах, в которых MPLS может не использоваться, могут быть использованы транспортные туннели, отличные от LSP. В целях иллюстрации, где используются MPLS или MPLS-TE, LSP 232-240 передают служебные пакеты между (входящим) маршрутизатором ближнего конца и одним или более (исходящими) маршрутизаторами дальнего конца, ассоциированными с SDP. На Фиг.2A и 2B SDP представлены графически как туннели, содержащие один или более компонентных транспортных туннелей, таких как LSP, для того, чтобы довести концепцию, что SDP обеспечивают путь для передачи данных через транспортные туннели, ассоциированные с ними, к месту назначения, ассоциированному с SDP. Должно быть понятно, что SDP фактически не представляют собой транспортные механизмы, отдельные от или организованные в виде уровней поверх транспортных туннелей, ассоциированных с ними, а наоборот, служат как пункт распространения, сконфигурированный для передачи пакетов данных, ассоциированных с услугами, привязанными к SDP, в место назначения, ассоциированное с SDP через транспортный туннель (например, LSP), ассоциированный с SDP. Установление и конфигурирование SDP будет описано более подробно ниже в связи с Фиг.3-Фиг.7.

Фиг.3 - иллюстративная система 300, имеющая однонаправленные транспортные туннели, соединяющие конечные точки по сети. Эта иллюстрация представляет собой более детальный пример системы, в которой SDP могут быть использованы для обеспечения передачи данных, основанной на услуге, по сети или серии сетей. Граничные маршрутизаторы 302 и 304 услуг (ESR) соединены через сеть 306. В этом примере сеть 306 проиллюстрирована как являющаяся базовой сетью IP/MPLS. В других вариантах реализации могут быть использованы другие типы базовой сети. CE 308-310 посылают пакеты, принятые от ESR 302 и 304 соответственно, к конечным местам назначения клиента, которым они адресованы, например, по MAC адресу в пределах их соответствующих клиентских сетей. CE 308 и 310 также принимают от ассоциированных клиентских узлов пакеты, которые должны быть переданы с помощью услуги 123 VLL, и доставляют такие пакеты к ESR 302 и 304 соответственно для передачи. Однонаправленные транспортные туннели 312 и 314 обеспечивают механизм транспортировки для передачи пакетов услуги и ассоциированы с SDP, показанными в этом примере. В одном варианте реализации, транспортный туннель 312 содержит LSP, ассоциированный с SDP 324, и транспортный туннель 314 содержит LSP, ассоциированный с SDP 326. Здесь услуга, такая как VLL, может быть реализована с использованием двунаправленных точек 316-318 доступа к услуге. В других реализациях, могут быть обеспечены другие типы услуг, например VPLS. Обмен пакетами услуги осуществляется между точками 316-318 доступа к услуге, и эти пакеты передаются по однонаправленным транспортным туннелям 312 и 314. В этом примере метки 320 и 322 виртуального канала (VC) применяются к пакетам услуги, исходящим от точек 316-318 доступа к услуге соответственно. SDP 324-326 пересылают пакеты услуги с присоединенными VC метками 320-322 через однонаправленные транспортные туннели 312 и 314 к ESR маршрутизаторам 302-304. После приема пакетов услуги с присоединенными впереди VC метками, демультиплексоры 328 и 330 идентифицируют пакеты услуги, как предназначенные для точек доступа 316 и 318 к услуге на основе VC меток 320-322, и маршрутизируют их соответственно.

В примере, показанном на Фиг.3, клиентский пакет, ассоциированный с VLL услугой 123, который отправляется источником, ассоциированным с CE 308, к месту назначения, ассоциированному с CE 310, например, будет отправлен CE 308 к ESR 302. ESR 302 примет пакет и ассоциирует пакет с VLL услугой 123 (например, на основе порта, по которому был принят пакет, использованной инкапсуляции, метки или другой идентифицирующей информации, включенной в пакет, и тому подобного). Точка 316 доступа к услуге перенаправит пакет SDP 324 (либо непосредственно согласно показанному варианту реализации, либо через модуль отображения SDP, не показанный на Фиг.3, но описанный выше в связи с Фиг.2А, например, в варианте реализации, в котором множество услуг используют один и тот же SDP) для передачи исходящему ESR 304. SDP 324 инкапсулирует пакет для передачи ESR 304 через однонаправленный транспортный туннель 312, включая вариант с помощью присоединения VC метки 320, которая идентифицирует пакет как пакет, ассоциированный со услугой 123. В варианте реализации, в котором SDP 324 содержит два или более транспортных туннелей к ESR 304, SDP 324 выбирает туннель, подлежащий использованию для передачи пакета к ESR 304. Например, в варианте реализации, в котором SDP 324 содержит два или более LSP, SDP 324 может быть сконфигурирован для привязки услуги к конкретному LSP, например VLL услуги, такой как VLL услуга 123, так, чтобы весь трафик для услуги отправлялся через один и тот же LSP. Для других типов услуг (например, VPLS или VPRN) SDP может отображать пакеты на LSP для передачи посредством ассоциирования пакета с «преобразованием» (то есть, осуществляется обмен соответствующим набором пакетов между двумя конечными точками) и выбрать LSP, ассоциированный с этим преобразованием (например, для предотвращения доставки пакетов в ненадлежащем порядке, как могло бы случиться, если бы различные пакеты, ассоциированные с преобразованием, передавались по различным маршрутам). В некоторых вариантах реализации, в которых обеспечиваются VPLS, VPRN или подобная услуга, MAC адрес места назначения может быть использован для идентификации LSP, подлежащего использованию для передачи пакета. Когда пакет прибывает на ESR 304, демультиплексор 330 идентифицирует пакет как пакет, ассоциированный с услугой 123, например, на основе присутствия VC метки 320, и доставляет исходный пакет (полезную нагрузку) точке 318 доступа к услуге для обработки. Точка 318 доступа к услуге, затем, доставляет пакет на CE 310.

Фиг.4 - иллюстративный формат OAM сообщения. В этом варианте реализации OAM сообщение 400 может содержать две секции, секцию 402 общего заголовка и секцию 404, характерную для конкретного сообщения. Секция 402 общего заголовка включает в себя поля, которые могут быть заполнены создателем или ответчиком эхо-сообщения. Примеры полей, которые могут быть включены в секцию 402 общего заголовка, включают в себя поля для идентификации версии используемой системы обмена OAM сообщениями, типа сообщения, длины сообщения, идентификатора сообщения, идентификационных данных создателя, идентификационных данных ответчика, идентификатора SDP, использованного создателем, идентификатора SDP, использованного ответчиком и/или ассоциированного ответчиком с услугой, и необязательную контрольную сумму. Другие поля могут быть использованы в этой или в других реализациях и не ограничиваются выше приведенными примерами.

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

В одном варианте реализации поле длины сообщения идентифицирует полную длину сообщения, включая секцию 402 общего заголовка и секцию 404, характерную для конкретного сообщения. Поле типа сообщения идентифицирует OAM сообщения по типу. В одном варианте реализации определены следующие типы: эхо-запрос SDP (отправляется SDP ближнего конца или входящим SDP месту назначения на дальнем конце, например, для проверки конфигурации и/или возможности соединения SDP); эхо-ответ SDP (для ответа на эхо-запрос SDP); эхо-запрос услуги (отправляется ESR ближнего конца или входящим ESR, например, для проверки конфигурации услуги на ближнем или дальнем конце); и эхо-ответ услуги (для ответа на эхо-запрос услуги). В этом примере сообщения типов, отличных от вышеперечисленных, отбрасываются. Тем не менее, в других вариантах реализации могут быть использованы другие типы сообщений. Идентификатор сообщения - это уникальный идентификатор (например, последовательность цифр), назначенный создателем сообщения. Примерные правила для назначения идентификатора сообщения описаны в предварительной патентной заявке США № 60/466340, поданной 28 апреля 2003.

Идентификатор создателя, включенный в поле идентификатора создателя секции 402 общего заголовка, может быть использован для аутентификации (удостоверения подлинности) принятого ответного сообщения. В качестве примера, ответчик на сообщение эхо-запроса не изменяет поле создателя, но заполняет сообщение эхо-ответа, которое включает в общий заголовок идентификатор создателя запроса. Ответчик может использовать идентификатор создателя для определения источника эхо-запроса, так как информация туннеля/SDP может быть не пригодной для использования для этой цели. Когда ответ должен быть отправлен через SDP создателю запроса, получатель эхо-запроса может использовать поле идентификатора создателя для поиска подходящего SDP, который будет использован в качестве ответного маршрута. Если ответное сообщение обобщенно инкапсулировано в IP/GRE, в противоположность отправке через SDP, как будет описано ниже со ссылкой на Фиг.5, идентификатор создателя может быть использован для определения IP адреса места назначения для создателя.

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

Формат секции 404, характерной для конкретного сообщения, зависит от типа отправляемого сообщения. В одном варианте реализации, если OAM сообщение 400 является сообщением эхо-запроса SDP или сообщением эхо-ответа SDP, секция 404, характерная для конкретного сообщения, содержит набор флагов создателя эхо-сообщения SDP, используемых создателем эхо-запроса (или создателем запроса, реакцией на который является ответ, в случае эхо-ответа) для предоставления информации о сообщении запроса и конфигурации SDP на стороне создателя, и набор флагов ответчика на эхо-сообщение SDP, используемых получателем сообщения запроса для обеспечения в ответном сообщении получателя информации о сообщении эхо-ответа SDP получателя и конфигурации SDP, которую получатель ассоциировал с создателем. Примеры флагов создателя эхо-сообщения SDP, используемых в одном варианте реализации, включают в себя флаги для обозначения того, содержат ли различные поля общего заголовка 402 действительные значения, флаги для информирования получателя запроса о рабочем и/или административном состоянии SDP создателя, идентифицируемого в общем заголовке, флаг, показывающий, был ли запрос отправлен с использованием SDP создателя, идентифицированного в общем заголовке (или, вместо этого, была ли использована обобщенная инкапсуляция IP/GRE, например), флаги для обозначения рабочего и/или административного состояния оборудования создателя, ассоциированного с идентификатором создателя, включенным в заголовок, и флаг, информирующий получателя запроса о том, должен ли получатель ответить на запрос через SDP получателя, идентифицированный в заголовке. Примеры флагов ответчика на SDP эхо-сообщение, используемые в одном варианте реализации, включают в себя флаги, используемые для информирования создателя о действительности или недействительности значений заголовка, включенных создателем в запрос, флаги для информирования создателя запроса о рабочем и/или административном состоянии SDP ответчика, идентифицируемого в общем заголовке, флаг, показывающий, был ли запрос отправлен с использованием SDP ответчика, идентифицированного в общем заголовке (или, вместо этого, была ли использована обобщенная инкапсуляция IP/GRE, например), флаги для обозначения рабочего и/или административного состояния оборудования ответчика, ассоциированного с идентификатором ответчика, включенным в заголовок, и флаг, информирующий создателя запроса о том, что идентификатор ответчика, включенный в запрос, был неправильным или был изменен, и что новый идентификатор ответчика, включенный в ответ, должен теперь использоваться. Другие флаги создателя и/или ответчика, и/или поля могут быть использованы аналогично описанным выше для проверки конфигурации и возможности соединения исходящих и ответных SDP.

В случае OAM сообщения эхо-запроса услуги или OAM сообщения эхо-ответа услуги, в одном варианте реализации, секция 404, характерная для конкретного сообщения, может содержать поля для обеспечения и/или проверки информации, относящейся к проверяемой услуге, и/или один или более флагов, используемых для сигнализации информации, относящейся к сообщению эхо-запроса или ответа услуги и/или услуге, к которой оно относится. Например, секция 404, характерная для конкретного сообщения, может содержать поля для обеспечения идентификатора услуги, ассоциированного с услугой, идентификатор для соответствующих меток виртуальных каналов, ассоциированных с услугой создателем и ответчиком соответственно а также набор флагов создателя эхо-сообщения услуги и набор флагов ответчика на эхо-сообщение услуги. Флаги создателя эхо-сообщения услуги могут быть использованы для сигнализации такой информации, как то, содержат ли определенные поля заголовка (например, идентификатор SDP создателя или идентификатор создателя) действительные данные, рабочее и/или административное состояние SDP создателя, идентифицированного в заголовке, был ли использован SDP создателя, идентифицированный в заголовке, для отправки запроса, должен ли получатель ответить с использованием SDP получателя, идентифицированного в заголовке (если это возможно), действителен ли идентификатор услуги создателя, включенный в соответствующее поле секции 404, характерной для конкретного сообщения, и соответствует ли рабочему и/или административному состоянию ассоциированной услуги подъем или спад на стороне создателя, и привязана ли услуга к SDP создателя, идентифицированному в заголовке. Флаги ответчика на эхо-сообщение услуги могут быть использованы для обеспечения соответствующей информации относительно конфигурации и состояния услуги на стороне ответчика и действительности данных в общем заголовке 402 и/или секции 404, характерной для конкретного сообщения. Дополнительные наборы флагов могут быть включены для обеспечения информации о действительности и рабочем состоянии входящих и исходящих VC меток, ассоциированных с услугой, на каждом конце, а также информации, относящейся к тому, как VC метки были переданы или обеспечены.

Фиг.5A иллюстрирует процесс определения действующей услуги, в соответствии с вариантом реализации. Определение действующей услуги или SDP является общим примером OAM функции, которая может быть выполнена. В этом варианте реализации обмен эхо-сообщениями для целей OAM, как было описано выше, может быть использован для реализации определения действующей услуги. Сообщение эхо-запроса посылается ESR дальнего конца для определения доступности и/или конфигурации услуги или SDP, рабочего состояния, возможности соединения и другой информации (например, MTU, полезной нагрузки и так далее) (504). Выполняется определение в отношении того, было ли или нет принято сообщение эхо-ответа (506). Если сообщение эхо-ответа было принято, то сообщение проверяется на наличие информации о конфигурации ESR дальнего конца, ID услуги и тому подобного (508). Если сообщение эхо-ответа не было принято, то сообщение об ошибке отправляется администратору (510), и услуга или SDP остаются в неработающем состоянии (512). Приведенное выше описание может быть использовано для описания использования обмена эхо-сообщениями для определений услуги или SDP, и, в других вариантах реализации, может быть использовано для других целей.

Фиг.5B иллюстрирует дополнительный процесс проверки сообщения эхо-ответа, в соответствии с вариантом реализации. В этом примере принимается сообщение эхо-ответа (520). После приема сообщение эхо-ответа проверяется для определения информации об услуге или SDP с местом назначения на дальнем конце (например, ESR) (522). После проверки, из сообщения эхо-ответа получают информацию, из которой можно определить, существует ли несовместимость между ESR дальнего конца и ESR ближнего конца (524).

Если несовместимость между ESR дальнего конца или SDP и ESR ближнего конца или SDP не найдена, то услуга или SDP приводятся в рабочее состояние (526). Если несовместимость между ESR дальнего конца или SDP и ESR ближнего конца или SDP найдена, на основе информации, включенной в сообщение эхо-ответа, отправляется сообщение об ошибке сетевому/системному администратору (528), и услуга или SDP остаются в нерабочем состоянии (530).

Фиг.6 иллюстрирует процесс для OAM эхо-сообщения для проверки маршрута распространения, основанного на услуге, в соответствии с вариантом реализации. В одном варианте реализации, процесс по Фиг.6 является характерной для конкретного SDP реализацией всего или части более общего процесса, показанного на Фиг.5A и 5B. Здесь, OAM эхо-сообщения SDP отправляются и принимаются между ближней конечной точкой (то есть создателем) и дальней конечной точкой (то есть ответчиком). OAM эхо-сообщения SDP могут включать в себя сообщение OAM эхо-запроса SDP и сообщение OAM эхо-ответа SDP.

В этом примере генерируется сообщение OAM эхо-запроса SDP (602). В процессе генерации, сообщение OAM эхо-запроса SDP может иметь различные битовые поля, значения заголовка, VC метки и другие управляющие слова, применяемые для идентификации определенных OAM функций или информационных запросов (например, возможности соединения SDP, тестирование RTT SDP, тестирование SDP-ID, рабочий обмен сообщениями SDP). После генерации, OAM сообщение эхо-запроса SDP отправляется дальней конечной точке (например, ESR) (604). На дальней конечной точке принимается OAM сообщение эхо-запроса SDP (606). После приема OAM сообщение эхо-запроса SDP обрабатывается в соответствии с информацией, включенной в формат сообщения (608). В этом примере, обработка может быть выполнена для определения и выполнения запрошенных OAM функций или для генерации и отправки OAM сообщения эхо-ответа SDP от ответчика назад создателю, который сгенерировал OAM сообщение эхо-запроса SDP.

Фиг.7 иллюстрирует процесс обмена OAM эхо-сообщениями для проверки услуги, отображенной на пункт распространения, основанный на услуге, в соответствии с вариантом реализации. В этом примере OAM сообщение эхо-запроса услуги генерируется создателем (702). После генерации OAM сообщения эхо-запроса услуги, он отправляется ответчику или месту назначения услуги на дальнем конце (например, ESR) (704). В месте назначения услуги на дальнем конце, OAM сообщение эхо-запроса услуги принимается и обрабатывается. Например, получатель может проверить данные ответчика, включенные в запрос, и может собрать и/или проверить информацию, относящуюся к конфигурации услуги на стороне ответчика. Ответчиком генерируется OAM сообщение эхо-ответа услуги и отправляется назад создателю. OAM сообщение эхо-ответа принимается (706). При приеме OAM сообщения эхо-ответа обрабатывается для определения того, сконфигурирована ли услуга правильно (708). OAM эхо-сообщения могут быть использованы для определения информации, относящейся к различным характеристикам услуги, включая то, существует ли услуга на дальнем конце, и если да, то каков рабочий и/или административный статус услуги на да