ЖУРНАЛ СТА 1/2012

логическое существование только одного пути доставки сообщения в конкретный момент времени при физическом наличии нескольких. Из существующих физических каналов связи один выбирается основным, остальные ждут в резерве. Такой принцип был впервые приме- нён в протоколе STP, который отсле- живал состояние каналов связи и при обнаружении обрывов направлял тра- фик с отказавшего канала на резерв- ный. Это означает, что связь теряется на некоторое время, пока обрыв обна- ружится, а новый канал передачи дан- ных будет активирован. В зависимости от размеров сети и сложности её топо- логии время восстановления связи может быть разным и заранее его опре- делить нельзя. На основе протокола STP можно сформулировать основные требования к протоколам резервирования Ethernet в промышленной среде. 1. Определённое время восстановления сети: период времени от момента разрыва основного соединения до восстановления связи по резервному соединению должен быть меньше некой допустимой величины. 2. Требования к сети: для протокола должны быть определены допусти- мая топология сети, максимальное количество узлов (коммутаторов), типы соединений и пр. 3. Протокол должен базироваться на стандартизированном методе или алгоритме. Только так можно гаран- тировать совместимость с сетевым оборудованием и другими сетевыми протоколами. Первое требование традиционно для промышленных сетей, работающих в реальном времени. Протокол резерви- рования может быть задействован, если максимально возможное время восстановления удовлетворяет требо- ваниям процесса или приложения, для которого сеть передачи данных ис- пользуется. Т ЕХНОЛОГИИ И РЕШЕНИЯ : ПРОТОКОЛЫ RSTP/MSTP В последние годы упомянутый про- токол STP был вытеснен своим более быстрым последователем – протоко- лом RSTP (Rapid Spanning Tree Pro- tocol), описанным в стандарте IEEE 802.1D-2004 [3]. Данный протокол под- держивает множество различных топо- логий и базируется на том, что из всех сетевых соединений выделяется древо- видная структура, так что между любы- ми двумя узлами сети в каждый момент времени существует единственный маршрут передачи данных. Все соеди- нения, не вошедшие в активное «дере- во», считаются резервными и не актив- ны до изменения топологии. Протокол базируется на мостовых соединениях (BPDU – Bridge Protocol Data Units), среди которых выбирается корневой мост (соединение коммутатор-комму- татор). Всё остальное «дерево» строится от него. Любое изменение в активном «дереве» означает изменение в составе BPDU с рассылкой специального BPDU-кадра по узлам сети, после чего те активируют резервные маршруты для трафика. В протокол встроена защита от перегрузки сети данными кадрами, которая может привести к увеличению времени восстановления. Протокол RSTP поддерживает боль- шое количество узлов и обеспечивает время восстановления связи порядка 1 секунды. Это время во многом зави- сит от места возникновения обрыва связи в сети, поэтому не может быть чётко определено заранее. Данный существенный недостаток можно обойти, если ограничить топо- логию сети кольцевой структурой. Тем самым можно добиться соблюдения времени восстановления сети порядка 100 мс и меньше. MSTP – новая итерация описанного протокола резервированных «деревь- ев», и работает она по тому же принци- пу [4]. Если RSTP работает вне зависи- мости от виртуальных сетей VLAN, то структуры MSTP, наоборот, суще- ствуют в составе виртуальной сети и таким образом обеспечивают больше удобств и свобод в плане возможных топологий и распределения нагрузки. Оба протокола совместимы между собой и могут быть реализованы внут- ри одной сети. Р ЕЗЕРВИРОВАННЫЕ КОЛЬЦА Кольцевая топология удобна прежде всего тем, что с ней достигается опре- делённое и гарантированное время восстановления связи после сбоя, учи- тывающее количество коммутаторов в кольце. Стандарт IEC 62439-1 описы- вает пример расчёта времени восста- новления для кольца, а также дополни- тельные ограничения (например, RSTP не может быть сконфигурирован на портах коммутатора, не задейство- ванных в кольце). Однако RSTP не был разработан для кольцевого резервиро- вания, поэтому уступает специализи- рованным протоколам типа MRP. В коммутаторах Hirschmann реализова- на поддержка обоих протоколов, и, хотя предписаний по их совместному применению нет, использовать в этом случае лучше MRP. MRP – СТАНДАРТИЗИРОВАННОЕ РЕЗЕРВИРОВАННОЕ КОЛЬЦО Протокол MRP был специально раз- работан для промышленных приложе- ний. Он описан в стандарте IEC 62439-2 для промышленных сетей Ethernet с высокой степенью доступности. MRP поддерживает только кольцевую топологию сети с количеством комму- таторов не более 50, гарантируя зара- нее определённое время восстановле- ния связи в случае возникновения сбоя. Время восстановления зависит от выбранных параметров протоко- ла MRP и может составлять от 10 до 500 мс, причём максимальное время можно установить заранее. Например, при максимальном времени восстанов- ления, равном 200 мс, типовое значе- ние составит 50–60 мс при средней загрузке сети. Протокол подразумевает объедине- ние в кольцо группы коммутаторов, один из которых берёт на себя роль ведущего (MRM – Media Redundancy Manager). Он контролирует целост- ность кольца, передавая по кольцу тестовые кадры данных в одну сторону и получая их по цепочке с другой сто- роны. Для предотвращения коллизий все данные, кроме тестовых кадров, блокируются на одном из двух кольце- вых портов MRM-коммутатора, обра- зуя фактически линейную топологию сети. Если ведущий коммутатор не получает тестовые кадры, это означает разрыв кольца, в таком случае он раз- блокирует второе соединение, восста- новив передачу данных. Остальные коммутаторы в кольце играют роль ведомых (MRC – Media Redundancy Clients) и передают тесто- вые кадры по цепочке с одного кольце- вого порта в другой. Также ведомые коммутаторы передают ведущему информацию об изменении состояния их портов. Если MRM-коммутатор получил сообщение от MRC-коммута- тора об отказе его кольцевого порта раньше, чем недосчитался тестовых кадров, то он руководствуется этим предупреждением и активирует забло- кированное соединение. Такой подход ОБ ЗОР / П РОМЫШЛ Е ННЫЕ С Е Т И 19 СТА 1/2012 www.cta.ru © СТА-ПРЕСС

RkJQdWJsaXNoZXIy MTQ4NjUy