RU2511605C2 - Способ и устройство для квитирования состояния линии связи для предотвращения зацикливания - Google Patents

Abstract

Изобретение относится к области предотвращения переходного цикла в сети связи с пакетной коммутацией. Техническим результатом является предотвращение появления всех возможных циклов, которые могли появиться во время переходного процесса в сети. Способ содержит этапы: приема сообщения в сетевом интерфейсе, которое содержит информацию об изменении в топологии сети; блокирования отправления трафика к каждому соседнему узлу сети в сетевом интерфейсе посредством блока обработки; согласования блоком обработки относительно топологии с каждым соседним узлом путем обмена описанием базы данных топологии или дайджестом базы данных топологии; и разблокирования отправления трафика, когда соседний узел имеет информацию о топологии, которая является той же самой, что и информация о топологии, сохраненная в памяти. 2 н. и 24 з.п. ф-лы, 12 ил.

Description

Область техники

Настоящее изобретение относится к предотвращению переходного цикла в сети связи с пакетной коммутацией.

Уровень техники

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

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

Протоколы управления состоянием линии были недавно предложены также для применения в сетях Ethernet; архитектура определена в IEEE 802.1aq Соединение Кратчайшего пути (SPB) (IEEE 802.1aq Virtual Bridged Local Area Networks - Amendment 9; Shortest Path Bridging, Draft D0.4 (Виртуальные соединенные локальные сети - Поправка 9: Соединение кратчайшего пути, Проект D0.4), 19 февраля 2008). Предотвращение циклов важно для сетей Ethernet, поскольку случайный цикл может вызвать потерю контроля над сетью вследствие мультиплицирования зацикленных кадров групповой или широковещательной передачи. В противоположность IP, нет никакой области TTL в заголовке Ethernet кадров, так что кадры, мультиплицированные из-за цикла, не могут исчезнуть из сети.

Применение протоколов управления состоянием линии в сетях Ethernet и в сетях IPFRR вызывает потребность в эффективном механизме предотвращения цикла.

Входная проверка, также называемая проверкой отправления обратного пути (RPFC), была предложена для обращения с циклами в SPB. Однако входная проверка не устраняет все возможные циклы, а только уменьшает возможность временных циклов. То есть случайные циклы могут появиться, несмотря на применение входной проверки, как показано несколькими примерами.

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

Сущность изобретения

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

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

Краткое описание чертежей

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

Фиг.1 - блок-схема настоящего изобретения, когда принимается сообщение, имеющее информацию об изменении топологии;

Фиг.2 - блок-схема данного изобретения, когда сообщение запроса синхронизации принимается от соседнего узла;

Фиг.3 - пример топологии сети;

Фиг.4 показывает узлы, уведомленные первыми относительно топологии сети по фиг.3;

Фиг.5 показывает, какие узлы блокируют свой путь согласно примерной операции протокола квитирования состояния линии;

Фиг.6 показывает, что дополнительные узлы распознают изменение рассматриваемого примера;

Фиг.7 показывает, что большее количество узлов распознает изменение упомянутого примера;

Фиг.8 показывает, что все узлы распознают изменение упомянутого примера;

Фиг.9 показывает, что все узлы обновлены в упомянутом примере;

Фиг.10 показывает переходный цикл в основанном на IS-IS SPB, который появляется, даже если применяется входная проверка;

Фиг.11 показывает предотвращение цикла для сценария SPB согласно настоящему изобретению;

Фиг.12 - блок-схема узла согласно настоящему изобретению.

Подробное описание

Далее даются ссылки на чертежи, на которых одинаковыми ссылочными позициями обозначены подобные или идентичные части, и, в частности, на фиг.12, где показан сетевой узел 12 сети 10 связи, управляемый протоколом состояния линии связи. Узел 12, который изображен подробно на фиг.12, включает в себя сетевой интерфейс 14, который принимает сообщение, которое содержит информацию об изменении в топологии сети 10. Узел 12 включает в себя блок 16 обработки, который блокирует пересылку трафика по меньшей мере к одному соседнему узлу 20 сети 10 в сетевом интерфейсе 14, согласовывает изменение в топологии с соседним узлом 20; и разблокирует отправление трафика, когда соседний узел 20 имеет информацию о физической топологии, которая является той же самой, что и информация о физической топологии в памяти 18. Физическая топология включает в себя все узлы сети и все соединения между ними. Протокол управления состоянием линии связи используется в сети, и реализация объекта протокола управления исполняется в каждом сетевом узле. Протокол состояния линии связи поддерживает информацию о физической топологии в каждом сетевом узле. Протокол управления состоянием линии связи определяет пути отправления для сообщений данных между сетевыми узлами. Пути пересылки, используемые в сети Ethernet, содержат так называемую активную топологию, которая должна всегда быть свободной от цикла. В традиционных сетях Ethernet активная топология в типовом случае представляет собой остовное дерево, управляемое Быстродействующим Протоколом Остовного Дерева (RSTP). Остовное дерево не содержит все физические соединения, но инактивирует некоторые из избыточных соединений, чтобы избежать циклов. Соединения, поддерживаемые активным RSTP, формируют активную топологию, которая является остовным деревом. MSTP и SPB могут обрабатывать множество активных топологий, то есть множество деревьев.

Сетевой интерфейс 14 может принять уведомление от другого соседнего узла 22, которое содержит информацию об изменении топологии. Блок 16 обработки может блокировать по меньшей мере активную топологию или путь отправления, на который влияет изменение в по меньшей мере одном порту сетевого интерфейса 14. Сетевой интерфейс 14 может послать запрос синхронизации в соседний узел 20 по меньшей мере по одному порту, который содержит информацию об уведомлении. Блок 16 обработки может проверить, что соседний узел 20 принял уведомление. Сетевой интерфейс 14 может принять подтверждение синхронизации от соседнего узла 20, которому был послан запрос синхронизации, который указывает, что соседний узел 20 обновил топологию согласно информации о топологии в уведомлении. Цель синхронизации состоит в том, чтобы гарантировать, что соседние узлы имеют то же самое представление о физической топологии сети. Как описано выше, это может быть сделано проверкой того, что оба соседних узла приняли все элементы информации о физической топологии, то есть имеют тот же самый набор уведомлений. Альтернативой этому является проверка того, что он имеет ту же самую базу данных топологии, описывающую физическую топологию сети. С этой целью соседние узлы могут обмениваться дайджестом своей базы данных топологии (частью базы данных, которая описывает физическую топологию или, например, всей базой данных топологии, которая хранит все принятые уведомления) и синхронизироваться на основе этого дайджеста. Дайждест может быть, например, уникальным хешем или CRC, подготовленными на основе базы данных топологии.

Сетевой интерфейс 14 может принять подтверждение синхронизации, имеющее идентификатор (ID) узла и порядковый номер уведомления. Сетевой интерфейс 14 может принять запрос синхронизации. Блок 16 обработки может проверить уведомление, которое было принято и обработано, в отношении которого был послан запрос синхронизации. Сетевой интерфейс 14 может послать подтверждение синхронизации. Сетевой интерфейс 14 может иметь IS-IS флаг «послать сообщение маршрутизации», установленный для каждого PDU состояния линии связи на каждый порт, и флаг относительно блокирования порта, когда уведомление имеет информацию об изменении топологии. Может иметься BPDU в RSTP/MSTP, который имеет флаг для сообщения запроса синхронизации и флаг для сообщения подтверждения синхронизации, помимо наличия дайджеста базы данных топологии или наличия идентификатора узла и порядкового номера уведомления.

Настоящее изобретение относится к способу предотвращения переходного цикла сетевого узла 12 сети 10, имеющей множество сетевых узлов 12, управляемых протоколом состояния линии, который проиллюстрирован на фиг.1 и фиг.2. Способ включает в себя этап S11 приема сообщения в сетевом интерфейсе 14, который содержит информацию об изменении в топологии сети 10. Далее имеется этап S12 блокирования отправления трафика к каждому соседнему узлу 20 сети 10 в сетевом интерфейсе 14 посредством блока 16 обработки. Имеется этап согласования блоком 16 обработки относительно изменения в топологии с соседним узлом 20. Также имеется этап S16 разблокирования отправления трафика, когда соседний узел 20 имеет информацию о топологии, которая является той же самой, что и информация о топологии, сохраненная в памяти 18, то есть соседний узел 20 имеет то же самое представление о топологии. Имеется этап S17 проверки того, заблокированы ли все еще интерфейсы 20.

Этап S11 приема сообщения может включать в себя этап приема уведомления в сетевом интерфейсе 14 от другого соседнего узла 22, который содержит информацию об изменении топологии. Этап S12 блокирования может включать в себя этап блокирования по меньшей мере активной топологии или пути отправления, на который влияет изменение в сетевом интерфейсе 14. Может иметься этап поддержания блокирования до тех пор, пока соседний узел 20 не достигнет соглашения, что он имеет топологию в своей памяти 18, которая является той же самой, что и топология в памяти 18.

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

На этапе S21 сетевой интерфейс 14 принимает запрос синхронизации, как показано на фиг.2. На этапе S22 проверяется с помощью блока 16 обработки, что уведомление принято и обработано или имеется тот же самой дайджест базы данных топологии, для которого был послан запрос синхронизации. На этапе S23 проверяется, был ли послан запрос синхронизации относительно того же самого элемента информации в соседний узел 20. На этапе S24 сетевым интерфейсом 14 посылается подтверждение синхронизации. На этапе S25 разблокируется порт, если он был блокирован.

Может иметься этап конфигурирования IS-IS флага «послать сообщение маршрутизации» на каждом сетевом интерфейсе 14 для каждого IS-IS PDU состояния линии связи. Может иметься этап S12 установки флага относительно блокирования порта при приеме уведомления, содержащего информацию об изменении топологии. Альтернативно, может быть BPDU в RSTP/MSTP, имеющий флаг для сообщения запроса синхронизации и флаг для сообщения подтверждения синхронизации и описание информации, по которой запрашивается синхронизация, которое, например, может быть дайджестом базы данных топологии или идентификатором узла и порядковым номером. Может иметься этап согласования с соседним узлом 20 по дайджесту, по меньшей мере, части топологии, сохраненной в памяти 18. Может иметься этап согласования, включающий в себя этап использования CRC или хеша.

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

Кроме того, главная причина случайных циклов в случае протокола управления состоянием линии связи состоит в том, что узлы сети 12 узнают об изменении(ях) асинхронным способом, то есть в различное время, и порядок уведомления о них является непредсказуемым. Таким образом, главная причина случайных циклов состоит в том, что узлы 12 имеют непоследовательное представление о топологии сети 10.

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

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

Протоколы состояния линии связи применяют периодические приветственные сообщения, чтобы обнаружить соседей узла 12 и контролировать возможность соединения. Каждый узел 12 оповещает свою информацию о своих соседях, применяя лавинную маршрутизацию сообщения уведомления о состоянии линии связи (LSA) в случае OSPF или блока протокольных данных о состоянии линии связи (LSP) в случае IS-IS. Эти уведомления идентифицированы идентификатором узла 12 отправителя и порядковым номером. Поэтому можно легко проверить, принял ли узел 12 последнее уведомление от данного узла 12 или нет. Сетевые узлы 12 формируют и поддерживают базу данных о физической топологии сети 10 и вычисляют пути отправления на основе этой базы данных топологии. Таким образом, если все узлы 12 имеют то же самое представление о топологии, то они вычисляют те же самые пути отправления, следовательно, никакой цикл не может появиться. Также может быть проверено, идентична ли база данных топологии двух узлов, путем обмена дайджестом базы данных, например, CRC или хешем.

Фиг.1 показывает функционирование предложенного метода предотвращения цикла, когда уведомление о состоянии линии связи принято узлом 12. Если оно является только обновлением старой информации, то не требуется делать ничего для механизма предотвращения цикла. В противоположность этому, если уведомление содержит информацию об изменении в топологии, то узел 12 приемника должен заблокировать все свои порты. Таким образом, появляются разъединения в топологии отправления, предотвращая возникновение в сети 10 любого случайного цикла. Блокирование портов может означать блокирование всего порта или только блокирование активной топологии, которая затронута изменением. Например, в случае SPB имеется множество конфигурированных деревьев кратчайшего пути (SPT) и является достаточным блокировать дерево, которому принадлежит уведомление.

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

Порт блокируется до тех пор, пока не будет принято подтверждение синхронизации (Syn Ack) от соседнего узла 20 на том же самом LSA (LSP) или том же самом дайджесте, для которого запрашивалась синхронизация. Syn Ack также содержит идентификатор узла и порядковый номер уведомления, которое подтверждается, или содержит дайджест. Подтверждение отсылается, если узел 12, который принял запрос, также принял рассматриваемое уведомление и обновил топологию отсылки согласно новой физической топологии, то есть имеет ту же самую базу данных топологии.

В запрашиваемом узле 12 имеется разъединение в направлении к соседнему узлу 20 до тех пор, пока конкретный соседний узел не подтвердит изменение топологии.

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

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

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

a) оба узла блокируют линию связи, посылают запрос, посылают и принимают подтверждение от другой стороны и разблокируют линию связи,

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

Вариант (b) является более быстрым, и работа согласно варианту (b) показана на фиг.2.

Иллюстративный пример работы

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

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

Предполагается, что узлы B и F узнают об изменении, как проиллюстрировано на фиг.4.

Как показано на фиг.5, узлы B и F блокируют свои порты, поскольку они реализуют изменение топологии и отсылают запрос синхронизации на принятое уведомление.

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

Как только подтверждения поступают, линии связи A-B и F-H становятся разблокированными, как изображено на фиг.7. Узлы C, D, E, I и J узнают об изменении на следующем этапе, таким образом, они подтверждают первые запросы, блокируют остальную часть своих портов и отсылают запрос синхронизации. Отметим, что узлы I и J посылают запрос в то же самое время, которое также поддерживается для узлов C и E.

Алгоритмы, показанные на фиг.1 и фиг.2, применяются, то есть если оба соседних узла посылают запрос для того же самого уведомления по той же самой линии связи, затем они активизируют линию связи после приема запроса от другой стороны. Фиг.8 показывает результат предыдущих сообщений.

Фиг.9 показывает случай, где все узлы 12 обновлены, и последний отослал назад подтверждение, таким образом, нет никакой блокированной линии связи.

Как показано на вышеуказанных чертежах, имеются независимые разъединения в топологии отправления во время конвергенции, которые не синхронизированы друг с другом, но зависят от порядка уведомления сетевых узлов 12. Очень важно, чтобы сеть 10 не отключалась во время конвергенции. Техника квитирования отличается от той, которая реализована в RSTP/MSTP, потому что в RSTP/MSTP квитирование связано с распространением информации об изменении топологии, которая переносится вектором расстояния, таким образом, квитирования предложения-соглашения должны следовать последовательности от корневого моста к листовым (концевым) мостам.

Имелось несколько идентифицированных сценариев, где переходные циклы могут появляться в основанной на IS-IS архитектуре, которая была предложена для SPB, несмотря на применение уменьшения циклов, например, входной проверки. Один из них изображен на фиг.10.

Физическое соединение между A и B разъединяется, и новое физическое соединение возникает между B и E в то же самое время. Затраты линии связи также указаны на чертеже; стрелки показывают передачу пакета от узла A. Как можно видеть, начальная и заключительная топология свободны от циклов. Линия связи между A и D не используется в начальной топологии; и линия связи между C и D не используется в заключительной топологии. Однако цикл формируется во время переходного процесса, если узлы A, B и E имеют обновленное представление о топологии, но узлы C и D имеют устаревшее представление. Цикл появляется, даже если входная проверка применяется.

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

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

Метод квитирования состояния линии связи может быть реализован различными способами. Две возможности реализации в качестве примера описаны здесь.

Механизм квитирования состояния линии связи может быть реализован с помощью IS-IS PDU и введением нового флага на каждый порт узла 12. Этот флаг будет обозначаться как BLOCKflag. Применение существующего IS-IS PDU описано здесь. Альтернатива этому должна определять новые PDU или TLV для механизма квитирования.

В IS-IS передача LSP управляется флагом «послать сообщение маршрутизации» (SRMflag), который может быть установлен для каждого PDU состояния линии связи (LSP) на каждый порт (схему). Если SRMflag для LSP на порт установлен, то LSP будет передаваться по истечении минимального интервала передачи LSP или немедленно, если был принят новый LSP. То есть LSP посылаются либо потому, что процесс обновления автоматически восстанавливает их, либо потому, что поступил новый LSP, содержащий новую информацию о топологии сети. Оба вида передач LSP управляются посредством SRMflag. На двухточечных линиях связи SRMflag очищается, если либо PDU частичного порядкового номера (PSNP), либо PDU полного порядкового номера (CSNP) принимается для LSP на этом порту. То есть PSNP служит своего рода подтверждением для LSP, перечисленных в PSNP, принятым смежным соседним узлом. Если LSP не перечислен в сообщении PSNP, то SRMflag остается установленным, поэтому LSP должен повторно передаваться к этому соседнему узлу. То есть PSNP предназначен для управления повторной передачей LSP в IS-IS по двухточечным линиям связи.

Механизм квитирования состояния линии связи может быть реализован с некоторыми расширениями для IS-IS. Новый флаг вводится для каждого порта: BLOCKflag; если BLOCKflag установлен, то кадрам пользовательской плоскости не разрешается проходить через этот порт, в противном случае пользовательские кадры могут передаваться через этот порт. Блокирование порта должно быть реализовано так или иначе, то есть никакие кадры не могут войти в узел 12 через этот порт, и никакие кадры не могут быть отосланы через этот порт. Это может быть реализовано, например, установкой фильтра, который управляется посредством BLOCKflag. Отметим, что если IS-IS используется в мостовой сети 10, то блокирование порта может быть реализовано с использованием роли блокирования порта RSTP/MSTP. LSP используются в качестве сообщений запроса синхронизации, и PSNP используются как сообщение подтверждения синхронизации метода квитирования состояния линии связи. В дополнение к этому должна быть ускорена передача PSNP, которые отсылаются согласно интервалу PSNP. В современных применениях IS-IS интервал PSNP находится в диапазоне секунд, что не применимо для метода предотвращения цикла, поскольку это привело бы к очень медленной конвергенции. Поэтому интервал PSNP должен быть уменьшен в диапазон миллисекунд или десятков миллисекунд. Передача PSNP управляется флагом «послать сообщение порядковых номеров» (SSNflag), который устанавливается при приеме каждого LSP, передаваемого по двухточечной линии. Если SSNflag установлен для LSP на порту, то соответствующий LSP должен быть перечислен в следующем PSNP, отсылаемом по этому порту. SSNflag очищается, когда соответствующий PSNP был отослан. Чтобы иметь возможность ускорить передачу PSNP, флаги SSNflags для LSP должны иметь возможность проверяться очень легко и быстро. Поэтому предложено поддерживать отдельный вектор (SSNvector) для SSNflag, таким образом, можно легко проверить двоичной операцией, имеется ли какой-либо установленный SSNflag, и соответствующий LSP должен быть перечислен в следующем PSNP. Другая возможность состоит в том, чтобы реализовать управление на основе прерывания для передачи PSNP вместо опроса для передачи на основе интервала PSNP. Когда PSNP принимается, SRNflag очищается. В этом случае оба соседних узла знают об изменении топологии, переносимом соответствующим LSP, таким образом, линия связи между ними может быть разблокирована. То есть BLOCKflag должен быть очищен, и линия связи повторно активируется.

Операция IS-IS с этими настройками и расширениями осуществляется следующим образом в сети 10, где установлены только двухточечные линии связи. Предположим, что узел 12 принимает LSP об изменении топологии на одном из своих портов. SRMflag затем устанавливается для этого LSP для всех портов за исключением того, на котором был принят LSP. Если LSP не является повторением первого, а относится к изменению топологии, то BLOCKflag должен быть также установлен для всех портов за исключением того, на котором поступил LSP. То есть все эти порты должны быть заблокированы. Отметим, что порт, на котором поступил LSP, необязательно должен быть блокированным, так как соседний узел, соединенный с тем конкретным узлом 12, знает об изменении топологии, так как тот узел 12 послал информацию об этом. Если SRMflag установлен на порту, то IS-IS объект отсылает LSP через этот порт. SRMflag поддерживается установленным до тех пор, пока PSNP не будет принят на этом порту. Когда соседний узел принимает LSP по двухточечной линии, он устанавливает соответствующий SSNflag. Если SSNflag установлен для LSP, то о приеме этого LSP должно быть сообщено соседнему узлу в следующем PSNP, который периодически посылается согласно интервалу PSNP. Все LSP, принятые в пределах интервала PSNP, подтверждаются в том же самом PSNP. Когда PSNP принят, как SRMflag, так и BLOCKflag очищаются, и линия связи разблокируется, пользовательские кадры могут передаваться по ней.

RSTP/MSTP обеспечивает механизм квитирования предложения-соглашения для предотвращения цикла. Этот механизм связан с вектором расстояния от корневого моста, который указывает на информацию об изменении топологии, если она была изменена. Так как RSTP и MSTP являются протоколами управления вектором расстояния, их объединенное применение вместе с протоколом управления состоянием линии связи, таким как IS-IS, является невыгодным. Если IS-IS является протоколом управления для конфигурирования активной топологии в SPB, то RSTP/MSTP не должны исполняться параллельно.

Хотя IS-IS может использоваться в мостовой сети 10 для конфигурирования активной топологии, и механизм квитирования состояния линии связи может быть реализован в RSTP/MSTP BPDU и выполняться параллельно IS-IS.

RSTP/MSTP BPDU реализуют механизм квитирования, так что механизм квитирования состояния линии связи может быть реализован в таких BPDU с небольшой модификацией на них.

Флаг предложения (бит 2 октета 5) BPDU может использоваться в качестве флага для сообщения запроса синхронизации.

Флаг соглашения (бит 7 октета 5) BPDU может использоваться в качестве флага для сообщения подтверждения синхронизации.

IS-IS нацелен на использование в SPB в качестве протокола управления состоянием линии связи для SPB. Идентификатор (ID) LSP и порядковый номер IS-IS LSP могут использоваться в качестве идентификатора информации об изменении топологии. LSP ID является системным идентификатором источника PDU состояния линии связи; порядковый номер является порядковым номером LSP. Поэтому LSP ID и порядковый номер должны быть включены в BPDU, чтобы реализовать сообщения запроса синхронизации и подтверждения синхронизации предложенного механизма квитирования состояния линии связи. Возможным вариантом является определить область из идентификации нескольких LSP в том же самом BPDU. Альтернативой этому является расширение BPDU дайджестом базы данных топологии и обеспечение квитирования на основе дайджеста.

Блокирование порта может быть, например, реализовано с использованием роли блокирования порта.

Таким образом, метод предотвращения цикла может быть легко реализован на основании RSTP/MSTP BPDU.

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

Настоящее изобретение связано с продолжающимися обсуждениями в IEEE 802.1aq Соединении кратчайшего пути. Предложенный способ может применяться также в инфраструктуре IP Быстрого изменения маршрутизации.

Сокращения

BPDU блок протокольных данных моста

CSNP PDU полного порядкового номера

IP-FRR IP быстрое изменение маршрутизации

IS-IS протокол маршрутизации от промежуточной системы к промежуточной системе

LSA уведомление о состоянии линии связи

LSP блок протокольных данных состояния линии связи

MSTP протокол множественного остовного дерева

OSPF первый открытый кратчайший путь

PSNP PDU частичного порядкового номера

RSTP быстрый протокол дерева охвата

SPB шунтирование кратчайшего пути

SRMflag флаг «послать сообщение маршрутизации»

SSNfalg флаг «послать сообщение порядкового номера»

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

Claims (26)

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

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

3. Способ по п.2, в котором этап блокирования включает в себя этап блокирования, по меньшей мере, активной топологии или пути отправления, на который влияет изменение в сетевом интерфейсе.

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

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

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

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

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

9. Способ по п.3, содержащий этап, на котором сетевой интерфейс принимает запрос синхронизации.

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

11. Способ по п.10, содержащий этап посылки сетевым интерфейсом подтверждения синхронизации.

12. Способ по п.8, содержащий этапы установки флага «послать сообщение маршрутизации» для каждого протокольного блока данных (PDU) состояния линии связи протокола маршрутизации от промежуточной системы к промежуточной системе (IS-IS) на порт, установки флага относительно блокирования порта, когда уведомление содержит информацию об изменении топологии, очистки флага относительно блокирования порта при приеме блока протокольных данных частичных порядковых номеров (PSNP) и конфигурирования интервала PSNP в диапазоне миллисекунд для быстрой сходимости.

13. Способ по п.8, в котором блок протокольных данных моста (BPDU) в быстром протоколе дерева охвата (RSTP)/протоколе множественного остовного дерева (MSTP) имеет флаг для сообщения запроса синхронизации и флаг для сообщения подтверждения синхронизации, и BPDU содержит либо описание базы данных топологии или дайджест базы данных топологии.

14. Способ по п.4, в котором этап согласования включает в себя этап согласования с соседним узлом по дайджесту по меньшей мере части топологии, сохраненной в памяти, где дайджест представляет собой контроль циклическим избыточным кодом (CRC) или хеш базы данных топологии.

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

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

17. Узел по п.16, в котором блок обработки блокирует по меньшей мере активную топологию или путь отправления, на который оказывает влияние изменение в по меньшей мере одном порту сетевого интерфейса.

18. Узел по п.17, в котором сетевой интерфейс приспособлен, чтобы посылать запрос синхронизации в соседний узел по меньшей мере по одному порту, который содержит информацию об уведомлении.

19. Узел по п.18, в котором блок обработки верифицирует, что соседний узел принял уведомление.

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

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

22. Узел по п.21, в котором сетевой интерфейс приспособлен, чтобы принимать запрос синхронизации.

23. Узел по п.22, в котором блок обработки верифицирует, что уведомление, для которого был послан запрос синхронизации, было принято и обработано.

24. Узел по п.23, в котором сетевой интерфейс приспособлен, чтобы посылать подтверждение синхронизации.

25. Узел по п.24, в котором в каждом сетевом интерфейсе установлен флаг «послать сообщение маршрутизации» для каждого протокольного блока данных (PDU) состояния линии связи на порт, и сетевой интерфейс приспособлен, чтобы поддерживать флаг относительно блокирования порта и устанавливать флаг блокирования, когда уведомление имеет информацию об изменении топологии, и очищать флаг блокирования при приеме соответствующего протокольного блока данных частичных порядковых номеров.

26. Узел по п.24, в котором блок протокольных данных моста (BPDU) в быстром протоколе дерева охвата (RSTP)/протоколе множественного остовного дерева (MSTP) имеет флаг для сообщения запроса синхронизации и флаг для сообщения подтверждения синхронизации, и BPDU содержит либо описание базы данных топологии, либо дайджест базы данных топологии.

Images