Сети и телекоммуникации
.pdf
441
ции протоколов канального и сетевого уровней (рис. 31.3). Кодирование этих полей определено стандартом ANSI Т1.617 и Рекомендацией ITU-T Q.933 и тем самым обеспечивает совместимость на нижних уровнях. Более того, возмож-
ность использования специального кода (идентификатора) в первом октете этих двух полей (7...10-й октеты, рис. 31.3) позволяет идентифицировать уникальные пользовательские протоколы.
Биты |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
Назначение |
|
Октеты |
||||||||||
|
|
|
|
|
|
|
|
|
||
1 |
0 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
Ф л а г |
|
2 |
|
|
|
|
|
|
|
|
Адресная часть заголовка |
|
3 |
|
|
|
|
|
|
|
|
стандартного FR-кадра |
|
4 |
1 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
ИНИК |
|
5 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Необязательное поле |
|
6 |
|
|
|
|
|
|
|
|
Идентификатор протокола сетевого уровня |
|
7 |
|
|
|
|
|
|
|
|
Идентификатор протокола 2-го уровня |
|
8 |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
9 |
|
|
|
|
|
|
|
|
Идентификатор протокола 3-го уровня |
|
10 |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
11... |
|
|
|
|
|
|
|
|
Д А Н Н Ы Е |
|
|
|
|
|
|
|
|
|
|
Проверочная последовательность |
|
|
0 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
Ф л а г |
|
Рис. 31.3. Формат многопротокольного кадра, использующего Рекомендацию ITU-T |
||||||||||
|
|
для идентификации протокола сетевого уровня |
||||||||
Такой формат многопротокольного кадра (рис. 31.3) обеспечивает воз-
можность идентифицировать протоколы взаимодействия объединенных ло-
кальных вычислительных сетей (ЛВС) и маршрутизации, определенные стан-
дартами Американского института инженеров в области электротехники и электроники (IEEE — Institute of Electrical and Electronics Engineers, «Комитет
802 по стандартизации ЛВС») для протоколов доступа к ЛВС (ПДЛВС). В этом случае, для идентификации ПДЛВС IEEE (заголовок ПДЛВС) используются пять октетов, следующие после октета ИПСУ. Заголовок ПДЛВС имеет сле-
дующее кодирование:
442
первые три октета (уникальный идентификатор организации) определяют организацию, которая устанавливает кодирование последних двух окте-
тов;
последние два октета — идентификатор протокола.
Все узлы связи и маршрутизаторы должны распознавать и соответствую-
щим образом интерпретировать поле ИПСУ и заголовок ПДЛВС.
Заголовок ПДЛВС пригоден как для протоколов маршрутизации в ЛВС,
так и для протоколов взаимодействия объединенных ЛВС. При использовании последних существует дополнительная необязательная функция поля FCS в FR-
кадре, которая заключается в том, что в этом поле размещается циклическая проверка корректности пакета, сформированного протоколом управления ЛВС и «вложенного» в FR-кадр (т.е. имеет место двойное применение поля FCS).
Кодирование идентификаторов протоколов взаимодействия объединенных ЛВС представлено в стандартах IEEE 802.3, 802.4, 802.5, 802.6 и на волоконно-
оптическую ЛВС (FDDI).
Заголовок |
|
|
|
|
Данные |
Верхние |
|
|
|
||||
верхнего уровня |
|
|
|
|
абонента |
уровни |
|
|
|
|
|
|
|
Уровень
фрагментации
FR-уровень
Заголовок |
Заголовок |
Концевик |
фрагментации |
FR-кадра |
FR-кадра |
Рис. 31.4. Процедура фрагментирования и формирования FR-кадра
Использование многопротокольного FR-кадра обеспечивает возможность передачи через межсетевой интерфейс, осуществляющий многопротокольное пакетирование, пакетов ЛВС, которые имеют максимальный размер, превы-
шающий размер поля данных FR-кадра. В этом случае необходимо иметь уст-
ройство доступа, обеспечивающее «разбиение» (фрагментирование) кадров ЛВС на меньшие информационные фрагменты. При этом элементарные фраг-
443
менты кадра ЛВС должны иметь индивидуальные номера, с помощью которых можно «собирать» (восстанавливать) исходный кадр ЛВС. Процедура фрагмен-
тирования и формирования FR-кадра представлена на рис. 31.4.
На первом этапе устройство доступа «добавляет» к кадру ЛВС пятиок-
тетный заголовок (рис. 31.2). Это большое сообщение, с «добавленным» заго-
ловком, затем разбивается на фрагменты меньшей длины, равной размеру ин-
формационного поля кадра FR-сети. Далее эти маленькие фрагменты рассмат-
риваются как блоки «чистых» данных, к которым добавились (еще до поступ-
ления в сеть) так называемые заголовки фрагментирования. После чего каждый такой фрагмент «вкладывается» в многопротокольный FR кадр, представлен-
ный на рис. 31.5. «Внутреннее содержимое» информационного поля многопро-
токольного FR-кадра (включая заголовки фрагментирования) определяется ис-
ключительно протоколами верхних уровней (но не канального).
Биты |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
Назначение |
|
Октеты |
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
1 |
|
0 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
Ф л а г |
2 |
|
|
|
|
|
|
|
|
|
Адресная часть заголовка |
3 |
|
|
|
|
|
|
|
|
|
стандартного FR-кадра |
4 |
|
1 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
ИНИК |
5 |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Необязательное поле |
6 |
|
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
ИПСУ |
7 |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Уникальный идентификатор |
8 |
|
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
|
|
организации |
|||||||||
9 |
|
0 |
1 |
0 |
0 |
0 |
0 |
1 |
1 |
|
|
|
|||||||||
10 |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Идентификатор протокола |
11 |
|
1 |
0 |
1 |
1 |
0 |
0 |
0 |
0 |
|
|
|
|||||||||
12 |
|
|
|
|
|
|
|
|
|
Последовательный номер |
13 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
14 |
|
|
Смещение |
|
|
Резерв |
|
F |
Подзаголовок фрагментирования |
|
15 |
|
|
Смещение (продолжение) |
|
|
|||||
|
|
|
|
|
||||||
16... |
|
|
|
|
|
|
|
|
|
ФРАГМЕНТ ДАННЫХ |
|
|
|
|
|
|
|
|
|
|
Проверочная последовательность |
|
|
0 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
Ф л а г |
Рис. 31.5. Формат многопротокольного кадра, «переносящего» один из фрагментов |
||||||||||
|
исходного сообщения, которое подверглось делению |
|||||||||
444
Заголовок FR-кадра (при фрагментировании исходного сообщения) со-
держит следующие поля:
oадресное поле. Стандартный формат FR-кадра, имеющий 2-октетную или,
если это необходимо, 3- и 4-октетную длину;
oидентификатор ненумерованного информационного кадра. Этот иденти-
фикатор определяется Рекомендацией ITU-T Q.922 (его значение анало-
гично значению кадра LMI);
o необязательное поле. Этот октет кодируется значением «00000000» и
служит для «выравнивания», если это необходимо, размера кадра; o ИПСУ. Кодирование представлено в Q.933 (ITU-T);
oуникальный идентификатор организации. Имеет постоянный код (шест-
надцатеричный «00-80-С2»);
oидентификатор протокола. Имеет постоянный код (шестнадцатеричный
«00-0D»);
oпоследовательный номер. Длина этого поля составляет два октета. Значе-
ние этого номера увеличивается каждый раз при поступлении нового це-
лого сообщения, подлежащего фрагментированию. Таким образом, фор-
мируется уникальный идентификатор для каждого FR-кадра, «перенося-
щего» один из фрагментов исходного сообщения, которое подверглось
делению. Начальное значение этого номера, как правило, выбирается
произвольным образом;
oбит «финал». Этот бит устанавливается в «1» в FR-кадре, содержащем последний фрагмент исходного сообщения, которое подверглось деле-
нию, а в других — в «0»;
oсмещение. Длина этого поля составляет 11 октетов. Значение величины,
содержащейся в этом поле, определяет логическое смещение передавае-
мого фрагмента относительно первого фрагмента исходного сообщения,
которое подверглось делению. Эта величина равняется порядковому но-
меру байта, перед которым произошло деление исходного сообщения
(байт, который стал первым в очередном блоке исходного сообщения),
446
На приемной стороне фрагменты собираются в исходное сообщение, по-
сле чего выполняются процедуры протокола верхнего уровня. Сборка исходно-
го сообщения осуществляется на основе анализа значений смещения, которые передаются в подзаголовке фрагментирования. Любой кадр может быть поте-
рян в сети, что будет обнаружено протоколом верхнего уровня ввиду отсутст-
вия одного (или более) фрагмента исходного сообщения. В этом случае ответ-
ственность за восстановление исходного сообщения (путем его перезапроса)
полностью ложится на протокол более высокого уровня.
Х.25 |
|
Х.25 |
|
|
|
Х.25 |
|
Процедуры |
|
Процедуры сетевого |
|
|
|
Процедуры |
|
сетевого |
|
|
|
|
сетевого |
||
|
уровня |
|
|
|
|||
уровня |
|
|
|
|
уровня |
||
|
|
|
|
|
|
||
|
|
|
LAPB |
|
|
|
LAPB |
LAPB |
|
LAPB |
|
|
|
|
|
|
Т.618 |
|
Т.618 |
|
Т.618 |
||
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
Физический |
|
Физический |
Физический |
|
Физический |
|
Физический |
|
|
|
|||||
уровень |
|
уровень |
уровень |
|
уровень |
|
уровень |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
АКД Х.25 со |
|
|
|
|
|
ООД Х.25 |
|
«встроенной» функцией |
|
FR-сеть |
|
FR-сеть/ |
|
|
межсетевого |
|
|
ООД Х.25 |
|||
|
|
|
|
|
|||
|
|
взаимодействия |
|
|
|
|
|
Рис. 31.7. Диаграмма многоуровневого управления доставкой пакетов Х.25 на основе упрощенного метода формирования FR-кадра
На рис. 31.6 показана процедура фрагментирования и формирования пер-
вых двух FR-кадров из исходного «большого» IP-пакета.
Интеграция FR и Х.25 сетей
Рекомендация ITU-T Х.25 определяет стандарты протоколов и интерфей-
сов канального и сетевого уровней. И с точки зрения ретрансляции кадров про-
токолы Х.25 являются высокоуровневыми «способами и средствами» управле-
ния информационным обменом. Поэтому существует система взглядов, в соот-
447
ветствии с которой кадры Х.25 достаточно корректно вписываются в формат многопротокольного FR-кадра. Однако многие фирмы, производящие про-
граммно-аппаратные средства для Х.25 сетей, считают, что способы формиро-
вания многопротокольного FR-кадра чрезвычайно сложны и существует более простая реализация протоколов доставки пакетов Х.25 через FR-сеть. Более то-
го, последнее активно внедряется в сетевое оборудование и абонентские пунк-
ты.
В связи с этим в стандарт ANSI T1.617 (Приложение G) были внесены поправки, которые детализируют упрощенный метод обрамления пакета Х.25 и
формирование FR-кадра. Этот метод может быть применен только с обоюдного предварительного согласия сторон, так как он не предусматривает какие-либо процедуры (способы) сигнализации с целью оповещения ООД пользователя об использовании такого метода.
На рис. 31.7 представлена диаграмма многоуровневого управления дос-
тавкой пакетов Х.25 на основе упрощенного метода формирования FR-кадра.
Априори считается, что взаимодействие на сетевом уровне осуществляет-
ся между абонентскими ООД, а на втором (канальном) уровне поддерживается сбалансированная процедура доступа к каналу (Link Access Procedure Balanced -
LAPB). Кадр канального уровня (LAPB) обрамляется и формируется FR-кадр,
который пересылается к месту назначения через определенный DLCI (при этом используются согласованные параметры и условия доставки по FR-сети). На приемной стороне кадр канального уровня «освобождается» от обрамления FR-
кадра и направляется для обработки на канальный уровень управления (LAPB),
а после этого, соответственно, — на сетевой уровень. Это означает, что прото-
кол канального уровня (LAPB) взаимодействует с FR-сетью так же, как и с фи-
зическим уровнем обычной сети Х.25; при этом FR-сеть «прозрачна» для всех типов кадров (информационных и управляющих).
На рис. 31.8 представлен формат FR-кадра, «переносящего» кадр каналь-
ного уровня (кадр LAPB). Адресное поле, поле управления и информационное поле кадра канального уровня полностью без изменений вставляются в инфор-
449
Метод ретрансляции кадров разрабатывался как синхронный метод дос-
тавки данных в ЦСИО (и не только). Соответственно все реализующие этот ме-
тод способы и качество обслуживания определялись для различных видов тра-
фика, кроме речевого. Все традиционные сети с пакетной коммутацией, как правило, использующие различные способы коммутации пакетов и низкоскоро-
стные каналы связи, не предусматривали возможность доставки сообщений,
чувствительных к задержке. Другими словами, эти сети имеют большую и час-
то меняющуюся задержку доставки сообщений.
Известно, что такая задержка является функцией, с одной стороны, ско-
рости коммутации в УС, а с другой — пропускной способности магистральной линии связи. Значительное снижение задержки может быть достигнуто за счет применения метода ретрансляции кадров и магистральных линий связи с высо-
кой пропускной способностью. Таким образом, FR-сеть способна «транспорти-
ровать» чувствительный к задержкам трафик. Однако одно дело — передача такого типа трафика по сети с динамической маршрутизацией, а другое — обеспечение приемлемого качества обслуживания пользователей.
Одной из проблем, связанных с передачей речевого трафика, является то,
что скорость такой передачи должна быть постоянна. Это следует из того, что вся информация, содержащаяся в оцифрованном речевом сигнале (импульсно-
кодовая модуляция — ИКМ), передаваемом со скоростью 64 Кбит/с, важна и необходима для восстановления исходного речевого сообщения на приемной стороне. Вместе с тем в настоящее время разработаны методы и способы сни-
жения требуемой полосы пропускания оцифрованного речевого сигнала, среди которых:
компрессия (сжатие речевого сигнала). Этот метод позволяет снизить скорость передачи с 64 до 8 Кбит/с и ниже. Во многих известных мульти-
плексорах (аппаратуре временного объединения (разделения) каналов)
реализованы алгоритмы, позволяющие уменьшить такую скорость. Ко-
нечно, дальнейший рост компрессии (т.е. снижение скорости передачи)
начинает сказываться на качестве восстанавливаемого речевого сообще-
450
ния. Однако человеческое ухо способно уловить и распознать речь, кото-
рая была подвергнута очень сильному сжатию;
детектирование шума (речевых пауз). Исследования показывают, что ти-
пичная человеческая речь включает до 60...70% пауз, которые необходи-
мо детектировать. Последняя процедура нужна, прежде всего, для того,
чтобы исключить передачу «бесполезной» информации через сеть и тем
самым обеспечить высокую эффективность функционирования сети.
Эти, а также другие методы могут быть с успехом использованы в про-
цессах пакетирования оцифрованных речевых сообщений. Поэтому в настоя-
щее время, активно проводятся работы по их стандартизации и внедрению в различные службы передачи речевого трафика в пакетной форме. Большинство проблем стандартизации в данной области связано с «природой» самих сетей с пакетной коммутацией. В первую очередь это относится к нумерации пакетов,
которая необходима для обеспечения гарантированной доставки пакетов в их естественной последовательности. Более того, различные пакеты могут иметь и различные внутрисетевые задержки, так как возможны различные экстремаль-
ные ситуации, возникающие при отказе линий и узлов связи, перегрузках и блокировках и т.п.
ITU-T принял Рекомендацию G.764, которая определяет способ сегмен-
тирования оцифрованного речевого сигнала и формирование соответствующих пакетов. Однако этот стандарт содержит много проблем, которые послужат дальнейшему поиску новых решений в области передачи речевого трафика в сетях с пакетной коммутацией. К этим проблемам относятся:
детектирование шума с целью снижения входного трафика. Эта рекомен-
дация детализирует процедуры анализа входного речевого трафика, де-
тектирования пауз и передачу последних через сеть в форме синхронизи-
рующих последовательностей для определения начала и окончания рече-
вых и неречевых последовательностей;
нумерация последовательностей пакетов, обеспечивающая доставку по-
следних в их естественной последовательности. В случае потери пакета
