Пакет для городской сети

GFP как метод передачи различных протоколов по одной транспортной среде.

Рынок передачи данных по SONET/SDH в городских сетях растет тем больше, чем чаще у клиентов возникает потребность в услуге пересылки информации на большие расстояния. Общая процедура формирования кадров (Generic Framing Procedure, GFP) представляет собой транспортный протокол, посредством которого пакетные данные доставляются по сети мультиплексной передачи с разделением каналов по времени (Time Division Multiplex, TDM), как SONET/SDH. GFP предлагает несколько преимуществ:

• высокую эксплуатационную надежность, поскольку все содержимое, включая служебную информацию, может быть защищено при помощи кода CRC;
• небольшое время задержки при ис-пользовании прозрачного режима GFP (GFP-T);
• прозрачное соединение на втором уровне посредством GFP-T;
• детерминированную пропускную способность;
• поддержку множества протоколов;
• умеренные накладные расходы.

ПРОБЛЕМЫ С ПЕРЕДАЧЕЙ В ГОРОДСКИХ СЕТЯХ

Эффективная передача различных протоколов по одной транспортной среде весьма востребована в городских сетях. Предназначенные для этой цели современные технологии не лишены недостатков: некоторые транспортные протоколы (к примеру, АТМ) предполагают большой объем служебных данных; другие методы для передачи данных по SONET (в частности, HDLC) созданы в расчете лишь на определенный клиентский протокол (в данном случае Ethernet). К этому добавляются прочие ограничения, в том числе недетерминированная пропускная способность HDLC из-за преобразования символов, когда полезные данные содержат символ 0х7Е.

К тому же необходим эффективный способ упаковки нес-кольких клиентских потоков в единый канал SONET/SDH. Так, скорость передачи полезных данных у ESCON составляет 160 Мбит/с в восьмибитной области (в ESCON используется кодировка 8В/10В). Контейнер VC-4 или STS-3C имеет емкость 155,52 Мбит/с без учета издержек на транспорт или полезные данные. Поэтому наиболее эффективное отображение ESCON на полезные данные SONET/SDH требует объединения нескольких потоков в полезную нагрузку SONET/SDH более высокого порядка. Кроме того, проектировщики систем хотят иметь возможность простого добавления функций на случай дальнейшего развития технологии. К их числу относятся и мониторинг канала с учетом клиента, и формирование трафика в контейнере для каждого канала. Эти требования вытекают из появления Ethernet на транспортной карте, в результате чего биллинга плезиохронной цифровой иерархии (Plesiochronous Digital Hierarchy, PDH) уже недостаточно — пользователи все чаще и чаще требуют биллинга Ethernet.

ОБЗОР GFP

На Рисунке 1 схематически изображена базовая структура кадра GFP. Поля индикатора длины полезной нагрузки (Payload Length Indicator, PLI) и исправления ошибки в базовом заголовке (Core Header Error Correction, cHEC) служат для разграничения кадров. Поле PLI длиной в два байта задает длину области полезной нагрузки. Под полезной нагрузкой понимается часть кадра GFP, не относящаяся к базовому заголовку. В случае cHEC речь идет о контроле с помощью циклического избыточного кода (Cyclical Redundancy Check, CRC) PLI. В разных кадрах поля PLI и cHEC могут различаться. Посредством поля cHEC отправляющий механизм GFP исправляет отдельные битовые ошибки в заголовке ядра и распознает многобитовые. Взаимосвязь между PLI и cHEC, в свою очередь, позволяет принимающему механизму GFP синхронизироваться с входящим потоком данных GFP после включения или сбоя и тем самым формирует базис для упомянутой эксплуатационной надежности GFP.

В Framed GFP (GFP-F) поле данных содержит полезные данные клиента; преобразования символов не происходит, хотя опциональный полином перестановки элементов определен. В Transparent GFP (GFP-T) система осуществляет отображение клиентских данных по схеме 64В/65В, однако оно является детерминированным и не влечет за собой расширения символа данных до двух символов.

Поле типа состоит из 2 байт и определяет вид кадра GFP — кадр данных клиента или кадр управления клиента. Помимо этого, оно указывает, находится ли в конце кадра GFP опциональное поле FCS, какой тип у заголовка расширения и к какому типу данных относится полезная нагрузка. Поле tHEC выполняет для поля типа ту же роль, что и поле cHEC для поля PLI. Заголовок расширения содержит дополнительные данные о потоке GFP.

В GFP-T область полезной нагрузки не содержит немодифицированных клиентских данных. Находящие-ся в ней символы закодированы в соответствии со схемой 64В/65В. Спецификация GFP определяет отображение 64В/65В, как показано на Рисунке 2: GFP-T поддерживает протоколы 8В/10В. Отображение начинается с обычного преобразования 10В-8В.

Преобразователь управляющего кода обрабатывает восьмибайтовый поток из управляющих символов и данных и переводит восьмибитные управляющие символы в новый, специфицированный в GFP-T, трехбитный управляющий код. При этом 8 байт переставляются таким образом, что управляющие коды размещаются в на-чале восьмибайтового блока. Кроме того, к управляющему трехбитному коду добавляется занимающий 4 бит к идентификатор длины. Добавляемый также флажок сигнализирует о том, является ли следующий байт символом данных или управления.

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

Как только набирается восемь восьмибитных кодовых групп 64В/65В, они объединяются в суперблок (см. Рисунок 3). Область полезной нагрузки каждого прозрачного кадра GFP содержит один или несколько суперблоков. Каждый образуется путем размещения одного за другим всех восьмибайтовых кодовых блоков, добавления однобитовых флажков всех кодовых блоков и включения кода СRС 16. В случае GFP-T количество суперблоков в разных кадрах может существенно различаться, однако в конкретном канале GFP-T принято поддерживать определенное их число.

Так или иначе, ничто не мешает суперблоку — в независимости от числа суперблоков на коде — «покинуть» принимающий механизм GFP, как только накопится восемь клиентских кодовых групп. Механизм GFP не должен ждать, пока соберется полный прозрачный кадр GFP. То же справедливо и для исходящего пути, если отсутствует опциональное поле FCS. GFP-T наличия этого поля не требует, поскольку здесь все байты полезной нагрузки в каждом суперблоке проверяются при помощи кода CRC 16. Поскольку со стороны архитектуры нет необходимости в одновременной обработке более чем одного суперблока, Transparent GFP вполне подходит на роль транспортного механизма с малым временем задержки.

Комитеты ITU и ANSI определили общую процедуру формирования кадров (GFP) как эффективное средство для передачи нескольких клиентских протоколов посредством общего протокольного механизма.

В качестве опции GFP предлагает отнесение кадра GFP к тому или иному каналу с помощью поля идентификатора канала (Channel ID, CID) из заголовка линейного расширения. Интеллектуальный протокольный процессор GFP может оценить идентификатор канала и приписать входящие кадры GFP к определенной виртуальной составляющей (tributary).

В обратном направлении у протокольного процессора GFP есть возможность переключения полезных данных исходящих кадров GFP на заданный порт клиентского протокола.

Но одна только возможность применения ряда функций еще не является преимуществом. Далее мы поговорим об использовании поля CID для коммутации и о тех ситуациях, когда это оказывается полезным.

ПРИЛОЖЕНИЯ ПЕРЕДАЧИ ДАННЫХ ПО SONET/SDH

На схеме типичного приложения GFP для передачи данных по SONET/SDH (см. Рисунок 4) можно видеть, что представление производится в соответствии с функциями. Отдельные блоки либо реализуются в независимом элементе каждый, либо все сразу интегрируются в один большой компонент. Возможна ситуация, когда данные поступают от разных протоколов, поскольку GFP на текущий момент поддерживает, как показано на рисунке, протоколы Ethernet 10/100/1000, FICON, ESCON, Fibre Channel и DVB-ASI. После последовательно-параллельного преобразования при помощи сердеса (сериалайзер/десериалайзер) данные попадают на преобразователь (mapper), генерирующий из них соответствующие кадры GFP. Отображение происходит в режиме один к одному: один поток клиентских данных относится к одному каналу в формирователе кадров. Последний обеспечивает поддержку виртуальной конкатенации (Virtual Concatenation, VC) и формирует кадр SONET/SDH, который после этого попадает на сердес SONET/SDH. Виртуальная конкатенация и GFP часто встречаются в связке с сердесом SONET/SDH и активно используются в решениях SONET/SDH.

ОГРАНИЧЕНИЯ GFP-T С ПОСТОЯННОЙ ПРОПУСКНОЙ СПОСОБНОСТЬЮ

В первом примере коммутации GFP речь идет о приложениях, в которых клиентскому протоколу предоставляется постоянная пропускная способность, и чрезмерного бронирования не происходит (к примеру, при отображении ESCON или Fibre Channel на GFP-T). Поэтому нижеприведенные высказывания имеют силу для всех приложений GFP-T с постоянной скоростью передачи данных в глобальной сети. Фактически речь идет о двух элементарных скоростях полезной нагрузки VC1, а именно — каналах на базе VC3 со скоростью передачи полезных данных примерно STS-1 (около 50 Мбит/с) и каналах на базе VC4 со скоростью передачи полезных данных на уровне STM-1 (около 150 Мбит/с). Согласно стандартному обозначению SDH, последняя цифра всегда соответствует количеству составляющих каналов. Таким образом, VC3-4v — это канал с четырьмя составляющими по 50 Мбит/с (всего около 200 Мбит/с), а VC4-2v — канал с двумя составляющими по 150 Мбит/с (всего около 300 Мбит/с).

Когда упомянутый преобразователь GFP работает с отображением 1:1, определенному каналу передачи данных всегда соответствует определенный клиентский интерфейс (см. Рисунок 5). Теперь предположим, что приложение VC отображает посредством GFP-T 12 потоков данных ESCON на канал OC-48/STM-16. Поскольку каждый отдельный канал ESCON в восьмибитной области обладает пропускной способностью в 160 Мбит/с, в канал VC4-1v, предлагающий лишь 150 Мбит/с, он не умещается, однако канала VC3-4v с его 200 Мбит/с вполне хватило бы. В каждом канале OC-48/STM-16 имеется 48 составляющих VC-3, а значит, такая реализация теоретически возможна, и все 12 потоков ESCON были бы успешно переданы. Однако более старые системы SDH не поддерживают ступенчатого предоставления скорости данных с шагом VC3, поэтому возникает искусственное ограничение: хотя емкости для передачи 12 потоков ESCON достаточно, но с учетом практического ограничения приемлемых транспортных форматов (отсутствие поддержки VC-3nv) невозможно обеспечить отображение 12 потоков ESCON с пропускной способностью 160 Мбит/с на канал OC-48/STM-16. Небольшое замечание: скорость передачи полезной нагрузки VC-3 и VC-4 нормирует ITU G. 707.

Использование заголовка линейного расширения GFP дает до сих пор не доступную в многопротокольных транспортных системах возможность, а именно коммутацию отдельного кадра GFP на основе содержимого поля CID в заголовке линейного расширения GFP. К примеру, возможно объединение всех трех отображаемых посредством GFP-T потоков ESCON (160 Мбит/с х 3 = 480 Мбит/с) в один канал VC4-4v (примерно 150 Мбит/с х 4 = примерно 600 Мбит/с). Однако оно имеет смысл лишь тогда, когда потоки поддаются разделению в исходящем направлении. Поскольку отображение происходит прозрачно, принимающий преобразователь GFP не имеет доступа к более высоким уровням потока клиентского протокола. Поэтому поле CID должно использоваться для идентификации отдельных потоков GFP на принимающей стороне. Точно так же поле CID пригодно и для разделения отдельных потоков GFP на стороне передачи. Благодаря возможности коммутации трафика на основании поля CID становится возможным поддерживать приложения, с которыми в других случаях работать не удается. Таким образом, можно снять ограничения, возникающие в результате конфигураций с другими клиентскими протоколами (Fibre Channel, DVB-ASI и т. д.) и транспортными технологиями (OC-12/STM-4, OC192/STM-64). Критерием применения поля CID для объединения является требование происхождения объединяемых потоков клиентского протокола от одного и того же клиента. Часто клиенты предпочитают пользоваться конвертом синхронной полезной нагрузки (Synchronous Payload Envelope, SPE) или виртуального контейнера не совместно с кем-либо, а персонально.

ПРИЛОЖЕНИЯ GFP-T С ПЕРЕМЕННОЙ ПРОПУСКНОЙ СПОСОБНОСТЬЮ

Логичным следующим шагом в применении поля CID в целях коммутации является использование приложений с переменной пропускной способностью. Это касается приложений на базе Framed GFP (GFP-F). При этом скорость передачи данных в глобальной сети не постоянна, а зависит от трафика по клиентскому соединению. Когда последний ничего не передает, транспортный канал состоит исключительно из пустых кадров GFP. Если клиентское соединение, напротив, сильно загружено, в SPE и виртуальных контейнерах транспортного канала содержатся исключительно кадры данных GFP и отсутствуют пустые кадры (при условии, что преобразователь GFP в состоянии правильно управлять каналом). До сих пор Ethernet, IP/PPP и FC-BBW остаются единственными определенными для передачи GFP-F протоколами (см. ITU G.7041). Поскольку большинство распространенных приложений GFP-F в ближайшем будущем будет базироваться на Ethernet, последующее утверждение касается Ethernet поверх GFP-F: транспорт GFP с переменной пропускной способностью для VC необходим в двух случаях — чрезмерное бронирование 1:1 и чрезмерное блокирование N:1 или N:N (см. Рисунок 6).

При перебронировании 1:1 группе VC в SONET/SDH назначается единственный клиентский протокольный канал, однако пропускная способность транспортного канала, предоставленного клиентскому протокольному каналу, меньше, чем максимально возможный трафик. Пример: назначение клиентского порта Ethernet с пропускной способностью 1000 Мбит/с каналу VC4-4v (около 600 Мбит/с).

Такие механизмы могут, в частности, работать с кадрами паузы Ethernet или отбрасывать пакеты Ethernet (причем система опирается на функциональность повторной передачи TCP, чтобы обеспечить правильную передачу данных). Поскольку происходит отображение 1:1, коммутация GFP-CID не нужна. Когда имеет место перебронирование 1:N или N:N, ряд клиентских портов с разной пропускной способностью назначаются одному или нескольким каналам SONET/SDH. На Рисунке 7 изображен случай приложения с перебронированием/объединением 4:1. Четыре потока Gigabit Ethernet объединяются в один. Поскольку клиенты часто требуют, чтобы их трафик передавался в собственном виртуальном контейнере SONET/SDH-SPE, подобная ситуация имеет смысл лишь тогда, когда весь клиентский трафик исходит от одного клиента. Причем трафик может составляться из голосовых данных (Voice over IP, VoIP), трафика многопротокольной коммутации меток (Multi-Protocol Label Switching, MPLS), расширения клиентской локальной сети и Fibre Channel поверх IP (FCIP). Но в любом случае преобразователю GFP приходится решать, какую пропускную способность следует предоставить каждому клиентскому порту. Поэтому в устройстве GFP должно быть реализовано качество услуг (Quality of Service, QoS), так как емкость транспортного канала меньше суммарной емкости клиентских протоколов. Таким образом, у преобразователя GFP должна иметься возможность доступа к более высоким уровням клиентского протокола (IP или ТСР). Хотя отрасль пока так и не договорилась о единой реализации QoS, ясно, что это будет происходить на верхних уровнях Ethernet. Поскольку устройство GFP должно обращаться к третьему и четвертому уровням клиентского трафика, передачу данных посредством Ethernet GFP-F не следует усложнять введением независимых идентификаторов каналов GFP. Для приложения N:1 или N:N с переменной пропускной способностью преобразователи GFP на обоих концах линии должны обращаться к более высоким уровням клиентских кадров Ethernet, поэтому коммутация на основании поля CID GFP оказывается излишней.

Джейсон Баумбах — менеджер по приложениям в компании Cypress Semiconductor. С ним можно связаться по адресу: jos@lanline.awi.de.

Маршрутизация или коммутация?

Протоколом маршрутизации эксперты называют протокол, который для ретрансляции пакетов использует собственный алгоритм маршрутизации (Cunningham/Lane). Такой протокол определяет путь, которым пакеты следуют через сеть. Примерами являются пограничный межсетевой протокол (Border Gateway Protocol, BGP), протокол маршрутной информации (Routing Information Protocol, RIP) и протокол маршрутизации внутреннего шлюза (Interior Gateway Routing Protocol, IGRP). Протокол передачи данных (клиентский протокол) можно назвать «маршрутизируемый», когда речь идет о протоколе данных, обрабатываемых протоколом маршрутизации. Для приложений передачи данных, где используется отображение пакетных данных на SONET/SDH, GFP может рассматриваться как «коммутируемый» протокол, поскольку он задуман в качестве транспортного протокола, а эту функцию в транспортной системе обычно называют «коммутация».

? AWi Verlag