2.7. Сигнальные сообщения т1.617 Приложение d

Стандарт Т1.617 Приложение D (далее просто стандарт Т1.617), как и стандарт Консорциума LMI (далее просто LMI), определяет два сообщения: STATUS ENQUIRY и STATUS. Оба сообщения по­сылаются в формате кадра HDLC UI (рис. 2.15). Если сообщение LMI использует DLCI=1023, то управляющие сообщения Т1.617 передаются с адресом DLCI=0 и со значениями битов FECN=0, BECN==0, DE=0 (рис.2.15). Длина заголовка сообщения Т1.617 четыре октета. Значение дискри­минатора протокола устанавливается равным 08, CRV=00 (фиктивное значение), и сообщение STATUS ENQUIRY кодируется значением 75, а сообщение STATUS - значением 7D. Вслед за заголов­ком Т1.617 идут информационные элементы сообщения.

Флаг	Адресное поле	Информационное поле	FCS	Флаг
1	2	n	2	1

UI	Дискриминатор протокола (08)	CRV (00)	Тип сооб-щения	Сдвиг блоки-ровки (95)	Информацион-ный элемент 1	Информацион-ный элемент 2
1 1 1 1 1 n n

8765 4321

0111 1101 STATUS

0111 0101 STATUS ENQUIRY

Рис. 2.15. Структура формата сообщения управления Т1.617

Отличительной чертой сообщения стандарта Т1.617 является использование в заголовке до­полнительного информационного элемента - Сдвиг блокировки (Locking Shift) со значением 95. Со­общения STATUS ENQUIRY и STATUS стандарта Т1.617 в целом аналогичны сообщениям LMI. Если протокол LMI использует в сообщении STATUS ENQUIRY информационные элементы Report Type и Keep Alive, то протокол Т1.617 - информационные элементы Report Type и Link Integrity Verification (Проверка связности канала), выполняющие те же функции. Информационный элемент Link Integrity Verification имеет структуру, аналогичную структуре элемента Keep Alive.

Особенностью информационного элемента Report Type стандарта Т1.617 является использова­ние добавочного значения 02, соответствующего запросу статуса отдельного PVC и не используемого в стандарте Консорциума. Еще одним отличием стандарта Т1.617 является структура сообщения STATUS, а именно состав информационного элемента PVC Status, где для передачи данных о мини­мальной ширине полосы канала используется не три октета, а только два.

2.8. Управление перегрузками по графику. Сигнализация cllm

Одной из важных функций U-плана протокола Frame Relay является обеспечение контроля пе­регрузок в сети. Оптимизация работы сети и обеспечение высоких показателей качества предостав­ляемых услуг без контроля перегрузок практически невозможны, поэтому этот вопрос решается как средствами протокола, так и средствами измерений, причем последние используют данные, содер­жащиеся в протоколе.

Перегрузки в сети Frame Relay приводят к снижению ее производительности (рис. 2.16 слева) и увеличению задержки в передаче информации пользователя (рис.2.16 справа).

Как видно из рисунка, с ростом нагрузки на сеть в сети возникают перегрузки, которые приво­дят к уничтожению передаваемых кадров в порядке их приоритетов коммутатором Frame Relay. Этот процесс получил название дискартирования или дискартинга. Поскольку в процессе дискартинга происходит уничтожение кадров, перегрузка в сети ведет к уменьшению ее производительности. В то же время оконечное оборудование с функциями контроля передаваемой/принимаемой информации будет дублировать потерянные кадры, в результате чего процесс "сборки" информации пользователя на приемной стороне будет иметь задержки. Общая задержка передачи информации пользователя будет увеличиваться с увеличением количества перегрузок.

Работа пользователя в сети Frame Relay характеризуется следующими параметрами, непосред­ственно связанными с процедурами управления перегрузками:

• Скорость доступа (Access Rate - АР) - скорость, которую обеспечивает физический канал доступа (обычно соответствует пропускной способности одного или нескольких каналов В, D или Н).

• Обязательная скорость передачи (Committed Information Rate - CIR) - скорость, гарантированная оператором пользователю для нормальной передачи по сети.

• Текущая скорость передачи - скорость передачи в заданный момент времени.

• Интервал измерений - временной интервал измерения параметров скорости и размера кадров.

• Обязательный объем информационного блока (Be) - максимальный объем (в битах) информации пользователя, который обязуется передать оператор при нормальных условиях работы сети за ин­тервал измерений.

• Дополнительный объем информационного блока (Be) - максимальный объем (в битах) информа­ции пользователя, который может передать оператор за интервал измерений без обязательств га­рантированной передачи.

Нагрузка на сеть Нагрузка на сеть

Рис. 2.16. Графики влияния перегрузок на параметры эффективности работы сети и задержки передачи.

В протоколе Frame Relay имеется процедура явного обна­ружения перегрузок, основанная на использовании FECN и BECN, упоминавшихся при описании состава адресного поля кадра (рис.2.5).Помимо процеду­ры явного обнаружения перегру­зок, используется также проце­дура неявного обнаружения, не связанная напрямую с протоко­лом Frame Relay, а реализован­ная на транспортном уровне про­токолов приложений. В зависи­мости от направления управле­ния передатчиком используется прямое или обратное направле­ние передачи информации о пе­регрузке. Процедура управления перегрузками представлена на рис.2.17.

Вслучае, если коммутатор контролируется приемником ин­формационного потока, при об­наружении перегрузки в направ­лении передачи посылается сиг­нал FECN. Если коммутатор кон­тролируется источником информационного потока, в обратном направлении передается сигнаг. BECN. Если в противоположном направлении нет передачи данных, сигнал BECN передавать невозмож­но. В этом случае коммутатор Frame Relay использует сообщение объединенного протокола управления каналом данных CLLM (Consolidated Link Layer Management). Сообщение CLLM посылается в направлении источника информационного потока. Для передачи сообщения CLLM служит адрес DLCI == 1023, зарезер­вированный для передачи этого сообщения.

После обнаружения перегрузки коммутаторы Frame Relay используют механизм дискартирования для ее устранения. Механизм дискартирования связан с контролем скорости передачи данных от пользовате­ля (рис.2.18). Как известно, технология Frame Relay обеспечивает гибкое регулирование скорости переда­чи данных от пользователя. Если скорость не больше обязательной скорости передачи (CIR), передача дан­ных гарантирована оператором сети. При превышении CIR данные могут быть переданы без гарантии переда­чи. В этом случае кадрам передачи таких данных при­сваивается низкий приоритет при дискартинге. При превышении скорости передачи максимальной скоро­сти (определяемой обычно скоростью доступа - AR), коммутатор должен сам начать процесс дискартинга и дискартировать все лишние кадры, отмеченные низким приоритетом.

С процессами дискартинга связана процедура управления импульсным графиком, имеющим место обычно при передаче информации LAN через сеть Frame Relay. Аналогом CIR здесь выступает обязатель­ный объем информационного блока (Вс), а аналогом AR- Be (рис.2.19).

Рис. 2.19. График управления размером передаваемого блока информации

Так же, как и в случае с процедурой контроля скорости передачи данных, если объем блока становится больше Вс, соответствующим блокам присваивается низкоуровневый приоритет при дискартировании (DE=1). При дальнейшем увеличении размера больше Вс + Be, соответствующие кад­ры дискартируются.

Рассмотрим детально протокол сообщений CLLM, используемый для анализа перегрузок, воз­никающих в сети. Он применяется довольно редко, поскольку обычно используется механизм BECN/FECN. Тем не менее, в некоторых случаях он является единственным. Для передачи сообще­ний CLLM применяется адрес DLCI = 1023. Сообщение использует стандартный формат Frame Relay (рис.2.5). Основное отличие формата состоит в структуре адресного и информационного полей и FCS. Структура кадра сообщения CLLM представлена на рис. 2.20.

В основу информационного поля положена структура HDLC XID, поэтому в состав информаци­онного поля входит один октет контрольного поля (Control=AF). Идентификатор формата и групповой идентификатор появились в стандарте из ISO 8885, откуда был выведен протокол CLLM. Нулевое значение идентификатора параметра показывает, что параметр относится к стандарту I.122, значение 2 - что обнаружена ошибка в сети; значение 3 - что причина ошибки находится в области DLCI. За­тем передается информация о DLCI. Каждый DLCI использует 2 октета. Таким образом, максимальное значение DLCI равно 255. Каждое сообщение CLLM может содержать информацию о 127 DLCI.

Поле	Октет 8		7	6	5	4	3	2	1	Наименование Адресный октет 1 (R означает отклик) Адресный октет 2 (X означает любое значение) Контрольное поле XID Идентификатор формата Групповой идентификатор (OF) Размер элемента - октет 1 Размер элемента - октет 2 Идентификатор параметра (0) Длина параметра (4) Значение параметра = 69 Значение параметра = 31 Значение параметра = 32 Значение параметра = 32 Идентификатор параметра = 2 Длина параметра Причина передачи Величина параметра = 3 (идентификатор DLCI) Длина параметра Первый DLCI - октет 1 Первый DLCI - октет 2
Адресное	1	1	1	1	1	1	0	R	1	Адресный октет 1 (R означает отклик) Размер элемента - октет 2 Идентификатор параметра (0) Длина параметра (4) Значение параметра = 69 Значение параметра = 31 Значение параметра = 32 Значение параметра = 32 Идентификатор параметра = 2 Длина параметра Причина передачи Величина параметра = 3 (идентификатор DLCI) Длина параметра Первый DLCI - октет 1
	2	1	1	1	1	X	X	X	1	Адресный октет 2 (X означает любое значение) DLCI - октет 1
Контрольное	3	1	0	1	0	1	1	1	1	Контрольное поле XID
Информа-ци­онное поле XID	4	1	0	0	0	0	0	1	0	Идентификатор формата
	5	0	0	0	0	1	1	1	1	Групповой идентификатор (OF)
	6									Размер элемента - октет 1
	7									Размер элемента - октет 2
	8	0	0	0	0	0	0	0	0	Идентификатор параметра (0)
	9	0	0	0	0	0	1	0	0	Длина параметра (4)
	10	0	1	1	0	1	0	0	1	Значение параметра = 69
	11	0	0	1	1	0	0	0	1	Значение параметра = 31
	12	0	0	1	1	0	0	1	0	Значение параметра = 32
	13	0	0	1	1	0	0	1	0	Значение параметра = 32
	14	0	0	0	0	0	0	1	0	Идентификатор параметра = 2
	15	0	0	0	0	0	0	0	1	Длина параметра
	16	0	0	0	0	0	0	1	1	Причина передачи
	17									Величина параметра = 3 (идентификатор DLCI)
	18									Длина параметра
	19									Первый DLCI - октет 1
	20									Первый DLCI - октет 2
	2n+17									N-й DLCI - октет 1
	2n+18									N-й DLCI – октет 2

Рис. 2.20. Структура сообщения CLLM

Важным параметром сообщения CLLM является причина его передачи. В зависимости от зна­чения этого параметра определяется причина возникновения перегрузки. Стандартом предусмотрены следующие значения октета причины передачи:

Биты	8765	4321
	0000	0010	Перегрузка сети из-за кратковременного повышения графика
	0000	0011	Перегрузка сети из-за долговременного повышения графика
	0000	0110	Кратковременный сбой аппаратуры или услуги
	0000	0111	Долговременный сбой аппаратуры или услуги
	0000	1010	Кратковременная процедура обслуживания
	0000	1011	Долговременная процедура обслуживания
	0001	0000	Не специфицировано (кратковременная причина)
	0001	0001	Не специфицировано (долговременная причина)