Развитие SDH сетей.

Д.А. Климов

Источник: http://http://www.conf.mirea.ru/pdf/m4/45.pdf

До недавнего времени технология SDH в основном использовалась для транспор тировки агрегированных голосовых сигналов, частных линий frame relay и ATM сервисов. Рост этих высокодоходных услуг в течение многих лет привел к широкомасштабному развертыванию городских и магистральных SDH сетей по всему миру.
В настоящее время потребность в сервисах сместилась с традиционных сервисов к услугам передачи IP/Ethernet. Этот сдвиг в требованиях произошел в основном по двум главным причинам. Во-первых, корпоративные пользователи показали, что им необходим надежный транспорт для сервисов Ethernet. Во-вторых, Ethernet стал избранной транспортной технологией уровня 2, как для корпоративных подключений, так и для сетей доступа. В дополнение к конвергенции голоса, видео и данных (например, сети «три-в-одном»), Ethernet соединения теперь используются для доставки критически-важных сервисов, что делает степень доступности сервиса в 99,999% абсолютно необходимым требованием для таких пользователей.
Стандарт SDH изначально не был предназначен для передачи таких сервисов как Ethernet, таким образом, попытка передачи пакетных сервисов имеет свои ограничивающие факторы, а именно:
  1. скорости передачи традиционной SDH не совпадают со скоростямисо скоростями работы пакетных интерфейсов, таких как Ethernet и Fibre Channel. Приведем приблизительные значения скоростей в порядке возрастания: 2 МБ/с, 3 МБ/с, 6 МБ/с, 34 МБ/с, 45 МБ/с, 139 МБ/с, 155 МБ/с, 622 МБ/с, 2.5 ГБ/с и 10 ГБ/с. Скорости передачи, лежащие между этими значениями, могут быть переданы только с использованием следующего большего значения из списка, что является неэффективным расходованием пропускной способности;
  2. традиционная SDH не имеет встроенных возможностей для динамической подстройки пропускной способности: Для того, что бы эффективно использоват пропускную способность необходимо иметь возможность ее изменения, основываясь на времени дня или других факторах. Например: финансовой организации может потребоваться большая полоса пропускания только в рабочие часы. Если эта организация была напрямую подключена к SDH сети, то вся полоса была бы занята все время, даже ночью и в выходные дни;
  3. традиционная SDH не имеет общей схемы преобразования данных: Frame Relay, ATM и др. являются преобладающими технологиями для доставки серви- сов по традиционным сетям SDH. Наиболее современная реализация доставки - Ethernet over LAPS (также известная как Х.86) появилась для доставки сервисов Ethernet по традиционным сетям SDH. Основной проблемой для всех этих тех- нологий является их сильная зависимость от клиентов и сервисов. К тому же, они не имеют обобщенной схемы адаптации для широкого диапазона сервисов данных таких как: Ethernet, Fibre Channel, IP/PPP и т.д.).
Растущая необходимость в надежной транспортной среде для передачи пакетных сервисов привела к «возрождению» SDH. Принимая во внимание фундаментальную надежность технологии и огромные капитальные вложения, которые уже были сдe ланы, провайдеры искали пути для использования своей существующей SDH инфраструктуры для выполнения задач по удовлетворению растущих потребностей в Ethernet сервисах.
В результате, в 1999 году была начата работа внутри комитетов по стандартизации ITU-T и ANSI, целью которой была выработка технологии, которая может помочь дальнейшему развитию сетей SDH и предложить эффективное средство для транспортировки пакетных сервисов по этим сетям. Их ответом было определение и ратификация трех ключевых технологий, которые и формируют основу SDH Следующего поколения: Обобщенная Процедура Формирования Кадров (generic framing procedure CFP), Виртуальная конкатенация (virtual concatenation - VCAT) и Схема Подстройки Пропускной способности Линии (link-capacity-adjustment scheme - LСAS).
Обобщенная процедура формирования кадров
Процедура GFP (Generic Framing Procedure - основная процедура фреймирования), согласно рекомендации ITU-T G.7041/Y.1303 [1], была разработана для того, чтобы обеспечить общий механизм адаптации трафика пользователя, передаваемого через транспортную сеть с верхних уровней модели OSI (МВОС), перед тем, как инкапсулировать его в полезную нагрузку фреймов SDH.
Трафик пользователя может быть двух типов, которые требуют соответственно два различных режима инкапсуляции:
  1. GFP-F (Frame-Mapped GFP) - основная процедура фреймирования с отображением кадров - режим инкапсуляции GFP, ориентированный на использование протокольного блока данных (PDU) кадров типа IP/PPP или MAC-кадров Ethernet (типа E, FE и GE). В этом случае отдельный кадр клиентского (пользовательского) трафика инкапсулируется, т.е. отображается, или упаковывается, в полезную нагрузку одного кадра GFP;
  2. GFP-T (Transparent GFP) - прозрачная основная процедура фреймирования режим инкапсуляции GFP, ориентированный на применение блокового кодирования потока данных с постоянной битовой скоростью, например потоков, формируемых для прохождения через интерфейсы типа Fiber Channel, ESCON/FICON, или же потоков данных, формируемых технологиями Ethernet (GE и 10GE). В этом случае последовательность символов-данных пользователя отображается в эффективные кодовые блоки, инкапсулируемые в полезную нагрузку одного GFP-кадра.
Формат клиентского GFP-кадра
В составе клиентского GFP-кадра можно выделить (грубо) два блока: основной заголовок и область полезной нагрузки (Рис.2, левый пунктирный столбец). Заголовок состоит из двух полей: индикатора длины клиентского PDU – PLI (Payload Indication) и поля контроля ошибок основного заголовка – cHEC (Header Error Control), фактически реализующего хорошо известную процедуру CRC-16. Полезная нагрузка состоит из трех полей: заголовка полезной нагрузки – PLH (Payload Header), поля клиентской полезной нагрузи – CPL (Client Payload), куда в нашем случае загружается MAC-кадр Ethernet, и необязательного поля контрольной последовательности кадра – FCS (Frame Check Sequence), фактически реализующего известную процедуру CRC-32. Основной заголовок допускает независимое от содержимого PDU верхних уровней выравнивание кадра GFP.
Поле PLI (2 байта) содержит двоичный эквивалент числа байтов (октетов), определяющих емкость полезной нагрузки. Минимальная емкость PL равна 4 байтам, она может содержать только PLH.
Поле cHEC (2 байта) содержит код контроля ошибок основного заголовка CRC-16, позволяющего исправлять его одиночные ошибки и обнаруживать кратные ошибки. Кроме этого основной заголовок дополнительно кодируется (скремблируется) для улучшения устойчивости процедуры выравнивания кадра GFP и обеспечения достаточного числа переходов 0-1 и 1-0 при передаче пустых кадров IF (Idle Frame).
Область полезной нагрузки служит для передачи протокольных данных верхних уровней и имеет переменную длину от 4 до 65535 байтов. Она состоит из двух общих полей: заголовка PLH (4–64 байта) и полезной нагрузки длиной от 0 до 65535-Х байтов, которая зависит от переносимых приложений и должна быть не меньше 1600 байтов. Заголовок PLH имеет переменную длину (4–64 байта), чтобы поддержать процедуры административного управления (менеджмента), характерные для верхних уровней клиентских приложений. PLH состоит из двух обязательных полей длиной 2 байта: поля тип заголовка (Type) и поля контроля его ошибок (tHEC), а также дополнительного поля расширения заголовка (EXH) переменной длины (0–58 байтов) и поля контроля его ошибок (eHEC) длиной 2 байта (Рис.2).
Наличие поля расширения заголовка (его общий формат имеет длину 0–60 байтов) и поля FCS для нагрузки GFP определяется полем Type, которое, в свою очередь, делится на несколько полей, описывающих не только типы кадров GFP, но и различные сервисы в случае мультисервисного обслуживания. Эти поля: PTI, PFI, EXI и UPI (Рис.2) несут следующую функциональную нагрузку:
  1. PTI (Payload Type Identifier) – идентификатор типа нагрузки (3 бита) – определяет в настоящее время только два типа нагрузки: PTI=000 для кадров данных пользователя (UD) и PTI=100 для кадров административного управления со стороны пользователя (CM);
  2. PFI (Payload FCS field Identifier) – указатель наличия поля FCS для нагрузки GFP (1 бит): PFI=1, если FCS присутствует, и PFI=0, если FCS отсутствует;
  3. EXI (Extension head Identifier) – идентификатор расширенного заголовка (4 бита) – определяет в настоящее время только три типа расширенного заголовка: EXI=0000 для нулевого расширения, EXI=0001 для кадра с топологией "линейная цепь" и EXI=0010 для кадра кольцевой топологии;
  4. UPI (User Payload Identifier) – идентификатор нагрузки пользователя (8 битов) определяет тип нагрузки, переносимой в поле информационной полезной нагрузки GFP. Этот тип нагрузки зависит от типа кадра данных пользователя, инкапсулируемого в GFP, а он, в свою очередь, определяется полем PTI. Определяемые идентификатором UPI значения кадров данных пользователя (т.е. кадров, соответствующих значению PTI=000).

Рис. 1. Формат клиентского GFP-кадра.

Топология "линейная цепь" рассматривается этим стандартом применительно к отдельному пользователю, как та же логическая "точка-точка", но пользователей может быть несколько. Это значит, что требуется процедура их агрегации (объединения, например, с помощью мультиплексирования) в один транспортный канал и дополнительная идентификация отдельного пользователя внутри этого транспортного канала. В результате такой кадр состоит из минимального PLH (4 байта: 5–8, Рис.2) и 4-байтного расширения: байта идентификации канала – CID (байт 9), резервного байта (10) и двух байтов eHEC (11–12), содержащих CRC-16 для контроля ошибок поля расширения заголовка. Байт CID позволяет идентифицировать 256 (28) каналов пользователей в агрегатном (транспортном) канале. Кольцевая топология в стандарте [1] пока не проработана и отложена для последующего рассмотрения.
Управляющие кадры GFP
Для управления GFP-соединением должны использоваться управляющие кадры. В настоящее время описан только один тип такого кадра [1] – пустой кадр IF. Он имеет длину четыре байта и фактически имитирует основной заголовок GFP, в котором поля PLI и cHEC (Рис.2) установлены нулевыми (область полезной нагрузки отсутствует).
Пустые кадры используются как кадры заполнения в процессе адаптации скорости (емкости) источника данных при инкапсуляции потока данных в GFP, если емкость транспортного канала среды передачи выше, чем требуется для размещения клиентского сигнала.
Процедура фреймирования данных пользователя в кадр GFP на входе может быть в общем случае представлена как процедура мультиплексирования потока байтов клиентских сигналов и пустых кадров (при отсутствии сигналов), управляемая процессом адаптации скорости сигналов и менеджментом со стороны клиента. На выходе мультиплексора агрегированный поток скремблируется раздельно для основного заголовка и полезной нагрузки. На выходе осуществляется логически обратный процесс.
Инкапсуляция кадров GFP в фреймы SDH
Поток кадров GFP упаковывается в контейнер C-n, где n=11, 12, 2, 3, 4, 4-Xc, 11/12/2/3/4-Xv, причем так, что границы байтов кадров GFP оказываются выровненными с границами такого контейнера C-n. Этот контейнер затем упаковывается в виртуальный контейнер VC-n, к которому добавляется соответствующий заголовок POH. Однако, учитывая, что емкость контейнера C-n не является целым кратным длины кадра GFP, какой-то из кадров может пересечь границу одного из фреймов C-n (аналогично тому, что имеет место при упаковке ячеек ATM во фреймы SDH). Вместе с тем, благодаря процедуре адаптации, основанной на вставке пустых кадров, емкость прибывающего потока кадров GFP идентична емкости полезной нагрузки VC-мультиконтейнера.
Еще раз подчеркнем, что процедура адаптации скорости и скремблирование осуществляется на первом этапе – этапе фреймирования потока Ethernet в кадры GFP, а не на втором этапе – этапе упаковки кадров GFP во фреймы SDH. Этим, главным образом (если забыть о гибкости и универсальности), и отличаются процедуры GFP и LAPS, а не тем, что GFP позволяет избежать процедуры стаффинга [3]. Вставка пустых ячеек на этапе адаптации мало, чем отличается от стаффинга, используемого в процедуре LAPS [2].
Наиболее важным преимуществом процедуры GFP является ее гибкость и универсальность, позволяющие дополнительно поддерживать трафик данных, использующий интерфейсы типа: FICON, ESCON/SBCON, а также трафик цифрового видеовещания (DVB).
Заключение
Оптимизация существующих сетей SDH для передачи пакетного трафика – характерная особенность оборудования нового поколения SDH. При решении этой задачи пришлось столкнуться с неизбежной проблемой адаптации асинхронного трафика к синхронному характеру передачи в сетях SDH. Наиболее ярко эта проблема проявилась при попытке приспособить такие сети к передаче трафика Ethernet.
Первые механизмы адаптации допускали, например, упаковку GE в контейнер STM-16 (VC-4-16c) SDH, но это позволяло использовать лишь 42% полезной нагрузки (PL). Затем данная схема была доработана и допускала упаковку GE в PL конкатенированного виртуального контейнера VC-4-8c (SDH). При этом указывалась дополнительная информация, позволяющая определить тип полезной нагрузки и идентифицировать клиента путем дополнительного контроля заголовка. Однако схема не была универсальной и не допускала гибкого использования полосы пропускания сетей. Выяснилось, что из всех Ethernet-технологий: E, FE, GE, 10GE только поток 10GE с интерфейсом WAN может быть непосредственно отображен на полезную нагрузку фреймов SDH (STM-64 и выше), так как в стандарте на интерфейс 10GE был специально предусмотрен подуровень (WIS – WAN Interface Sublayer) и процедура фреймирования, позволившие редуцировать линейную скорость 10GE до уровня STM64. Остальные технологии требовали использования определенного механизма адаптации для отображения сервиса Ethernet на PL фреймов STM-N.
Следующая генерация механизмов адаптации включала технологии LAPS (ITUT X.86) и GFP. Последний механизм адаптации оказался наиболее гибким (так как позволял использовать виртуальную конкатенацию VCAT и процедуру динамической настройки емкости звена связи LCAS) и эффективным (так как допускал как пакетную инкапсуляцию с фреймированием – GFP-F, так и инкапсуляцию кодированного потока, рассчитанную на прозрачную передачу потока через сеть – GFP-T). Согласно этой схеме, GE-сигнал отображается с помощью GFP-F и VCAT на полезную нагрузку STS3c-7v или STS-1-21v (в сети SONET) и на VC-4-7v или VC-3-21v (в сети SDH). Применение процедуры LCAS позволило гибко изменять емкость сети SDH, используемой для передачи Ethernet трафика, за счет включения или выключения емкости контейнера, используемого в схеме виртуальной конкатенации. Тип используемого при этом контейнера (VC-4, VC-3 или VC-12) определял гранулярность схемы изменения емкости звена связи (140, 34 или 2 Мбит/с). Оказалось, что при передаче Ethernet и Fast Ethernet большей эффективности использования полосы можно достичь при гранулярности VC-12, тогда как при передаче GE и 10GE вполне можно довольствоваться гранулярностью VC-3 и VC-4.
Та же процедура LCAS позволяет на практике передавать трафик GE (1 Гбит/с) по сети SDH уровня STM-4 (622 Мбит/с), ограничивая суммарную емкость сцепленных с помощью виртуальной конкатенации контейнеров на уровне 600 Мбит/с, что достаточно при реализации большинства приложений GE.

Литература

  1. ITU-T G.7041/Y.1303. Generic Framing Procedure (GFP) (12.01, 3.03); Corr. 1 (12.03); Amd.1,2 (6.02, 3.03).
  2. www.exfo.com
  3. Бакланов И. NGSDH: успех неизбежен. Ч.1. Новые принципы измерений в совре- менных системах передачи данных. – Connect! Мир связи, 2004, №11, с. 164–167.
  4. ITU-T G.707/Y.1322. Network Node Interface for the Synchronous Digital Hierarchy (SDH) (96; 10.00; 11.01; 8.03; 12.03); Corr. 1, 2, 3 (3.01, 11.01, 3.03); Err.1 (9.02); Amd.1, 2 – Internet protocol Aspects – Transport (11.01; 8.02); Amd.3 (4.03).