Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Сети и телекоммуникации

.pdf
Скачиваний:
257
Добавлен:
05.06.2015
Размер:
13.44 Mб
Скачать

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 октетов. Значение величины,

содержащейся в этом поле, определяет логическое смещение передавае-

мого фрагмента относительно первого фрагмента исходного сообщения,

которое подверглось делению. Эта величина равняется порядковому но-

меру байта, перед которым произошло деление исходного сообщения

(байт, который стал первым в очередном блоке исходного сообщения),

445

деленному на 32. Очевидно, что эта величина в FR-кадре, «переносящем»

первый из фрагментов исходного сообщения, устанавливается в «0»;

oданные. Это поле содержит заголовок верхнего уровня и данные пользо-

вателя.

 

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

1

1

0

0

1

1

ИПСУ

7

 

 

Д а н н ы е

 

 

Исходный IP-пакет

...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверочная

 

 

 

 

 

 

 

 

 

последовательность

 

 

 

 

 

 

 

 

 

 

 

0

1

1

1

1

1

1

0

Флаг

 

 

 

 

 

 

 

 

 

 

Назначение

1

2

 

3

4

 

5

6

 

7

8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Флаг

0

1

 

1

1

 

1

1

 

1

0

1

Адресная часть

 

 

 

 

 

 

 

 

 

 

 

2

заголовка FR-кадра

 

 

 

 

 

 

 

 

 

 

 

3

ИНИК

1

1

 

0

0

 

0

0

 

0

0

4

Необязательное поле

0

0

 

0

0

 

0

0

 

0

0

5

ИПСУ

0

0

 

0

1

 

0

0

 

0

0

6

Уникальный идентификатор

0

0

 

0

0

 

0

0

 

0

0

7

0

0

 

0

1

 

0

0

 

0

0

8

организации

 

 

 

0

1

 

0

0

 

0

0

 

1

1

9

 

 

 

 

Идентификатор

0

0

 

0

0

 

0

0

 

0

0

10

протокола

1

0

 

1

1

 

0

0

 

0

0

11

Последовательный

 

 

 

 

 

n

 

 

 

 

12

номер

 

 

 

 

 

 

 

 

 

13

 

 

 

 

 

 

 

 

 

 

 

Подзаголовок

Смещение

 

 

Резерв

 

0

14

фрагментирования

 

 

Смещение («0»)

 

 

15

Необязательное поле

0

0

 

0

0

 

0

0

 

0

0

16

ИПСУ

0

0

 

1

1

 

0

0

 

1

1

17

Первые m байт

 

 

 

Д а н н ы е

 

 

18

исходного IP-пакета

 

 

 

 

 

...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверочная

 

 

 

 

 

 

 

 

 

 

 

 

последовательность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Флаг

0

1

 

1

1

 

1

1

 

1

0

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

1

2

 

3

4

 

5

6

 

7

8

 

 

 

 

 

 

 

 

 

 

 

 

Флаг

0

1

 

1

1

 

1

1

 

1

0

1

Адресная часть

 

 

 

 

 

 

 

 

 

 

 

2

заголовка FR-кадра

 

 

 

 

 

 

 

 

 

 

 

3

ИНИК

1

1

 

0

0

 

0

0

 

0

0

4

Необязательное поле

0

0

 

0

0

 

0

0

 

0

0

5

ИПСУ

0

0

 

0

1

 

0

0

 

0

0

6

Уникальный

0

0

 

0

0

 

0

0

 

0

0

7

идентификатор

0

0

 

0

1

 

0

0

 

0

0

8

организации

0

1

 

0

0

 

0

0

 

1

1

9

 

 

 

 

Идентификатор

0

0

 

0

0

 

0

0

 

0

0

10

протокола

1

0

 

1

1

 

0

0

 

0

0

11

Последовательный

 

 

 

 

 

n

 

 

 

 

12

номер

 

 

 

 

 

 

 

 

 

13

 

 

 

 

 

 

 

 

 

 

 

Подзаголовок

Смещение

 

 

Резерв

 

1

14

фрагментирования

 

Смещение («m/32»)

 

15

Остаток исходного IP-пакета

 

 

 

Д а н н ы е

 

 

16

 

 

 

 

 

...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверочная

 

 

 

 

 

 

 

 

 

 

 

 

последовательность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Флаг

0

1

 

1

1

 

1

1

 

1

0

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 31.6. Пример фрагментирования IP-пакета

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). Адресное поле, поле управления и информационное поле кадра канального уровня полностью без изменений вставляются в инфор-

448

мационное поле FR-кадра. Одним из характерных условий формирования тако-

го FR-кадра является то, что в этом случае в заголовке FR-кадра не использу-

ется идентификатор типа протокола. Другое характерное условие касается при-

менения стандартного 2-октетного адресного поля заголовка. И последнее ус-

ловие относится к полю проверочной последовательности (FCS): FCS кадра ка-

нального уровня заменяется FCS FR-кадра, которая определяется с учетом всех полей — 2-октетного адресного поля заголовка FR-кадра, адресного поля, поля управления и информационного поля кадра канального уровня. Соответственно на приемной стороне осуществляются процедуры, обратные указанным выше.

Назначение

1

 

2

3

4

5

6

7

 

8

 

 

 

 

 

 

 

 

 

 

Флаг

0

 

1

1

1

1

1

1

 

0

Заголовок

 

 

 

Адресное поле

 

 

 

кадра LAPB

 

 

 

Поле управления

 

 

 

 

 

 

 

Данные

 

Информационное поле кадра LAPB

 

FCS

 

 

 

 

 

 

 

 

 

 

кадра LAPB

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Флаг

0

 

1

1

1

1

1

1

 

0

 

 

 

 

 

 

 

 

 

 

 

1

2

3

4

5

6

7

8

 

 

 

 

 

 

 

 

0

1

1

1

1

1

1

0

 

 

 

 

 

 

 

 

0

0

 

 

DLCI

 

 

 

 

 

 

 

 

 

1

D

B

F

 

DLCI

 

 

 

 

 

 

 

 

 

Адресное поле

Поле управления

Информационное поле кадра LAPB

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0

1

1

1

1

1

1

0

 

 

 

 

 

 

 

 

Назначение

Флаг

Адрес FR-кадра

Заголовок кадра LAPB

Данные

FCS FR-кадра

Флаг

Рис. 31.8. Формат FR-кадра, «переносящего» кадр LAPB

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

телей. При реализации такой схемы взаимодействия FR и Х.25 сетей желатель-

но выполнение следующего условия: максимальный размер «окна» на 2-ом уровне (ЭМВОС) должен соответствовать рекомендованному значению (128).

Это вызвано, в первую очередь, тем, что практика применения протоколов управления потоков на канальном уровне с использованием меньшего (чем 128)

размера «окна» показала значительное снижение эффективности функциониро-

вания процедуры LAPB.

Ретрансляция кадров и речевой трафик

449

Метод ретрансляции кадров разрабатывался как синхронный метод дос-

тавки данных в ЦСИО (и не только). Соответственно все реализующие этот ме-

тод способы и качество обслуживания определялись для различных видов тра-

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

стные каналы связи, не предусматривали возможность доставки сообщений,

чувствительных к задержке. Другими словами, эти сети имеют большую и час-

то меняющуюся задержку доставки сообщений.

Известно, что такая задержка является функцией, с одной стороны, ско-

рости коммутации в УС, а с другой — пропускной способности магистральной линии связи. Значительное снижение задержки может быть достигнуто за счет применения метода ретрансляции кадров и магистральных линий связи с высо-

кой пропускной способностью. Таким образом, FR-сеть способна «транспорти-

ровать» чувствительный к задержкам трафик. Однако одно дело — передача такого типа трафика по сети с динамической маршрутизацией, а другое — обеспечение приемлемого качества обслуживания пользователей.

Одной из проблем, связанных с передачей речевого трафика, является то,

что скорость такой передачи должна быть постоянна. Это следует из того, что вся информация, содержащаяся в оцифрованном речевом сигнале (импульсно-

кодовая модуляция — ИКМ), передаваемом со скоростью 64 Кбит/с, важна и необходима для восстановления исходного речевого сообщения на приемной стороне. Вместе с тем в настоящее время разработаны методы и способы сни-

жения требуемой полосы пропускания оцифрованного речевого сигнала, среди которых:

компрессия (сжатие речевого сигнала). Этот метод позволяет снизить скорость передачи с 64 до 8 Кбит/с и ниже. Во многих известных мульти-

плексорах (аппаратуре временного объединения (разделения) каналов)

реализованы алгоритмы, позволяющие уменьшить такую скорость. Ко-

нечно, дальнейший рост компрессии (т.е. снижение скорости передачи)

начинает сказываться на качестве восстанавливаемого речевого сообще-

450

ния. Однако человеческое ухо способно уловить и распознать речь, кото-

рая была подвергнута очень сильному сжатию;

детектирование шума (речевых пауз). Исследования показывают, что ти-

пичная человеческая речь включает до 60...70% пауз, которые необходи-

мо детектировать. Последняя процедура нужна, прежде всего, для того,

чтобы исключить передачу «бесполезной» информации через сеть и тем

самым обеспечить высокую эффективность функционирования сети.

Эти, а также другие методы могут быть с успехом использованы в про-

цессах пакетирования оцифрованных речевых сообщений. Поэтому в настоя-

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

которая необходима для обеспечения гарантированной доставки пакетов в их естественной последовательности. Более того, различные пакеты могут иметь и различные внутрисетевые задержки, так как возможны различные экстремаль-

ные ситуации, возникающие при отказе линий и узлов связи, перегрузках и блокировках и т.п.

ITU-T принял Рекомендацию G.764, которая определяет способ сегмен-

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

детектирование шума с целью снижения входного трафика. Эта рекомен-

дация детализирует процедуры анализа входного речевого трафика, де-

тектирования пауз и передачу последних через сеть в форме синхронизи-

рующих последовательностей для определения начала и окончания рече-

вых и неречевых последовательностей;

нумерация последовательностей пакетов, обеспечивающая доставку по-

следних в их естественной последовательности. В случае потери пакета