eng
Выпуск #4/2005
Н.Слепов.
Сети SDH новой генерации и их использование для передачи трафика Ethernet
Сети SDH новой генерации и их использование для передачи трафика Ethernet
Просмотры: 3616
В первой части публикуемой статьи [1], в рамках сетей SDH новой генерации, были рассмотрены механизмы, предложенные адаптировать сети SDH к современному трафику: виртуальная конкатенация (VCAT), динамическая настройка пропускной способности (емкости) звена связи (LCAS), а также общая процедура инкапсуляции LAPS. Их можно использовать для передачи пакетного трафика, генерируемого, например, современной технологией Ethernet. В предлагаемой второй части рассматривается, в частности, другая, более универсальная и современная, процедура инкапсуляции (фреймирования) GFP, которая позволяет упростить передачу пакетного трафика, в том числе и трафика Ethernet, и повысить эффективность его использования.
Процедура GFP
Процедура GFP (Generic Framing Procedure – основная процедура фреймирования), согласно [2], была разработана для того, чтобы обеспечить общий механизм адаптации трафика пользователя, передаваемого через транспортную сеть с верхних уровней модели OSI (МВОС), перед тем, как инкапсулировать его в полезную нагрузку фреймов SDH.
Термин фреймирование понимается здесь обобщенно как отображение потока данных на поле полезной нагрузки кадра-переносчика (GFP) или как отображение кадра GFP на поле полезной нагрузки фрейма-переносчика (SONET/SDH).
Трафик пользователя может быть двух типов, которые требуют соответственно два различных режима инкапсуляции:
· GFP-F (Frame-Mapped GFP) – основная процедура фреймирования с отображением кадров – режим инкапсуляции GFP, ориентированный на использование протокольного блока данных (PDU) кадров типа IP/PPP или MAC-кадров Ethernet (типа E, FE и GE). В этом случае отдельный кадр клиентского (пользовательского) трафика инкапсулируется, т.е. отображается, или упаковывается, в полезную нагрузку одного кадра GFP;
· GFP-T (Transparent GFP) – прозрачная основная процедура фреймирования – режим инкапсуляции GFP, ориентированный на применение блокового кодирования потока данных с постоянной битовой скоростью, например потоков, формируемых для прохождения через интерфейсы типа Fiber Channel, ESCON/FICON, или же потоков данных, формируемых технологиями Ethernet (GE и 10GE). В этом случае последовательность символов-данных пользователя отображается в эффективные кодовые блоки, инкапсулируемые в полезную нагрузку одного GFP-кадра.
Так как нас интересует прежде всего передача пакетного трафика Ethernet (E, FE и GE), учитывая, что трафик 10GE хорошо приспособлен для передачи по сети SDH (см. ниже), то в рамках данной статьи мы ограничимся рассмотрением только режима GFP-F. Он ориентирован на PDU и дает возможность обрабатывать как Ethernet-, так и IP-трафик, и может быть представлен функциональной моделью, приведенной на рис.1 (рассматривается только один клиент и топологическая схема передачи "точка-точка") [2].
В рамках этой модели функция инкапсуляции (и предшествующая ей функция адаптации скорости) потока клиента/пользователя в GFP может работать на уровне звена передачи данных (или на более высоких уровнях). Это значит, что клиентский PDU должен быть получен из сети уровня звена передачи данных (от IP-маршрутизатора или коммутатора Ethernet; см. интерфейсные точки C/C' на рис.1) или через функцию моста/коммутатора/маршрутизатора в транспортном сетевом элементе (TNE – Transport Network Element). В этом последнем случае клиентский PDU принимается, например, через интерфейс Ethernet (см. интерфейсные точки A/A' на рис.1).
Используя эту модель, можно установить соединение между портами A и A'; C и C'; A и C'; C и A'.
Формат клиентского 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).
Поля tHEC и eHEC содержат стандартные циклические коды CRC-16 для защиты целостности контролируемых ими полей Type и EXH и позволяют корректировать все одиночные и выявлять множественные ошибки (пачки).
Наличие поля расширения заголовка (его общий формат имеет длину 0–60 байтов) и поля FCS для нагрузки GFP определяется полем Type, которое, в свою очередь, делится на несколько полей, описывающих не только типы кадров GFP, но и различные сервисы в случае мультисервисного обслуживания.
Эти поля: PTI, PFI, EXI и UPI (см. рис.2) несут следующую функциональную нагрузку:
· PTI (Payload Type Identifier) – идентификатор типа нагрузки (3 бита) – определяет в настоящее время только два типа нагрузки: PTI=000 для кадров данных пользователя (UD) и PTI=100 для кадров административного управления со стороны пользователя (CM);
· PFI (Payload FCS field Identifier) – указатель наличия поля FCS для нагрузки GFP (1 бит): PFI=1, если FCS присутствует, и PFI=0, если FCS отсутствует;
· EXI (Extension head Identifier) – идентификатор расширенного заголовка (4 бита) – определяет в настоящее время только три типа расширенного заголовка: EXI=0000 для нулевого расширения, EXI=0001 для кадра с топологией "линейная цепь" и EXI=0010 для кадра кольцевой топологии;
· UPI (User Payload Identifier) – идентификатор нагрузки пользователя (8 битов) – определяет тип нагрузки, переносимой в поле информационной полезной нагрузки GFP. Этот тип нагрузки зависит от типа кадра данных пользователя, инкапсулируемого в GFP, а он, в свою очередь, определяется полем PTI.
Определяемые идентификатором UPI значения кадров данных пользователя (т.е. кадров, соответствующих значению PTI=000) приведены в табл.1.
Определяемые идентификатором UPI значения кадров административного управления со стороны пользователя (т.е. кадров, соответствующих значению PTI=100) приведены в табл.2.
Поле расширения заголовка PLH вместе с полем eHEC имеет переменную длину (0–60 байтов) и предназначено для поддержки специфичных для разных технологий заголовков звена передачи данных, таких как идентификаторы виртуальных звеньев, адреса источника/назначения, номера портов, классы сервиса, контроль ошибок расширенного заголовка. Тип расширенного заголовка указывается битами поля EXI. В настоящее время определены только три варианта расширенного заголовка. Они используются для поддержки данных, передаваемых по логическому кольцу (EXI=0010), линейной цепи (EXI=0001) и звену связи точка-точка (EXI=0000).
Стандарт [2] фактически проработан только для двух последних топологий. При этом под звеном связи "точка-точка" подразумевается, фактически, выделенный канал для одного пользователя, что не требует какой-то дополнительной идентификации. Это означает, что поле расширения отсутствует, а PLH минимально и состоит из четырех байтов: два первых байта (5-й и 6-й) поля типа Type, два последующих (7-й и 8-й) – типа tHEC (см. рис.2).
Топология "линейная цепь" рассматривается этим стандартом применительно к отдельному пользователю, как та же логическая "точка-точка", но пользователей может быть несколько. Это значит, что требуется процедура их агрегации (объединения, например, с помощью мультиплексирования) в один транспортный канал и дополнительная идентификация отдельного пользователя внутри этого транспортного канала. В результате такой кадр состоит из минимального PLH (4 байта: 5–8, рис.2) и 4-байтного расширения: байта идентификации канала – CID (байт 9), резервного байта (10) и двух байтов eHEC (11–12), содержащих CRC-16 для контроля ошибок поля расширения заголовка. Байт CID позволяет идентифицировать 256 (28) каналов пользователей в агрегатном (транспортном) канале.
Кольцевая топология в стандарте [2] пока не проработана и отложена для последующего рассмотрения.
Управляющие кадры GFP
Для управления GFP-соединением должны использоваться управляющие кадры. В настоящее время описан только один тип такого кадра [2] – пустой кадр IF. Он имеет длину четыре байта и фактически имитирует основной заголовок GFP, в котором поля PLI и cHEC (см. рис.2) установлены нулевыми (область полезной нагрузки отсутствует).
Пустые кадры используются как кадры заполнения в процессе адаптации скорости (емкости) источника данных при инкапсуляции потока данных в GFP, если емкость транспортного канала среды передачи выше, чем требуется для размещения клиентского сигнала. Учитывая процедуру скремблирования Баркера, фактически пустой кадр представлен последовательностью из четырех байтов вида (16-ричное значение байтов показано в нумерации справа налево):
E0 31 AB B6
Другие типы управляющих кадров с PLI=1,2,3 находятся в стадии разработки.
Процедура фреймирования данных пользователя в кадр GFP на входе может быть в общем случае представлена как процедура мультиплексирования потока байтов клиентских сигналов и пустых кадров (при отсутствии сигналов), управляемая процессом адаптации скорости сигналов и менеджментом со стороны клиента. На выходе мультиплексора агрегированный поток скремблируется раздельно для основного заголовка и полезной нагрузки. На выходе осуществляется логически обратный процесс.
При наличии множества портов и множества типов клиентского трафика мультиплексирование осуществляется в режиме покадрового (кадры GFP) интерливинга [3].
Инкапсуляция кадров GFP в фреймы SONET/SDH
Поток кадров GFP упаковывается в контейнер C-n, где n =11, 12, 2 (SONET), 3, 4, 4-Xc, 11/12/2/3/4-Xv, причем так, что границы байтов кадров GFP оказываются выровненными с границами такого контейнера C-n. Этот контейнер затем упаковывается в виртуальный контейнер VC-n, к которому добавляется соответствующий заголовок POH [3]. Однако, учитывая, что емкость контейнера C-n не является целым кратным длины кадра GFP, какой-то из кадров может пересечь границу одного из фреймов C-n (аналогично тому, что имеет место при упаковке ячеек ATM во фреймы SDH [3]). Вместе с тем, благодаря процедуре адаптации, основанной на вставке пустых кадров, емкость прибывающего потока кадров GFP идентична емкости полезной нагрузки VC-мультиконтейнера.
Еще раз подчеркнем, что процедура адаптации скорости и скремблирование осуществляется на первом этапе – этапе фреймирования потока Ethernet в кадры GFP, а не на втором этапе – этапе упаковки кадров GFP во фреймы SONET/SDH. Этим, главным образом (если забыть о гибкости и универсальности), и отличаются процедуры GFP и LAPS, а не тем, что GFP позволяет избежать процедуры стаффинга [4]. Вставка пустых ячеек на этапе адаптации мало чем отличается от стаффинга, используемого в процедуре LAPS [1]. Весь вопрос в том, для каких технологий, когда и как это делается и что получается в результате!
Наиболее важным преимуществом процедуры GFP является ее гибкость и универсальность, позволяющие дополнительно поддерживать трафик данных, использующий интерфейсы типа: FICON, ESCON/SBCON, а также трафик цифрового видеовещания (DVB).
Заключение
Оптимизация магистральных телефонных сетей для передачи пакетизированного трафика – характерная особенность оборудования нового поколения SDH. При решении этой задачи пришлось столкнуться с неизбежной проблемой адаптации асинхронного трафика к синхронному характеру передачи в сетях SDH. Наиболее ярко эта проблема проявилась при попытке приспособить такие сети к передаче трафика Ethernet.
Первые механизмы адаптации допускали, например, упаковку GE в контейнер OC-48/STM-16 (OC-48c/VC-4-16c) SONET/SDH, но это позволяло использовать лишь 42% полезной нагрузки (PL). Затем данная схема была доработана и допускала упаковку GE в PL синхронного транспортного сигнала STS-24c емкостью 1,244 Гбит/с (SONET) или эквивалентного ему конкатенированного виртуального контейнера VC-4-8c (SDH). При этом указывалась дополнительная информация, позволяющая определить тип полезной нагрузки и идентифицировать клиента путем дополнительного контроля заголовка. Эта последняя схема позволяла упаковывать до 8 клиентских каналов GE в синхронные транспортные модули OC-192/STM-64 емкостью 10 Гбит/с. Однако схема не была универсальной и не допускала гибкого использования полосы пропускания сетей.
Выяснилось, что из всех Ethernet-технологий: E, FE, GE, 10GE только поток 10GE с интерфейсом WAN может быть непосредственно отображен на полезную нагрузку фреймов SDH (STM-64 и выше), так как в стандарте на интерфейс 10GE был специально предусмотрен подуровень (WIS – WAN Interface Sublayer) и процедура фреймирования, позволившие редуцировать линейную скорость 10GE до уровня STM-64 [5, 6]. Остальные технологии требовали использования определенного механизма адаптации для отображения сервиса Ethernet на PL фреймов STM-N.
Следует отметить, что и технология 10GE, но с интерфейсом LAN, не может быть непосредственно отображена на полезную нагрузку фреймов SDH (STM-64 и выше), так как этот вариант 10GE требует звена связи емкостью 10,3125 Гбит/с. Аналогичная ситуация будет и с сигналом 10GE, использующим интерфейс WAN, если применяется схема кодирования FEC с упреждающей коррекцией ошибок [5, 6].
Следующая генерация механизмов адаптации включала технологии POS (Packet Over SONET), LAPS (ITU-T X.86) и GFP. Последний механизм адаптации оказался наиболее гибким (так как позволял использовать виртуальную конкатенацию VCAT и процедуру динамической настройки емкости звена связи LCAS) и эффективным (так как допускал как пакетную инкапсуляцию с фреймированием – GFP-F, так и инкапсуляцию кодированного потока, рассчитанную на прозрачную передачу потока через сеть – GFP-T). Согласно этой схеме, GE-сигнал отображается с помощью GFP-F и VCAT на полезную нагрузку STS-3c-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. Слепов Н.Н. Сети SDH новой генерации и их использование для передачи трафика Ethernet. – ЭЛЕКТРОНИКА: НТБ, 2005, №3, с. 56–62.
2. 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).
3. Слепов Н.Н. Современные технологии цифровых оптоволоконных сетей связи. – 2-е изд. исправл. – М.: Радио и связь, 2003.
4. Бакланов И. NGSDH: успех неизбежен. Ч.1. Новые принципы измерений в современных системах передачи данных. – Connect! Мир связи, 2004, №11, с. 164–167.
5. 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).
6. IEEE 802.3-2002 – Local and Metropolitan Area Networks – Specific Requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
Процедура GFP (Generic Framing Procedure – основная процедура фреймирования), согласно [2], была разработана для того, чтобы обеспечить общий механизм адаптации трафика пользователя, передаваемого через транспортную сеть с верхних уровней модели OSI (МВОС), перед тем, как инкапсулировать его в полезную нагрузку фреймов SDH.
Термин фреймирование понимается здесь обобщенно как отображение потока данных на поле полезной нагрузки кадра-переносчика (GFP) или как отображение кадра GFP на поле полезной нагрузки фрейма-переносчика (SONET/SDH).
Трафик пользователя может быть двух типов, которые требуют соответственно два различных режима инкапсуляции:
· GFP-F (Frame-Mapped GFP) – основная процедура фреймирования с отображением кадров – режим инкапсуляции GFP, ориентированный на использование протокольного блока данных (PDU) кадров типа IP/PPP или MAC-кадров Ethernet (типа E, FE и GE). В этом случае отдельный кадр клиентского (пользовательского) трафика инкапсулируется, т.е. отображается, или упаковывается, в полезную нагрузку одного кадра GFP;
· GFP-T (Transparent GFP) – прозрачная основная процедура фреймирования – режим инкапсуляции GFP, ориентированный на применение блокового кодирования потока данных с постоянной битовой скоростью, например потоков, формируемых для прохождения через интерфейсы типа Fiber Channel, ESCON/FICON, или же потоков данных, формируемых технологиями Ethernet (GE и 10GE). В этом случае последовательность символов-данных пользователя отображается в эффективные кодовые блоки, инкапсулируемые в полезную нагрузку одного GFP-кадра.
Так как нас интересует прежде всего передача пакетного трафика Ethernet (E, FE и GE), учитывая, что трафик 10GE хорошо приспособлен для передачи по сети SDH (см. ниже), то в рамках данной статьи мы ограничимся рассмотрением только режима GFP-F. Он ориентирован на PDU и дает возможность обрабатывать как Ethernet-, так и IP-трафик, и может быть представлен функциональной моделью, приведенной на рис.1 (рассматривается только один клиент и топологическая схема передачи "точка-точка") [2].
В рамках этой модели функция инкапсуляции (и предшествующая ей функция адаптации скорости) потока клиента/пользователя в GFP может работать на уровне звена передачи данных (или на более высоких уровнях). Это значит, что клиентский PDU должен быть получен из сети уровня звена передачи данных (от IP-маршрутизатора или коммутатора Ethernet; см. интерфейсные точки C/C' на рис.1) или через функцию моста/коммутатора/маршрутизатора в транспортном сетевом элементе (TNE – Transport Network Element). В этом последнем случае клиентский PDU принимается, например, через интерфейс Ethernet (см. интерфейсные точки A/A' на рис.1).
Используя эту модель, можно установить соединение между портами A и A'; C и C'; A и C'; C и A'.
Формат клиентского 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).
Поля tHEC и eHEC содержат стандартные циклические коды CRC-16 для защиты целостности контролируемых ими полей Type и EXH и позволяют корректировать все одиночные и выявлять множественные ошибки (пачки).
Наличие поля расширения заголовка (его общий формат имеет длину 0–60 байтов) и поля FCS для нагрузки GFP определяется полем Type, которое, в свою очередь, делится на несколько полей, описывающих не только типы кадров GFP, но и различные сервисы в случае мультисервисного обслуживания.
Эти поля: PTI, PFI, EXI и UPI (см. рис.2) несут следующую функциональную нагрузку:
· PTI (Payload Type Identifier) – идентификатор типа нагрузки (3 бита) – определяет в настоящее время только два типа нагрузки: PTI=000 для кадров данных пользователя (UD) и PTI=100 для кадров административного управления со стороны пользователя (CM);
· PFI (Payload FCS field Identifier) – указатель наличия поля FCS для нагрузки GFP (1 бит): PFI=1, если FCS присутствует, и PFI=0, если FCS отсутствует;
· EXI (Extension head Identifier) – идентификатор расширенного заголовка (4 бита) – определяет в настоящее время только три типа расширенного заголовка: EXI=0000 для нулевого расширения, EXI=0001 для кадра с топологией "линейная цепь" и EXI=0010 для кадра кольцевой топологии;
· UPI (User Payload Identifier) – идентификатор нагрузки пользователя (8 битов) – определяет тип нагрузки, переносимой в поле информационной полезной нагрузки GFP. Этот тип нагрузки зависит от типа кадра данных пользователя, инкапсулируемого в GFP, а он, в свою очередь, определяется полем PTI.
Определяемые идентификатором UPI значения кадров данных пользователя (т.е. кадров, соответствующих значению PTI=000) приведены в табл.1.
Определяемые идентификатором UPI значения кадров административного управления со стороны пользователя (т.е. кадров, соответствующих значению PTI=100) приведены в табл.2.
Поле расширения заголовка PLH вместе с полем eHEC имеет переменную длину (0–60 байтов) и предназначено для поддержки специфичных для разных технологий заголовков звена передачи данных, таких как идентификаторы виртуальных звеньев, адреса источника/назначения, номера портов, классы сервиса, контроль ошибок расширенного заголовка. Тип расширенного заголовка указывается битами поля EXI. В настоящее время определены только три варианта расширенного заголовка. Они используются для поддержки данных, передаваемых по логическому кольцу (EXI=0010), линейной цепи (EXI=0001) и звену связи точка-точка (EXI=0000).
Стандарт [2] фактически проработан только для двух последних топологий. При этом под звеном связи "точка-точка" подразумевается, фактически, выделенный канал для одного пользователя, что не требует какой-то дополнительной идентификации. Это означает, что поле расширения отсутствует, а PLH минимально и состоит из четырех байтов: два первых байта (5-й и 6-й) поля типа Type, два последующих (7-й и 8-й) – типа tHEC (см. рис.2).
Топология "линейная цепь" рассматривается этим стандартом применительно к отдельному пользователю, как та же логическая "точка-точка", но пользователей может быть несколько. Это значит, что требуется процедура их агрегации (объединения, например, с помощью мультиплексирования) в один транспортный канал и дополнительная идентификация отдельного пользователя внутри этого транспортного канала. В результате такой кадр состоит из минимального PLH (4 байта: 5–8, рис.2) и 4-байтного расширения: байта идентификации канала – CID (байт 9), резервного байта (10) и двух байтов eHEC (11–12), содержащих CRC-16 для контроля ошибок поля расширения заголовка. Байт CID позволяет идентифицировать 256 (28) каналов пользователей в агрегатном (транспортном) канале.
Кольцевая топология в стандарте [2] пока не проработана и отложена для последующего рассмотрения.
Управляющие кадры GFP
Для управления GFP-соединением должны использоваться управляющие кадры. В настоящее время описан только один тип такого кадра [2] – пустой кадр IF. Он имеет длину четыре байта и фактически имитирует основной заголовок GFP, в котором поля PLI и cHEC (см. рис.2) установлены нулевыми (область полезной нагрузки отсутствует).
Пустые кадры используются как кадры заполнения в процессе адаптации скорости (емкости) источника данных при инкапсуляции потока данных в GFP, если емкость транспортного канала среды передачи выше, чем требуется для размещения клиентского сигнала. Учитывая процедуру скремблирования Баркера, фактически пустой кадр представлен последовательностью из четырех байтов вида (16-ричное значение байтов показано в нумерации справа налево):
E0 31 AB B6
Другие типы управляющих кадров с PLI=1,2,3 находятся в стадии разработки.
Процедура фреймирования данных пользователя в кадр GFP на входе может быть в общем случае представлена как процедура мультиплексирования потока байтов клиентских сигналов и пустых кадров (при отсутствии сигналов), управляемая процессом адаптации скорости сигналов и менеджментом со стороны клиента. На выходе мультиплексора агрегированный поток скремблируется раздельно для основного заголовка и полезной нагрузки. На выходе осуществляется логически обратный процесс.
При наличии множества портов и множества типов клиентского трафика мультиплексирование осуществляется в режиме покадрового (кадры GFP) интерливинга [3].
Инкапсуляция кадров GFP в фреймы SONET/SDH
Поток кадров GFP упаковывается в контейнер C-n, где n =11, 12, 2 (SONET), 3, 4, 4-Xc, 11/12/2/3/4-Xv, причем так, что границы байтов кадров GFP оказываются выровненными с границами такого контейнера C-n. Этот контейнер затем упаковывается в виртуальный контейнер VC-n, к которому добавляется соответствующий заголовок POH [3]. Однако, учитывая, что емкость контейнера C-n не является целым кратным длины кадра GFP, какой-то из кадров может пересечь границу одного из фреймов C-n (аналогично тому, что имеет место при упаковке ячеек ATM во фреймы SDH [3]). Вместе с тем, благодаря процедуре адаптации, основанной на вставке пустых кадров, емкость прибывающего потока кадров GFP идентична емкости полезной нагрузки VC-мультиконтейнера.
Еще раз подчеркнем, что процедура адаптации скорости и скремблирование осуществляется на первом этапе – этапе фреймирования потока Ethernet в кадры GFP, а не на втором этапе – этапе упаковки кадров GFP во фреймы SONET/SDH. Этим, главным образом (если забыть о гибкости и универсальности), и отличаются процедуры GFP и LAPS, а не тем, что GFP позволяет избежать процедуры стаффинга [4]. Вставка пустых ячеек на этапе адаптации мало чем отличается от стаффинга, используемого в процедуре LAPS [1]. Весь вопрос в том, для каких технологий, когда и как это делается и что получается в результате!
Наиболее важным преимуществом процедуры GFP является ее гибкость и универсальность, позволяющие дополнительно поддерживать трафик данных, использующий интерфейсы типа: FICON, ESCON/SBCON, а также трафик цифрового видеовещания (DVB).
Заключение
Оптимизация магистральных телефонных сетей для передачи пакетизированного трафика – характерная особенность оборудования нового поколения SDH. При решении этой задачи пришлось столкнуться с неизбежной проблемой адаптации асинхронного трафика к синхронному характеру передачи в сетях SDH. Наиболее ярко эта проблема проявилась при попытке приспособить такие сети к передаче трафика Ethernet.
Первые механизмы адаптации допускали, например, упаковку GE в контейнер OC-48/STM-16 (OC-48c/VC-4-16c) SONET/SDH, но это позволяло использовать лишь 42% полезной нагрузки (PL). Затем данная схема была доработана и допускала упаковку GE в PL синхронного транспортного сигнала STS-24c емкостью 1,244 Гбит/с (SONET) или эквивалентного ему конкатенированного виртуального контейнера VC-4-8c (SDH). При этом указывалась дополнительная информация, позволяющая определить тип полезной нагрузки и идентифицировать клиента путем дополнительного контроля заголовка. Эта последняя схема позволяла упаковывать до 8 клиентских каналов GE в синхронные транспортные модули OC-192/STM-64 емкостью 10 Гбит/с. Однако схема не была универсальной и не допускала гибкого использования полосы пропускания сетей.
Выяснилось, что из всех Ethernet-технологий: E, FE, GE, 10GE только поток 10GE с интерфейсом WAN может быть непосредственно отображен на полезную нагрузку фреймов SDH (STM-64 и выше), так как в стандарте на интерфейс 10GE был специально предусмотрен подуровень (WIS – WAN Interface Sublayer) и процедура фреймирования, позволившие редуцировать линейную скорость 10GE до уровня STM-64 [5, 6]. Остальные технологии требовали использования определенного механизма адаптации для отображения сервиса Ethernet на PL фреймов STM-N.
Следует отметить, что и технология 10GE, но с интерфейсом LAN, не может быть непосредственно отображена на полезную нагрузку фреймов SDH (STM-64 и выше), так как этот вариант 10GE требует звена связи емкостью 10,3125 Гбит/с. Аналогичная ситуация будет и с сигналом 10GE, использующим интерфейс WAN, если применяется схема кодирования FEC с упреждающей коррекцией ошибок [5, 6].
Следующая генерация механизмов адаптации включала технологии POS (Packet Over SONET), LAPS (ITU-T X.86) и GFP. Последний механизм адаптации оказался наиболее гибким (так как позволял использовать виртуальную конкатенацию VCAT и процедуру динамической настройки емкости звена связи LCAS) и эффективным (так как допускал как пакетную инкапсуляцию с фреймированием – GFP-F, так и инкапсуляцию кодированного потока, рассчитанную на прозрачную передачу потока через сеть – GFP-T). Согласно этой схеме, GE-сигнал отображается с помощью GFP-F и VCAT на полезную нагрузку STS-3c-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. Слепов Н.Н. Сети SDH новой генерации и их использование для передачи трафика Ethernet. – ЭЛЕКТРОНИКА: НТБ, 2005, №3, с. 56–62.
2. 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).
3. Слепов Н.Н. Современные технологии цифровых оптоволоконных сетей связи. – 2-е изд. исправл. – М.: Радио и связь, 2003.
4. Бакланов И. NGSDH: успех неизбежен. Ч.1. Новые принципы измерений в современных системах передачи данных. – Connect! Мир связи, 2004, №11, с. 164–167.
5. 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).
6. IEEE 802.3-2002 – Local and Metropolitan Area Networks – Specific Requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
Отзывы читателей
