Подсистема GFP-C.

Подсистема GFP-C является частью протокола GFP, которая не зависит от типа передаваемой нагрузки. В GFP-C предполагается существование двух типов кадров:

- Клиентские кадры GFP, передающие полезную нагрузку

- Кадры управления GFP

Основная информация протокола GFP передается в клиентских кадрах, Поэтому именно они имеют довольно сложную архитектуру. Кадры управления намного проще.

Структура клиентского кадра GFP-C.

			cHEC (CRC-16)

4

		Поле нагрузки

4 - 65535

		Дополнительная контрольная сумма FCS (CRC-32)

Рис. 5.24. Структура клиентского кадра GFP-C.

Клиентский кадр GFP-C состоит из поля заголовка и поля полезной нагрузки. Размер поля заголовка составляет 4 байта (октета), два из которых отводятся под индикатор поля нагрузки PLI (Payload Length Indicator), а два – под контрольную сумму CRC-16 в заголовке cHEC. В зависимости от типа поле полезной нагрузки имеет переменный размер от 4 до 65535 октетов. Как показано на рис. 4.24 в состав поля полезной нагрузки входят заголовок нагрузки ( от 4 до 64 байтов), непосредственно поле нагрузки и контрольная сумма FCS размером 4 байта, необходимая для контроля ошибок с использованием CRC-32. Рекомендацией ITU-T G.7041 поле FCS считается дополнительным, оно может и отсутствовать.

Для обеспечения целостности всего клиентского кадра GFP-C особое внимание в протоколе отводится заголовку кадра. Очевидно, что возникновение ошибки в поле PLI приведет к неправильному считыванию всего кадра GFP. Поэтому для контроля ошибок в заголовке кадра используется не просто алгоритм CRC-16, а его модификация cHEC. Технология HEC была разработана под приложения АТМ, и с тех пор применяется в различных телекоммуникационных системах, где важна достоверность передаваемых данных. Суть HEC состоит в том, что этот алгоритм обеспечивает не просто идентификацию блоковой ошибки, как CRC, но также позволяет корректировать возникновение единичной битовой ошибки. В случае появления более чем одной ошибки HEC идентифицирует многобитовую ошибку. Можно рассматривать HEC как помехоустойчивое кодирование, применяемое в современных системах передачи. Описание алгоритма HEC приведено в рек. ITU-T V.41. Следует отметить, что использование НЕС позволяет корректировать возможные ошибки в поле PLI, поэтому можно гарантировать сохранность всего кадра GFP-C.

Х=4 to 64 6 6 2

Передаваемые 7 7

9 9

6 9 . 9 2

.

0 to 65535X . . .

. .

n n

Октет 1 2 3 4 5 6 7 8 2

Бит 1 2 3 4 5 6 7 8

Порядок передачи битов

Рис. 5.25. Структура поля полезной нагрузки.

Рассмотрим теперь поле полезной нагрузки клиентского кадра (рис. 5.25). Оно имеет переменный размер, варьируемый в очень широких пределах. Большой размер поля полезной нагрузки определяется тем, что существуют

приложения, требующие передачи кадров большого размера, например, дейтаграмм IP и кадров Ethernet. Влияние этих двух технологий потребовало, чтобы поле полезной нагрузки было как минимум 1600 байт. С запасом на перспективу стандарт предполагает размер поля полезной нагрузки до 65535 байт, что превосходит все современные и перспективные требования по передаче данных. Нижний предел поля полезной нагрузки определяется размером заголовка полезной нагрузки – 4 байта. В этом случае, если мы имеем «пустой» GFP кадр, поле полезной нагрузки будет состоять только из заголовка.

На рис. 5.25 детально рассмотрена структура заголовка. Заголовок полезной нагрузки, также как и заголовок кадра GFP, является составным и использует поля HEC. Его размер может быть переменным – от 4 до 64 октетов. Минимальный заголовок нагрузки состоит из двух обязательных полей по 2 октета: поле типа нагрузки (поле Type) и поле контроля и корректировки ошибок (типа НЕС). Остальные поля заголовка нагрузки (до 60 октетов) являются дополнительными и могут не присутствовать в составе заголовка. Эта часть заголовка получила название поля расширения заголовка (Extension Header). Поле расширения представляет собой довольно большой массив информации, который определяется назначением поля расширения. Для передачи разнородной нагрузки NGN нужно передавать большой объем дополнительных данных, связанных с этой нагрузкой, например, идентификаторы виртуальных каналов, адреса передатчика и приемника, номер порта, класс обслуживания, дополнительные сигналы о неисправностях и т. д. Именно для передачи такой информации и используется поле расширения. Поэтому само поле может иметь большой размер – до 60 октетов. Для контроля и корректировки ошибок в этой части поля заголовка используется все та же процедура НЕС. Данные контрольной суммы передаются в 2-октетном поле еНЕС.

Наличие или отсутствие поля расширения заголовка и его формат определяется в поле Type. В этом поле указывается также наличие или отсутствие контрольной суммы FCS у всего поля полезной нагрузки (рис. 5.25).

15 14 13 12 11 10 9 8

Поле передачи

октетов

6 Бит

7 6 5 4 3 2 1 0

1 2 3 4 5 6 7 8

Порядок передачи битов

Рис. 5.26. Структура поля типа нагрузки (поля Type) для заголовка нагрузки GFP-C.

Рассмотрим сначала обязательные поля заголовка нагрузки, а именно поле Type. Структура этого двухоктетного поля представлена на рис. 5.26. Для

удобства рассмотрения на рисунке показаны номера октетов с учетом всей нумерации кадра GFP-C, так что поле Type начинается с пятого октета. Но при этом для рассмотрения поля Type целесообразно перенумеровать 16 битов этого поля так, как показано на рисунке (от 0 до 15). Легко заметить, что нумерация внутри поля и порядок передачи битов в системе NGSDH совершенно противоположен.

Как следует из рис. 5.26, в составе поля Type заголовка полезной нагрузки присутствуют 4 поля:

· Идентификатор типа нагрузки – PTI (Payload Type Identifier)

· Идентификатор наличия контрольной суммы FCS – PFI (Payload FCS Identifier)

· Идентификатор наличия поля расширения заголовка нагрузки – EXI (Extension Header Identifier)

· Идентификатор нагрузки - UPI (User Payload Identifier)

Рассмотрим кратко назначение указанных полей, поскольку они непосредственно представляют ценность для эксплуатации NGSDH.

Поле PTI состоит из 3 битов и определяет тип клиентского кадра GFP-C. Данные пользователя передаются со значением PTI=000, данные управления передаются со значением PTI=100, остальные значения зарезервированы за будущими изменениями технологии GFP. Таким образом, в настоящее время действуют два типа полезной нагрузки, определяемые полем PTI.

Поле PFI – это значение бита №12. Оно имеет единственное назначение: указать на присутствие поля FCS в составе поля нагрузки (рис. 5.24 – 5.25). Соответственно, PFI=1 означает, что FCS есть, а PFI=0 – что FCS отсутствует.

Поле EXI определяет статус поля расширения заголовка нагрузки. Само поле расширения является необязательным, поэтому в поле Type нужно определить статус этого поля. EXI имеет размер в 4 бита, что соответствует максимально 16 значениям. В настоящее время используется только три значения, так что возможны три варианта поля расширения:

• EXI=0000 означает, что поле расширения отсутствует. В рекомендации такой кадр называют кадром с нулевым расширением заголовка.
• EXI=0001 означает линейный заголовок кадра (Linear Frame). Это значение используется в случае, когда мы имеем дело с передачей информации по схеме «точка – точка», например, для передачи нагрузки РРР и т. п.
• EXI=0010 означает кольцевой заголовок кадра (Ring Frame). Такие заголовки расширения используются для передачи трафика от систем с кольцевой топологией (типа Token Ring, FDDI, RPR и пр.).

Поле UPI представляет собой поле из 8 битов, которые определяют тип передаваемой нагрузки. Это поле не имеет конкретных значений, и его интерпретация зависит от значения поля PTI. Для данных пользователя (PTI=000) поле UPI имеет свои значения, для кадров управления (PTI=001) – свои. Таким

образом, рассмотрение UPI можно производить только вместе с PTI.

Итак, все перечисленные 4 поля полностью определяют тип передаваемой нагрузки. Можно определенно говорить, что каждому типу GFP-кадра соответствует определенная маркировка (PTI, PFI, EXI, UPI). Эта маркировка едина для всех клиентских GFP-кадров и, как мы увидим, значительно облегчает понимание процессов передачи данных в GFP.

5 5

6 6

7 7

8 8

1 2 3 4 5 6 7 8

Octet Bit 9 9

EXI=0000 10 10

Octet Bit 1 2 3 4 5 6 7 8

Рис. 5.27. Два наиболее распространенных варианта заголовков нагрузки: без поля расширения и с линейным полем расширения.

Справа на рисунке показано поле с линейным заголовком расширения PTI, PFI, 0001, UPI (EXI=0001). Представлена ситуация, когда в точке мультиплексирования GFP имеются несколько независимых каналов, которые должны быть объединены в один транспортный маршрут. Как видно из рисунка, поле заголовка в этом случае имеет размер в 8 октетов:

• Два октета для поля Type
• Два октета для поля tHEC
• Один октет для поля идентификации канала CID (Channel ID)

• Два октета eHEC для контроля и коррекции ошибок в поле расширения

Рассмотрим теперь различные значения поля UPI в зависимости от типа поля PTI. Для передачи нагрузки пользователя (PTI=000) существует несколько разных значений UPI, определяющих тип передаваемой нагрузки (табл. 4.5). Как следует из таблицы, поле UPI соотносится с форматами кадров GFP-F и GFP-T и определяет тип передаваемой нагрузки. Например, передача через сеть NGSDH данных Ethernet должна иметь маркировку PTI, PFI, EXI, UPI (000, PFI, 0001, 0000 0001) т. е. иметь значения полей PTI=000, EXI=0001, и UPI=0000 0001. Этот пример иллюстрирует, как маркировка (PTI, PXI, EXI, UPI) определяет в протоколе GFP-C специфику передаваемого по сети NGSDH трафика.

Таблица 5.5. Значения поля UPI в случае передачи нагрузки пользователя (PTI=000).

При передаче в поле нагрузки сигналов управления значение поля PTI=100. Следует отметить, что в данном случае речь идет не о кадрах управления протокола GFP-C, мы по-прежнему говорим о клиентских кадрах. Но и в этом случае в поле нагрузки может возникнуть необходимость передачи сигналов управления. Например, если возникнет необходимость передачи данных от каких-либо процессов на стороне клиента, которые требуют контроля связности канала и контроля стабильности сигнала синхронизации, то в самом протоколе GFP-C должна быть предусмотрена возможность передачи по сети NGSDH таких

сигналов сквозным образом. Именно этой цели и служат клиентские кадры управления со значением PTI=100. В случае таких кадров значение поля UPI отличается. Возможные их значения в современном стандарте показаны в табл. 5.6.

Таблица 5.6. Значения поля UPI при передаче кадров управления (PTI=100).

Теперь от рассмотрения клиентских кадров перейдем к рассмотрению кадров управления в протоколе GFP-C.

Кадры управления GFP-C.

В отличие от клиентских кадров GFP-C кадры управления в настоящее время находятся в стадии рассмотрения и согласования. Для протокола GFP-С основное назначение – это передача пакетного трафика по сети NGSDH, а вопросы управления и контроля процесса передачи являются второстепенными. По этой причине стандарт в части структуры кадров управления является весьма лаконичным. Однако, по мере развития и внедрения технологии GFP на транспортных сетях возникнет большее понимание, какие механизмы управления должны быть реализованы на уровне GFP, и тогда стандарт начнет развиваться. Пока же единственным стандартизованным кадром управления GFP-C является «пустой» кадр.

«Пустой» кадр по своей структуре соответствует рис. 5.24, но в нем есть только заголовок кадра в 4 октета, и нет полезной нагрузки. В технологии NGSDH пустые кадры используются для процедуры заполнения ресурса канала передачи, если ресурс оказывается больше размера, необходимого для передачи клиентского трафика. Тогда излишек ресурса канала передачи заполняется пустыми кадрами. Как видно из рис. 5.28, структура пустого кадра по тривиальности соответствует его назначению. Значение индикатора нагрузки PLI=0. Что означает, что полезная нагрузка в кадре отсутствует. Соответственно, поле cHEC также представляет собой два последовательных октета из нулей. Для будущего использования предлагается также под контрольные кадры GFP-C зарезервировать значения PLI=1, 2 и 3.

Октеты 1 2 3 4 5 6 7 8

Биты

Рис. 5.28. Структура «пустого» кадра GFP-С.

C-n

Кадры GFP «Пустой» кадр

Заголовок Поле нагрузки

Рис. 5.29. Заполнение контейнера NGSDH кадрами GFP-C.

Применение пустых кадров позволяет добиться полного заполнения пространства виртуального контейнера NGSDH (рис. 5.29). Как показано на рисунке, в составе контейнера присутствуют и обычные кадры GFP-C, и пустые кадры, представляющие собой отдельные заголовки нулевого содержимого. Следует отметить, что под контейнером C-n в данном случае понимаются на только стандартные контейнеры классической SDH C-X, но также конкатенированные контейнеры C-X-Xc и виртуально конкатенированные контейнеры C-X-Xv.

Чтобы избежать путаницы, несомненно, присутствующей в стандарте GFP, сведем все приведенные ранее сведения воедино. Для этого на рис. 4.30 представлено дерево архитектуры GFP-C. При этом, важно сделать несколько выводов относительно основ GFP:

1. В протоколе GFP существует 5 важных для практики эксплуатации полей кадров PLI, PTI, PFI, EXI и UPI. Все эти пять полей несут важную информацию о составе кадров GFP и однозначно определяют тип передаваемого трафика. Поэтому значения этих полей сопоставимо со всеми известными полями классической SDH. Нужно только помнить их предназначение и местоположение в архитектуре GFP.
2. В протоколе GFP существует 4 поля контроля параметров ошибок: FCS, cHEC, tHEC и eHEC. Каждое из этих полей может быть использовано в дальнейшем для поиска и устранения ошибок в системе передачи на уровне GFP.
3. Протокол GFP добавляет два новых сигнала о неисправности уровня GFP, а именно LCS и LCSyn, которые присутствуют в клиентских кадрах. Эти два сигнала дополняют галерею сигналов о неисправности классической SDH и вносят первый вклад в многоуровневую систему контроля HGSDH.

Поля, имеющие

значение для эксплуатации

Процедуры контроля и

корректировки ошибок

в полях

Сигналы о неисправностях

в GFP

Рис. 5.30. Структура протокола GFP-C с указанием основных полей.

Как уже отмечалось, самое важное преимущество GFP перед его предшественниками состоит в максимальной адаптации к современному

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

Теперь перейдем к описанию подсистем GFP, связанных со спецификой передаваемой нагрузки.