В промышленности требования к ЛВС становятся все более серьезными, т.к. АСУ ТП берут на себя все больший функционал, и потери данных могут повлечь серьезные издержки.
Например, в энергетике, если на терминал РЗА не попадут вовремя данные от измерительных преобразователей, то это может быть чревато распространением короткого замыкания на смежные участки электросети, что скажется убытками гораздо более серьезными, нежели в случае своевременного отключения участка с КЗ. Поэтому часто в проектах энергетики можно встретить требование «Время восстановления менее 1 мс».
Резервирование сети на основе таких распространенных в промышленности протоколов, как RSTP, MRP, DLR и прочих подобных, основано на изменении топологии в случае возникновения какой-либо неисправности при передаче данных. Изменение топологии занимает определенное время (от миллисекунд до секунд в зависимости от протокола), которое и называется «временем восстановления». В течение этого времени связи с частью сети нет и, соответственно, данные теряются. Т.е. привычные технологии кольцевого резервирования не позволяют обеспечить время восстановления меньше 1 мс.
Ввиду этого набирают популярность технологии так называемого «бесшовного» резервирования — PRP и HSR. Резервирование на основании PRP и HSR осуществляется, в отличие от вышеобозначенных протоколов, не за счет перестроения топологии, а за счет дублирования фреймов. Каждый фрэйм дублируется отправителем, и оба фрейма передаются разными путями, а принимающий узел обрабатывает фрэйм, пришедший первым, и отбрасывает второй. Данный принцип работы не требует выполнения перестроения топологии и, соответственно, данный протокол действует практически «бесшовно». Под катом Вы найдете подробности реализации данных протоколов.
«Бесшовное» резервирование реализуется на конечных узлах, а не на сетевых компонентах. Это одно из самых главных отличий PRP и HSR от других протоколов резервирования, таких как RSTP или MRP. Рассмотрим особенности структуры сети для PRP и HSR.
Конечный узел имеет два Ethernet-интерфейса, которые подключаются к двум изолированным друг от друга сетям, действующим параллельно и имеющим независимую топологию (т.е. топологии этих двух сетей могут быть как одинаковыми, так и различаться). Сети должны быть изолированными для того, чтобы любая неисправность и остановка передачи данных в одной сети не влияли на вторую, т.е. даже питание сетей осуществляется от разных источников. Никаких прямых соединений между этими сетями быть не должно.
Структура сети PRP
Эти две сети обычно называются LAN A и LAN B. Как уже обозначалось ранее, они могут иметь различные топологии, а также различную производительность. Задержки в передачи данных также могут различаться.
В сети могут присутствовать следующие элементы:
Принцип работы RedBox’а
Структура сети HSR
Принцип действия HSR заключается в том, что все устройства объединяются в кольцо и все сообщения, также как и в PRP, дублируются. Устройство отправляет оба фрейма через кольцо: одну копию по часовой стрелке, другую — против. Приемник получает обе копии, но обрабатывает только первую, а вторую удаляет. Если с каким-то из линков что-то случается, и один из дублированных фреймов не приходит, то просто принимается другой. Все HSR-устройства имеют два Ethernet-интерфейса — порт A и порт B.
В соответствии с протоколом HSR в сети могут существовать следующие элементы:
Пример использования QuadBox
Для PRP и для HSR структура DAN похожа. Каждый DAN имеет два интерфейса, действующих параллельно и подключенных к верхнему уровню одного коммуникационного стека через так называемый уровень LRE — link redundancy entity. На данном уровне выполняются все функции резервирования.
Оба интерфейса DAN имеют одинаковые MAC-адреса и один IP-адрес. Это позволяет сделать резервирование прозрачным для верхнего уровня. Особенно важен тот факт, что это позволяет использовать протокол ARP для DAN также, как и для любого нерезервированного узла.
Однако, конечно, в структуре DAN для PRP и для HSR имеются и нюансы.
Когда с верхнего уровня посылается фрейм, LRE дублирует его и посылает оба пакета через порты практически одновременно. Оба фрейма передаются параллельно через две сети с разными задержками. В идеальной ситуации они доставляются на узел назначения с минимальной разницей во времени. При получении LRE приемника передает на верхний уровень первый принятый фрейм, а второй отбрасывает.
LRE создает дублированные фреймы при отправке и обрабатывает их при получении. Данный уровень, по отношению к верхнему уровню, представляет собой обычный интерфейс нерезервированного сетевого адаптера. LRE выполняет две задачи: обработка дублированных фреймов и управление резервированием. Для реализации управления LRE добавляет к каждому фрейму 32-битный трейлер контроля резервирования (redundancy control trailer — RCT) и удаляет его при получении фрейма.
Передача данных между двумя DAN в PRP
Фрейм, присланный с верхнего уровня, дублируется уровнем LRE, и пакеты посылаются через порт A и порт B практически одновременно. (1 и 2 на схеме).
Приемник при получении фрейма передает его на уровень LRE, а также перенаправляет на другой порт и передает дальше в кольце. (3, 4).
Если фрейм приходит на отправитель, то дальше этот фрейм не передается, а уничтожается (5, 6).
На уровень LRE приходят оба фрейма, но на верхний уровень передается тот, который был прислан быстрее, а дублированный фрейм отбрасывается.
LRE добавляет к каждому фрейму 48-битный HSR-тег (сродни добавлению VLAN-тега) и удаляет этот тег при получении.
Передача данных между двумя DAN в HSR
В PRP SAN может быть подключен к любой сети — LAN A или LAN B, но такой узел не поддерживает функций резервирования. Поэтому SAN, подключенный к одной сети, не сможет обмениваться данными с другим подобным узлом, подключенным ко второй сети. Для взаимодействия с SAN DAN генерирует специальные фреймы. Эта необходимость вызвана тем, что SAN в обычном фрейме от резервированного устройства должен игнорировать RCT, что сделать не представляется возможным, так как SAN не может отличить RCT от обычного блока данных IEEE 802.3. В свою очередь, DAN понимает, что отправляет фрейм на SAN и не добавляет RCT в фрейм. Он просто пересылает один фрейм с верхнего уровня на тот интерфейс, к которому подключен SAN. Другими словами, если DAN не может определить, что обменивается данными с другим DAN, то он не добавляет RCT в фрейм.
В HSR SAN не может быть подключен напрямую к сети. Его можно подключать исключительно через RedBox
При работе с дублированными фреймами, принимаемыми на обоих интерфейсах (в случае их исправности), DAN необходимо принять один из фреймов, а второй отбросить. В PRP есть два метода обработки:
Для HSR рассмотрим наиболее популярные режимы U и X
DAN, работающий в данном режиме не отбрасывает ни один из фреймов при обработке на канальном уровне.
Фреймы отправляются в LAN A и LAN B без RCT. LRE приемника просто перенаправляет оба фрейма на верхний уровень, предполагая, что при дальнейшей передаче дубликаты будут уничтожены (в IEEE 802.1D четко прописано, что протоколы верхнего уровня должны уметь обрабатывать дублированные фреймы).
Например, протоколы TCP и UDP имеют высокий уровень устойчивости к дублированным фреймам.
Данный метод очень прост в реализации, но имеет серьезный недостаток — он не предоставляет никаких возможностей контроля сети, т.к. никаким образом не отслеживается корректность приема обоих фреймов.
При использовании второго метода в фрейм добавляется поле, состоящее из четырех октет — RCT (redundancy control trailer). Трейлер добавляется на уровне LRE, когда фрейм принимается от верхнего уровня. RCT состоит из следующих параметров:
Из-за добавления к фрейму RCT-трейлера его размер получается больше максимального размера фрейма, определенного в стандарте IEEE 802.3-2005. Для передачи данных внутри сети с PRP оборудование должно быть сконфигурировано для передачи данных размером 1496 октет. Из-за этого не каждый коммутатор подходит для использования в LAN A или LAN B.
Фрейм с добавленным RCT
Каждый раз, когда канальный уровень посылает фрейм на какой-то определенный адрес, отправитель увеличивает номер последовательности для соответствующего узла и отправляет идентичные фреймы через оба интерфейса.
Узел-приемника должен определить дубликаты, основываясь на информации из RCT.
Приемник предполагает, что фреймы, присылаемые от любого источника, работающего по протоколу PRP, посылаются последовательно с постоянно возрастающим номером. Номер последовательности, который ожидается у следующего фрейма хранится в переменных ExpectedSeqA и соответственно ExpectedSeqB.
При приеме, корректность последовательности может быть проверена при помощи сравнения значения ExpectedSeqA (ExpectedSeqB) c номером последовательности полученного фрейма, хранящемся в переменной currentSeq в RCT. При положительном результате, переменная ExpectedSeq устанавливается на один больше, чем currentSeq для того, чтобы далее можно бы было выполнять корректную проверку на данной линии.
Интервал отбрасывания фрейма (drop window)
Для обоих интерфейсов существует динамический интервал отбрасывания фрейма (sliding drop window) для парных номеров последовательности. Верхней границей данного интервала является ExpectedSeq (следующий ожидаемый номер последовательности на данном интерфейсе), исключая само данное значение, а нижней границей данного интервала является startSeq (наименьший номер последовательности, при котором происходит отбрасывание дублированного фрейма с таким номером последовательности).
После проверки правильности номера последовательности, приемник решает отбрасывать данный фрейм или нет. Предположим, что LAN A имеет ненулевой размер интервала отбрасывания фрейма (Рис.5). Фрейм из LAN B, чей номер лежит в данном интервале, будет отброшен. Все остальные фреймы из LAN B будут приняты и отправлены на верхний уровень.
Отбрасывая фрейм из LAN B, уменьшается размер интервала LAN A, т.к. после получения данного фрейма не ожидается никаких фреймов с меньшим номером на данном интерфейсе. Соответственно startSeqA устанавливается на один больше, чем currentSeqB. При этом размер интервала отбрасывания фрейма LAN B сбрасывается до 0 (startSeqB = expectedSeqB), т.к. очевидно, что фреймы LAN B “отстают” от LAN A и никакие фреймы из LAN A не должны быть отброшены.
Уменьшение интервала LAN A после отбрасывания фрейма из LAN B
В ситуации на рис.7, когда несколько фреймов из LAN A приходят подряд, но из LAN B не приходит ничего, то они принимаются, т.к. их currentSeq находится вне интервала отбрасывания фрейма LAN B и интервал LAN A увеличивается на одну позицию. Если фреймы из LAN A продолжают приходить, а из LAN B по прежнему ничего не приходит, при достижении максимального размера интервала, startSeqA начинает также увеличиваться на единицу.
Когда принимаемый фрейм находится вне интервала отбрасывания фрейма другого LAN, то этот фрейм сохраняется, а размер интервала данного интерфейса устанавливается равным 1, что означает, что только фрейм из другого LAN с таким же номером последовательности будет отброшен, в то время как drop window другого интерфейса устанавливается равным 0, что означает, что ни одного фрейма не будет отброшено (Рис.7).
Фрейм из LAN B не был отброшен
Наиболее общая ситуация — когда оба интерфейса синхронизированы и размер обоих интервалов равен 0 (Рис.8), что означает, что будет принят фрейм того интерфейса, который придет первее и интервал данного интерфейса будет увеличен до 1, что позволит отбросить фрейм от другого интерфейса с таким же номером последовательности.
Синхронизированные LAN
Из-за наличия идентификатора LAN в RCT, дублированные фреймы различаются на один бит (и имеют разные контрольные суммы). Приемник проверяет принадлежность фрейма к интерфейсу (т.е. проверяет, что фрейм с идентификатором LAN A пришел на интерфейс A). Приемник не отбросит данный фрейм, т.к. он может содержать полезную информацию в блоке данных, но в этом случае будет увеличен на единицу счетчик cntWrongLanA или cntWrongLanB. Так как подобные ошибки не разовые (перепутаны местами LAN A и LAN B), то счетчик будет возрастать постоянно.
При передаче данных внутри HSR-сети к каждому фрейму добавляется HSR-тег.
HSR-тег состоит из следующих параметров:
Отправитель вставляет одинаковые номера последовательности отправляемым дублированным фреймам и затем инкрементирует номер последовательности для каждой посылки, отправленной с данного узла.
Приемник отслеживает номера последовательности всех фреймов от каждого источника, от которого он принимает данные (источники он различает по MAC-адресу). Если фреймы приходят с разных линий и имеют одинаковый источник и номер последовательности, то один из них принимается, а второй отбрасывается.
Для контроля сети, на каждом устройстве ведется таблица всех узлов в сети, от которых он принимает данные. Это позволяет обнаружить исчезновение узлов и ошибки на шине.
Узел определяет фрейм, который он отправил по источнику и по номеру последовательности.
Фрейм с добавленным HSR-тегом
Узел HSR никогда не отбрасывает фрейм, который он ранее не получал. Узел определяет практически все дублированные фреймы, но в случае, если их немного, он их не удаляет, т.е. фрейм просто проходит все кольцо и уничтожается на отправителе.
В стандарте алгоритм определения дублированных фреймов не определен. В качестве возможных методов могут быть использованы хэш-таблицы, очереди и отслеживание номеров последовательности.
В данном режиме, узел, который принимает фрейм, уничтожает дубликат и не позволяет ему распространяться дальше. В случае, если фрейм все-таки были передан далее, то он уничтожается на следующих узлах. Данный режим позволяет разгрузить кольцо от Unicast-трафика.
На схеме красными стрелками обозначены пакеты с HSR-тегом, отправленные с порта “А” (в дальнейшем — фрейм “А”).
Зелеными стрелками обозначены пакеты с HSR-тегом, отправленные с порта “В” (в дальнейшем — фрейм “В”).
Пустыми стрелками обозначен отброшенный трафик, т.е. фреймы, которые бы передавались при обычной работе, но в данном режиме были отброшены.
Крестом обозначается удаление трафика из кольца (в любом случае).
В данном режиме узел не передает фрейм дальше и отбрасывает его, если такой фрейм был получен с другого направления.
Например, DAN 1 на изображении не передаст дальше фрейм “B”, т.к. он уже получил фрейм “A”, а DAN 2 не будет передавать далее фрейм “A”, т.к. уже получил фрейм “B”.
В случае, если в алгоритме произошла где-то ошибка и фреймы были переданы далее, то они будут отброшены на следующих узлах или на узле, на котором они были созданы.
Режим X не применим для сообщений PTP и для передачи supervision frame.
Приемник проверяет, что все фреймы приходят последовательно и корректно принимаются на обоих каналах. Он поддерживает счетчики ошибок, которые можно прочитать, например, через SNMP.
Все устройства поддерживают таблицы узлов, с которыми они обмениваются данными. В этих таблицах содержится информация о времени, когда последний фрейм был отправлен или получен от конкретного узла и другую информацию, касающуюся протокола PRP.
В то же время, данные таблицы позволяют обнаружить соединения, в которых необходимо синхронизировать номера последовательности, а также обнаружить нарушенные последовательности и пропавшие узлы.
Диагностика основана на том, что каждый DAN периодически посылает диагностический фрейм (supervision frame), который позволяет проверить целостность сети и наличие узлов. В то же время данные фреймы позволяют проверить какие устройства выступают в качестве DAN, определить их MAC-адреса и в каком режиме они работают — duplicate accept или duplicate discard.
Каждый узел постоянное проверяет все линки.
Каждый узел периодически посылает диагностический фрейм (на оба порта), содержащий информацию о состоянии узла. Этот фрейм принимается всеми узлами, включая отправителя. Когда отправитель принимает собственное диагностическое сообщение, то выполняется проверка целостности физического канала.
Интервал посылки диагностического фрейма сравнительно большой (несколько секунд), т.к. он не требуется для обеспечения резервирования, а нужен только для диагностических целей.
Все узлы заносят в таблицу всех партнеров, которых удалось обнаружить, и регистрируют время, когда узел последний раз был активен, а также все пропущенные фреймы и фреймы, присланные не последовательно.
Все произошедшие изменения топологии также регистрируются и вся информация может быть получена по SNMP.
HSR и PRP: плюсы и минусы
Нельзя сказать, что один протокол лучше другого — они созданы немного для разных применений. И HSR, и PRP позволяют организовать бесшовное резервирование сети, но HSR позволяет создавать более бюджетные решения. Но подобная экономичность влечет за собой сложности, т.к. сеть на основе HSR достаточно сложно масштабировать, и применения не очень гибкие. Низкая гибкость обуславливается ограниченной топологией (кольцо, сопряжение колец), а также плохой совместимостью протокола с другими технологиями. Поэтому HSR лучше подходит для резервирования небольших систем и интеграции в большую сеть. Организовать резервирование всей сети на основе HSR достаточно проблематично. PRP же, в свою очередь, является решением более дорогим, но позволяющим организовать достаточно масштабную сеть, которую в дальнейшем можно будет расширять без проблем, т.к. данный протокол дает возможность удобно интегрировать практически любые технологии и реализовывать совершенно разные топологии.
Найти решение
Например, в энергетике, если на терминал РЗА не попадут вовремя данные от измерительных преобразователей, то это может быть чревато распространением короткого замыкания на смежные участки электросети, что скажется убытками гораздо более серьезными, нежели в случае своевременного отключения участка с КЗ. Поэтому часто в проектах энергетики можно встретить требование «Время восстановления менее 1 мс».
Резервирование сети на основе таких распространенных в промышленности протоколов, как RSTP, MRP, DLR и прочих подобных, основано на изменении топологии в случае возникновения какой-либо неисправности при передаче данных. Изменение топологии занимает определенное время (от миллисекунд до секунд в зависимости от протокола), которое и называется «временем восстановления». В течение этого времени связи с частью сети нет и, соответственно, данные теряются. Т.е. привычные технологии кольцевого резервирования не позволяют обеспечить время восстановления меньше 1 мс.
Ввиду этого набирают популярность технологии так называемого «бесшовного» резервирования — PRP и HSR. Резервирование на основании PRP и HSR осуществляется, в отличие от вышеобозначенных протоколов, не за счет перестроения топологии, а за счет дублирования фреймов. Каждый фрэйм дублируется отправителем, и оба фрейма передаются разными путями, а принимающий узел обрабатывает фрэйм, пришедший первым, и отбрасывает второй. Данный принцип работы не требует выполнения перестроения топологии и, соответственно, данный протокол действует практически «бесшовно». Под катом Вы найдете подробности реализации данных протоколов.
Структура сети
«Бесшовное» резервирование реализуется на конечных узлах, а не на сетевых компонентах. Это одно из самых главных отличий PRP и HSR от других протоколов резервирования, таких как RSTP или MRP. Рассмотрим особенности структуры сети для PRP и HSR.
PRP — структура сети
Конечный узел имеет два Ethernet-интерфейса, которые подключаются к двум изолированным друг от друга сетям, действующим параллельно и имеющим независимую топологию (т.е. топологии этих двух сетей могут быть как одинаковыми, так и различаться). Сети должны быть изолированными для того, чтобы любая неисправность и остановка передачи данных в одной сети не влияли на вторую, т.е. даже питание сетей осуществляется от разных источников. Никаких прямых соединений между этими сетями быть не должно.
Структура сети PRP
Эти две сети обычно называются LAN A и LAN B. Как уже обозначалось ранее, они могут иметь различные топологии, а также различную производительность. Задержки в передачи данных также могут различаться.
В сети могут присутствовать следующие элементы:
- DAN (Dual Attached Node) — узел, который подключается к обеим сетям и посылает/принимает дублированные фреймы.
- SAN (Single Attached Node) — узел, который подключается только к одной сети (LAN A или LAN B) и посылает/принимает обычные фреймы.
- В случае, когда к RPR -сети необходимо резервировано подключить устройство, имеющее один Ethernet-интерфейс, и без поддержки протокола PRP, используется так называемый Redundancy Box (чаще RedBox). На RedBox’е пакет от устройства дублируется и передается в сеть PRP, так словно данные передаются от DAN. Более того, устройство, которое находится за RedBox’ом, видится для остальных устройств как DAN. Такой узел называется виртуальный DAN или VDAN (Virtual DAN).
Принцип работы RedBox’а
HSR — структура сети
Структура сети HSR
Принцип действия HSR заключается в том, что все устройства объединяются в кольцо и все сообщения, также как и в PRP, дублируются. Устройство отправляет оба фрейма через кольцо: одну копию по часовой стрелке, другую — против. Приемник получает обе копии, но обрабатывает только первую, а вторую удаляет. Если с каким-то из линков что-то случается, и один из дублированных фреймов не приходит, то просто принимается другой. Все HSR-устройства имеют два Ethernet-интерфейса — порт A и порт B.
В соответствии с протоколом HSR в сети могут существовать следующие элементы:
- SAN — узел, имеющий только один Ethernet-интерфейс. Такой узел может быть подключен к HSR-сети исключительно через RedBox.
- DAN — узел, который может обмениваться данными внутри HSR-кольца (может посылать/принимать дублированные фреймы).
- RedBox — также как и в PRP RedBox позволяет подключить устройство, имеющее один Ethernet-интерфейс, к HSR-сети. Устройство, которое находится за RedBox’ом, видится для остальных устройств как DAN. Такой узел называется виртуальный DAN или VDAN (Virtual DAN).
- QuadBox – также HSR вводит один новый элемент — QuadBox. Это устройство, имеющее четыре HSR-порта. Оно позволяет объединять два HSR-кольца. В каждом кольце QuadBox выполняет роль DAN и может пересылать данные из одного кольца в в другое.
Пример использования QuadBox
Структура DAN
Для PRP и для HSR структура DAN похожа. Каждый DAN имеет два интерфейса, действующих параллельно и подключенных к верхнему уровню одного коммуникационного стека через так называемый уровень LRE — link redundancy entity. На данном уровне выполняются все функции резервирования.
Оба интерфейса DAN имеют одинаковые MAC-адреса и один IP-адрес. Это позволяет сделать резервирование прозрачным для верхнего уровня. Особенно важен тот факт, что это позволяет использовать протокол ARP для DAN также, как и для любого нерезервированного узла.
Однако, конечно, в структуре DAN для PRP и для HSR имеются и нюансы.
PRP — структура DAN
Когда с верхнего уровня посылается фрейм, LRE дублирует его и посылает оба пакета через порты практически одновременно. Оба фрейма передаются параллельно через две сети с разными задержками. В идеальной ситуации они доставляются на узел назначения с минимальной разницей во времени. При получении LRE приемника передает на верхний уровень первый принятый фрейм, а второй отбрасывает.
LRE создает дублированные фреймы при отправке и обрабатывает их при получении. Данный уровень, по отношению к верхнему уровню, представляет собой обычный интерфейс нерезервированного сетевого адаптера. LRE выполняет две задачи: обработка дублированных фреймов и управление резервированием. Для реализации управления LRE добавляет к каждому фрейму 32-битный трейлер контроля резервирования (redundancy control trailer — RCT) и удаляет его при получении фрейма.
Передача данных между двумя DAN в PRP
HSR — структура DAN
Фрейм, присланный с верхнего уровня, дублируется уровнем LRE, и пакеты посылаются через порт A и порт B практически одновременно. (1 и 2 на схеме).
Приемник при получении фрейма передает его на уровень LRE, а также перенаправляет на другой порт и передает дальше в кольце. (3, 4).
Если фрейм приходит на отправитель, то дальше этот фрейм не передается, а уничтожается (5, 6).
На уровень LRE приходят оба фрейма, но на верхний уровень передается тот, который был прислан быстрее, а дублированный фрейм отбрасывается.
LRE добавляет к каждому фрейму 48-битный HSR-тег (сродни добавлению VLAN-тега) и удаляет этот тег при получении.
Передача данных между двумя DAN в HSR
Взаимодействие между SAN и DAN
В PRP SAN может быть подключен к любой сети — LAN A или LAN B, но такой узел не поддерживает функций резервирования. Поэтому SAN, подключенный к одной сети, не сможет обмениваться данными с другим подобным узлом, подключенным ко второй сети. Для взаимодействия с SAN DAN генерирует специальные фреймы. Эта необходимость вызвана тем, что SAN в обычном фрейме от резервированного устройства должен игнорировать RCT, что сделать не представляется возможным, так как SAN не может отличить RCT от обычного блока данных IEEE 802.3. В свою очередь, DAN понимает, что отправляет фрейм на SAN и не добавляет RCT в фрейм. Он просто пересылает один фрейм с верхнего уровня на тот интерфейс, к которому подключен SAN. Другими словами, если DAN не может определить, что обменивается данными с другим DAN, то он не добавляет RCT в фрейм.
В HSR SAN не может быть подключен напрямую к сети. Его можно подключать исключительно через RedBox
Режимы работы DAN
При работе с дублированными фреймами, принимаемыми на обоих интерфейсах (в случае их исправности), DAN необходимо принять один из фреймов, а второй отбросить. В PRP есть два метода обработки:
- Duplicate accept — метод, при котором оба пришедших фрейма принимаются и перенаправляются на верхний уровень.
- Duplicate discard — метод, при котором узел-приемник считывает информацию из RCT пришедшего фрейма для того чтобы определить, какой фрейм отбрасывать.
Для HSR рассмотрим наиболее популярные режимы U и X
Duplicate accept
DAN, работающий в данном режиме не отбрасывает ни один из фреймов при обработке на канальном уровне.
Фреймы отправляются в LAN A и LAN B без RCT. LRE приемника просто перенаправляет оба фрейма на верхний уровень, предполагая, что при дальнейшей передаче дубликаты будут уничтожены (в IEEE 802.1D четко прописано, что протоколы верхнего уровня должны уметь обрабатывать дублированные фреймы).
Например, протоколы TCP и UDP имеют высокий уровень устойчивости к дублированным фреймам.
Данный метод очень прост в реализации, но имеет серьезный недостаток — он не предоставляет никаких возможностей контроля сети, т.к. никаким образом не отслеживается корректность приема обоих фреймов.
Duplicate discard на канальном уровне
При использовании второго метода в фрейм добавляется поле, состоящее из четырех октет — RCT (redundancy control trailer). Трейлер добавляется на уровне LRE, когда фрейм принимается от верхнего уровня. RCT состоит из следующих параметров:
- 16-битный номер последовательности;
- 4-битный идентификатор сети, 1010 (0xA) для LAN A и 1011 (0xB) для LAN B;
- 12-битный размер фрейма.
Из-за добавления к фрейму RCT-трейлера его размер получается больше максимального размера фрейма, определенного в стандарте IEEE 802.3-2005. Для передачи данных внутри сети с PRP оборудование должно быть сконфигурировано для передачи данных размером 1496 октет. Из-за этого не каждый коммутатор подходит для использования в LAN A или LAN B.
Фрейм с добавленным RCT
Каждый раз, когда канальный уровень посылает фрейм на какой-то определенный адрес, отправитель увеличивает номер последовательности для соответствующего узла и отправляет идентичные фреймы через оба интерфейса.
Узел-приемника должен определить дубликаты, основываясь на информации из RCT.
Алгоритм метода Duplicate discard
Приемник предполагает, что фреймы, присылаемые от любого источника, работающего по протоколу PRP, посылаются последовательно с постоянно возрастающим номером. Номер последовательности, который ожидается у следующего фрейма хранится в переменных ExpectedSeqA и соответственно ExpectedSeqB.
При приеме, корректность последовательности может быть проверена при помощи сравнения значения ExpectedSeqA (ExpectedSeqB) c номером последовательности полученного фрейма, хранящемся в переменной currentSeq в RCT. При положительном результате, переменная ExpectedSeq устанавливается на один больше, чем currentSeq для того, чтобы далее можно бы было выполнять корректную проверку на данной линии.
Интервал отбрасывания фрейма (drop window)
Для обоих интерфейсов существует динамический интервал отбрасывания фрейма (sliding drop window) для парных номеров последовательности. Верхней границей данного интервала является ExpectedSeq (следующий ожидаемый номер последовательности на данном интерфейсе), исключая само данное значение, а нижней границей данного интервала является startSeq (наименьший номер последовательности, при котором происходит отбрасывание дублированного фрейма с таким номером последовательности).
После проверки правильности номера последовательности, приемник решает отбрасывать данный фрейм или нет. Предположим, что LAN A имеет ненулевой размер интервала отбрасывания фрейма (Рис.5). Фрейм из LAN B, чей номер лежит в данном интервале, будет отброшен. Все остальные фреймы из LAN B будут приняты и отправлены на верхний уровень.
Отбрасывая фрейм из LAN B, уменьшается размер интервала LAN A, т.к. после получения данного фрейма не ожидается никаких фреймов с меньшим номером на данном интерфейсе. Соответственно startSeqA устанавливается на один больше, чем currentSeqB. При этом размер интервала отбрасывания фрейма LAN B сбрасывается до 0 (startSeqB = expectedSeqB), т.к. очевидно, что фреймы LAN B “отстают” от LAN A и никакие фреймы из LAN A не должны быть отброшены.
Уменьшение интервала LAN A после отбрасывания фрейма из LAN B
В ситуации на рис.7, когда несколько фреймов из LAN A приходят подряд, но из LAN B не приходит ничего, то они принимаются, т.к. их currentSeq находится вне интервала отбрасывания фрейма LAN B и интервал LAN A увеличивается на одну позицию. Если фреймы из LAN A продолжают приходить, а из LAN B по прежнему ничего не приходит, при достижении максимального размера интервала, startSeqA начинает также увеличиваться на единицу.
Когда принимаемый фрейм находится вне интервала отбрасывания фрейма другого LAN, то этот фрейм сохраняется, а размер интервала данного интерфейса устанавливается равным 1, что означает, что только фрейм из другого LAN с таким же номером последовательности будет отброшен, в то время как drop window другого интерфейса устанавливается равным 0, что означает, что ни одного фрейма не будет отброшено (Рис.7).
Фрейм из LAN B не был отброшен
Наиболее общая ситуация — когда оба интерфейса синхронизированы и размер обоих интервалов равен 0 (Рис.8), что означает, что будет принят фрейм того интерфейса, который придет первее и интервал данного интерфейса будет увеличен до 1, что позволит отбросить фрейм от другого интерфейса с таким же номером последовательности.
Синхронизированные LAN
Из-за наличия идентификатора LAN в RCT, дублированные фреймы различаются на один бит (и имеют разные контрольные суммы). Приемник проверяет принадлежность фрейма к интерфейсу (т.е. проверяет, что фрейм с идентификатором LAN A пришел на интерфейс A). Приемник не отбросит данный фрейм, т.к. он может содержать полезную информацию в блоке данных, но в этом случае будет увеличен на единицу счетчик cntWrongLanA или cntWrongLanB. Так как подобные ошибки не разовые (перепутаны местами LAN A и LAN B), то счетчик будет возрастать постоянно.
Передача HSR-трафика на канальном уровне
При передаче данных внутри HSR-сети к каждому фрейму добавляется HSR-тег.
HSR-тег состоит из следующих параметров:
- 16-битного HSR Ethertype
- 4-битного индикатора направления (path indicator)
- 12-битного размера фрейма
- 16-битного номера последовательности
Отправитель вставляет одинаковые номера последовательности отправляемым дублированным фреймам и затем инкрементирует номер последовательности для каждой посылки, отправленной с данного узла.
Приемник отслеживает номера последовательности всех фреймов от каждого источника, от которого он принимает данные (источники он различает по MAC-адресу). Если фреймы приходят с разных линий и имеют одинаковый источник и номер последовательности, то один из них принимается, а второй отбрасывается.
Для контроля сети, на каждом устройстве ведется таблица всех узлов в сети, от которых он принимает данные. Это позволяет обнаружить исчезновение узлов и ошибки на шине.
Узел определяет фрейм, который он отправил по источнику и по номеру последовательности.
Фрейм с добавленным HSR-тегом
Узел HSR никогда не отбрасывает фрейм, который он ранее не получал. Узел определяет практически все дублированные фреймы, но в случае, если их немного, он их не удаляет, т.е. фрейм просто проходит все кольцо и уничтожается на отправителе.
В стандарте алгоритм определения дублированных фреймов не определен. В качестве возможных методов могут быть использованы хэш-таблицы, очереди и отслеживание номеров последовательности.
Режим U
В данном режиме, узел, который принимает фрейм, уничтожает дубликат и не позволяет ему распространяться дальше. В случае, если фрейм все-таки были передан далее, то он уничтожается на следующих узлах. Данный режим позволяет разгрузить кольцо от Unicast-трафика.
На схеме красными стрелками обозначены пакеты с HSR-тегом, отправленные с порта “А” (в дальнейшем — фрейм “А”).
Зелеными стрелками обозначены пакеты с HSR-тегом, отправленные с порта “В” (в дальнейшем — фрейм “В”).
Пустыми стрелками обозначен отброшенный трафик, т.е. фреймы, которые бы передавались при обычной работе, но в данном режиме были отброшены.
Крестом обозначается удаление трафика из кольца (в любом случае).
Режим X
В данном режиме узел не передает фрейм дальше и отбрасывает его, если такой фрейм был получен с другого направления.
Например, DAN 1 на изображении не передаст дальше фрейм “B”, т.к. он уже получил фрейм “A”, а DAN 2 не будет передавать далее фрейм “A”, т.к. уже получил фрейм “B”.
В случае, если в алгоритме произошла где-то ошибка и фреймы были переданы далее, то они будут отброшены на следующих узлах или на узле, на котором они были созданы.
Режим X не применим для сообщений PTP и для передачи supervision frame.
Контроль сети
PRP
Приемник проверяет, что все фреймы приходят последовательно и корректно принимаются на обоих каналах. Он поддерживает счетчики ошибок, которые можно прочитать, например, через SNMP.
Все устройства поддерживают таблицы узлов, с которыми они обмениваются данными. В этих таблицах содержится информация о времени, когда последний фрейм был отправлен или получен от конкретного узла и другую информацию, касающуюся протокола PRP.
В то же время, данные таблицы позволяют обнаружить соединения, в которых необходимо синхронизировать номера последовательности, а также обнаружить нарушенные последовательности и пропавшие узлы.
Диагностика основана на том, что каждый DAN периодически посылает диагностический фрейм (supervision frame), который позволяет проверить целостность сети и наличие узлов. В то же время данные фреймы позволяют проверить какие устройства выступают в качестве DAN, определить их MAC-адреса и в каком режиме они работают — duplicate accept или duplicate discard.
HSR
Каждый узел постоянное проверяет все линки.
Каждый узел периодически посылает диагностический фрейм (на оба порта), содержащий информацию о состоянии узла. Этот фрейм принимается всеми узлами, включая отправителя. Когда отправитель принимает собственное диагностическое сообщение, то выполняется проверка целостности физического канала.
Интервал посылки диагностического фрейма сравнительно большой (несколько секунд), т.к. он не требуется для обеспечения резервирования, а нужен только для диагностических целей.
Все узлы заносят в таблицу всех партнеров, которых удалось обнаружить, и регистрируют время, когда узел последний раз был активен, а также все пропущенные фреймы и фреймы, присланные не последовательно.
Все произошедшие изменения топологии также регистрируются и вся информация может быть получена по SNMP.
HSR и PRP: плюсы и минусы
Заключение
Нельзя сказать, что один протокол лучше другого — они созданы немного для разных применений. И HSR, и PRP позволяют организовать бесшовное резервирование сети, но HSR позволяет создавать более бюджетные решения. Но подобная экономичность влечет за собой сложности, т.к. сеть на основе HSR достаточно сложно масштабировать, и применения не очень гибкие. Низкая гибкость обуславливается ограниченной топологией (кольцо, сопряжение колец), а также плохой совместимостью протокола с другими технологиями. Поэтому HSR лучше подходит для резервирования небольших систем и интеграции в большую сеть. Организовать резервирование всей сети на основе HSR достаточно проблематично. PRP же, в свою очередь, является решением более дорогим, но позволяющим организовать достаточно масштабную сеть, которую в дальнейшем можно будет расширять без проблем, т.к. данный протокол дает возможность удобно интегрировать практически любые технологии и реализовывать совершенно разные топологии.
Найти решение
